[Bug 1895137] Re: [MIR] rpi-eeprom; raspberrypi-userland

2021-02-18 Thread Matthias Klose
Override component to main
rpi-eeprom 11.3-1ubuntu1 in hirsute: multiverse/misc -> main
rpi-eeprom 11.3-1ubuntu1 in hirsute arm64: multiverse/misc/optional/100% -> main
rpi-eeprom 11.3-1ubuntu1 in hirsute armhf: multiverse/misc/optional/100% -> main
3 publications overridden.


** Changed in: rpi-eeprom (Ubuntu)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1895137

Title:
  [MIR] rpi-eeprom; raspberrypi-userland

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/raspberrypi-userland/+bug/1895137/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1895137] Re: [MIR] rpi-eeprom; raspberrypi-userland

2021-02-18 Thread Matthias Klose
Override component to main
raspberrypi-userland 0~20200520+git2fe4ca3-0ubuntu3 in hirsute: universe/libs 
-> main
libraspberrypi-bin 0~20200520+git2fe4ca3-0ubuntu3 in hirsute arm64: 
universe/misc/optional/100% -> main
libraspberrypi-bin 0~20200520+git2fe4ca3-0ubuntu3 in hirsute armhf: 
universe/misc/optional/100% -> main
libraspberrypi-dev 0~20200520+git2fe4ca3-0ubuntu3 in hirsute arm64: 
universe/libdevel/optional/100% -> main
libraspberrypi-dev 0~20200520+git2fe4ca3-0ubuntu3 in hirsute armhf: 
universe/libdevel/optional/100% -> main
libraspberrypi0 0~20200520+git2fe4ca3-0ubuntu3 in hirsute arm64: 
universe/libs/optional/100% -> main
libraspberrypi0 0~20200520+git2fe4ca3-0ubuntu3 in hirsute armhf: 
universe/libs/optional/100% -> main
7 publications overridden.

** Changed in: raspberrypi-userland (Ubuntu)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1895137

Title:
  [MIR] rpi-eeprom; raspberrypi-userland

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/raspberrypi-userland/+bug/1895137/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1895137] Re: [MIR] rpi-eeprom; raspberrypi-userland

2021-02-17 Thread Christian Ehrhardt 
Set the states to be ready for the AAs per [1].
This should resolve soon'ish.

[1]:
https://wiki.ubuntu.com/MainInclusionProcess?action=show=MIRTeam#Process_states

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1895137

Title:
  [MIR] rpi-eeprom; raspberrypi-userland

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/raspberrypi-userland/+bug/1895137/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1895137] Re: [MIR] rpi-eeprom; raspberrypi-userland

2021-02-17 Thread Christian Ehrhardt 
Ok clarified, and good - thanks Dave!

All former concerns are resolved AFAICS.
Therefore since all else was ready let use mark this ready for promotion (and 
after all this also is one of the cases that we kind of "already support but 
want to make official").

** Changed in: raspberrypi-userland (Ubuntu)
 Assignee: Matthias Klose (doko) => (unassigned)

** Changed in: rpi-eeprom (Ubuntu)
   Status: In Progress => Fix Committed

** Changed in: raspberrypi-userland (Ubuntu)
   Status: New => Fix Committed

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1895137

Title:
  [MIR] rpi-eeprom; raspberrypi-userland

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/raspberrypi-userland/+bug/1895137/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1895137] Re: [MIR] rpi-eeprom; raspberrypi-userland

2021-02-17 Thread Christian Ehrhardt 
We have assigned doko to re-review, but he is too often lost in too
important bugs (e.g. today in
https://bugs.launchpad.net/ubuntu/+source/fakeroot/+bug/1915250). So I
want to help here by doing the re-review.

The builds of 
https://bugs.launchpad.net/ubuntu/+source/rpi-eeprom/+bug/1895137/comments/15 
are in hirsute by now.
 raspberrypi-userland | 0~20200520+git2fe4ca3-0ubuntu3   | hirsute/universe 
   | source

Now we need to check if all concerns were adressed:
per CL they are:
  3   * d/copyright audit   
 
  4   * Added d/p/no-specific-libgps.patch to use whatever libgps the system
 
  5 provides
 
  6   * Excluded the various /usr/bin/containers_* test binaries from   
 
  7 libraspberrypi-bin  
 
  8   * Added d/librasperrypi0.symbols file 
 
  9   * Fixed pkgconfig paths in d/p/fix-multiarch-dir.patch

I checked the changes between this and the former versions
- symbols are really present now for libraspberrypi0
  - this was a bit ugly (one pkg, many libs - no versioned names, ..)
  - but eventully the .symbols made sense, covered all
  - also I see why we need the dev-pkg-without-shlib-symlink and 
shlib-without-versioned-soname overrides unless we want to mess with the common 
filenames
- copyright was massively updated
- containers* is removed after dh_install
- test binaries are moved
- There are a few more fixes, none look concerning


This really looks mostly good by now.

Remaining Questions:
- multi-arch: foreign was requested, same it became - reason?

I've pinged Dave to clarify ...

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1895137

Title:
  [MIR] rpi-eeprom; raspberrypi-userland

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/raspberrypi-userland/+bug/1895137/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1895137] Re: [MIR] rpi-eeprom; raspberrypi-userland

2021-01-26 Thread Christian Ehrhardt 
** Changed in: raspberrypi-userland (Ubuntu)
 Assignee: (unassigned) => Matthias Klose (doko)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1895137

Title:
  [MIR] rpi-eeprom; raspberrypi-userland

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/raspberrypi-userland/+bug/1895137/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1895137] Re: [MIR] rpi-eeprom; raspberrypi-userland

2021-01-25 Thread Matthias Klose
** Changed in: raspberrypi-userland (Ubuntu)
   Status: In Progress => New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1895137

Title:
  [MIR] rpi-eeprom; raspberrypi-userland

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/raspberrypi-userland/+bug/1895137/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1895137] Re: [MIR] rpi-eeprom; raspberrypi-userland

2021-01-25 Thread Łukasz Zemczak
** Changed in: raspberrypi-userland (Ubuntu)
   Status: Incomplete => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1895137

Title:
  [MIR] rpi-eeprom; raspberrypi-userland

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/raspberrypi-userland/+bug/1895137/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1895137] Re: [MIR] rpi-eeprom; raspberrypi-userland

2021-01-14 Thread Brian Murray
Comment #16 was inappropriately added due to the following in the linux-
firmware-raspi2 changelog:

* Replaced postinst with flash-kernel trigger (relates to LP: #1895137)

So please ignore it, sorry for the noise!

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1895137

Title:
  [MIR] rpi-eeprom; raspberrypi-userland

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/raspberrypi-userland/+bug/1895137/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1895137] Re: [MIR] rpi-eeprom; raspberrypi-userland

2021-01-11 Thread Dave Jones
The userland packages in the following PPA should address all points
raised by doko in the review in comment #13:

https://launchpad.net/~waveform/+archive/ubuntu/userland

I'm happy to attach a debdiff if that's preferable, but given the scale
of the changes I'm not sure that'd be easier to review. Not mentioned in
the changelog is that file conflicts have now been checked and verified
as not applicable.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1895137

Title:
  [MIR] rpi-eeprom; raspberrypi-userland

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/raspberrypi-userland/+bug/1895137/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1895137] Re: [MIR] rpi-eeprom; raspberrypi-userland

2020-12-08 Thread Christian Ehrhardt 
FYI in MIR meeting of today:
[16:44]  waveform: I wanted to know if this is incomplete as in "ack 
I'll do it at some point" or as in "we'll give u then"
[16:44]  cpaelzer, that's basically done - I've just got to update 
the bug

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1895137

Title:
  [MIR] rpi-eeprom; raspberrypi-userland

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/raspberrypi-userland/+bug/1895137/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1895137] Re: [MIR] rpi-eeprom; raspberrypi-userland

2020-10-16 Thread Matthias Klose
raspberrypi-userland:

things which have to be fixed:

 - the debian/copyright is incomplete. an fgrep -ri copyright
   shows missing copyright holders, although these might
  not be extensive.  Please also check for possible missing
  copyright holders which are not covered by the simple
  check above.

- host_applications/linux/apps/hello_pi/hello_video/README
  not mentioned in d/copyright, and no license given. If the license
  is not clear, it should be removed from the source package.

- having an upstream not caring about ABI stability is one thing,
  however that's not what Ubuntu requires for main inclusion.
  Especially for this, symbols files are required.

 - libraspberrypi-bin.lintian-overrides says:
  "The container binaries are undocumented and don't support -h
  so I've no idea what they do".
  How can we support these if we don't know what these do, and
  why they are included?

- did you check for conflicting files in /usr/bin and /usr/include?
  some names look pretty generic

things which should be fixed:

- the library packages should be marked as M-A: foreign

- there are a few (test?) binaries in /usr/bin, polluting the
  name space, which don't even have man pages. Wouldn't it
  be more appropriate to move those into some package
  specific libdir?


** Changed in: raspberrypi-userland (Ubuntu)
   Status: New => Incomplete

** Changed in: raspberrypi-userland (Ubuntu)
 Assignee: Matthias Klose (doko) => (unassigned)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1895137

Title:
  [MIR] rpi-eeprom; raspberrypi-userland

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/raspberrypi-userland/+bug/1895137/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1895137] Re: [MIR] rpi-eeprom; raspberrypi-userland

2020-10-16 Thread Dave Jones
Thanks Seth,

> Security team ACK for promoting rpi-eeprom to restricted CONDITIONAL
> on another team stating that they will provide testing resources and
> periodically import updated versions as appropriate.

Foundations team will handle regular importing of updated versions, and
SRUing to all supported releases. Devices certification team will handle
provision of testing resources and periodic testing of all supported
releases.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1895137

Title:
  [MIR] rpi-eeprom; raspberrypi-userland

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/raspberrypi-userland/+bug/1895137/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1895137] Re: [MIR] rpi-eeprom; raspberrypi-userland

2020-10-15 Thread Seth Arnold
I reviewed rpi-eeprom version 9.0-1ubuntu1 as checked into groovy. This
isn't a full security audit but a very quick gauge of maintainability.

Because this is an architecture-specific review, the usual tooling doesn't
work for this case. This is a slight problem for maintenance, because the
security team may not have sufficient hardware for update preparation or
update testing. We will probably need to rely upon other teams to provide
testing facilities.

The firmwares themselves are blackboxes similar to intel-microcode or
amd64-microcode. The only recourse we have in the face of regressions is
reverting updates and the same will hold with this package as well.

I'm also concerned about the update frequency given in the
debian/changelog file or releases.md file. The security team does not
have the bandwidth to track these updates ourselves. It is unlikely
each one has security relevance, but if Canonical gets too far behind
on these packages, the Ubuntu security team may have trouble importing
new versions.

So, I would like some assurances that another team will be SRUing new
versions of the package for all supported releases on an appropriate
time-scale to manage the risks associated with high-rate-of-change
projects.

Security team ACK for promoting rpi-eeprom to restricted CONDITIONAL 
on another team stating that they will provide testing resources and
periodically import updated versions as appropriate.

Thanks


** Changed in: rpi-eeprom (Ubuntu)
 Assignee: Ubuntu Security Team (ubuntu-security) => (unassigned)

** Changed in: rpi-eeprom (Ubuntu)
   Status: Triaged => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1895137

Title:
  [MIR] rpi-eeprom; raspberrypi-userland

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/raspberrypi-userland/+bug/1895137/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1895137] Re: [MIR] rpi-eeprom

2020-10-07 Thread Dimitri John Ledkov
** Description changed:

+ = rpi-eeprom =
+ 
  [Availability]
  The package is in proposed, pending a correction to Architecture to permit it 
to migrate to multiverse (LP: #1884748).
  
  [Rationale]
  The package is required for updating the boot EEPROM on the Raspberry Pi 4.
  
  [Security]
  I am not aware of any open CVEs against the tools in rpi-eeprom.
  
  [Quality assurance]
  The package is extensively used upstream on Raspbian, and is obviously 
actively maintained there. There is no meaningful test suite included in the 
package, but the contents of the package are regularly exercised in image 
testing (and boot EEPROM testing).
  
  [UI standards]
  Manual pages are included for both utilties included in the package 
(rpi-eeprom-config and rpi-eeprom-update), but localization is missing from 
both utilities at present. However, most users will never use these utilities 
directly. Rather, they are typically launched by a systemd service on boot 
which automatically applies new versions of the boot EEPROM.
  
  [Dependencies]
  The package depends on binutils, python3, and pciutils, all of which are 
already in main. It also depends on linux-firmware-raspi2 and 
libraspberrypi-bin which are the subject of other MIRs (LP: #1867813, LP: 
#1895133).
  
  [Standards compliance]
  The package installs its scripts under /usr/bin.
  
  [Maintenance]
  The package is maintained by the Ubuntu Foundations team.
  
  [Background information]
  As this is a dependency for keeping the boot EEPROM on the Raspberry Pi 4 up 
to date, the intention is to install this by default in all pi-related images 
going forward.
  
- 
  ---
  
+ = raspberrypi-userland =
  
  [Availability]
  The package is already in universe.
  
  [Rationale]
  The package is depended upon by the new raspi-common seed, for inclusion in 
all pi related images. The reason for its inclusion in the seed is that the 
libraspberrypi-bin package provides the vcgencmd and dtoverlay utilities which 
are both required by rpi-eeprom (the subject of a separate MIR, LP: #1895137) 
for updating the boot EEPROM on the Raspberry Pi 4.
  
  The libraspberrypi0 package is a dependency of libraspberrypi-bin and
  both are built from the raspberrypi-userland source package.
  
  [Security]
  I am not aware of any open CVEs against the tools in libraspberrypi-bin or 
the libraries in libraspberrypi0.
  
  It may be worth noting that the -bin package installs a udev rule (in
  /lib/udev/10-local-rpi.rules) permitting members of the "video" group
  access to /dev/vchiq, which is required for all the VC related utilities
  (including vcgencmd, raspivid, and raspistill) to be operated without
  root privileges.
  
  [Quality assurance]
  The package is extensively used upstream on Raspbian, and is obviously 
actively maintained there. There is no meaningful test suite included in the 
package, but the contents of the package are regularly exercised in image 
testing (and boot EEPROM testing).
  
  [UI standards]
  I've added manual pages for all the utilities I'm able to, but localization 
is missing from all utilities at present. However, most users will never use 
these utilities directly (bar, perhaps, the raspivid and raspistill utilities 
for the camera module). Instead the most common scenario is that the utilities 
will be used (invisibly) by other scripts (e.g. rpi-eeprom-update) for 
maintenance purposes like manipulating the boot EEPROM.
  
  [Dependencies]
  As noted above, libraspberrypi-bin depends on libraspberrypi0. It also 
depends on device-tree-compiler and libc6, both of which are already in main. 
libraspberrypi0 in turn merely depends on libc6.
  
  [Standards compliance]
  The package installs its binaries under /usr/bin, and its libraries under 
/usr/lib. Upstream does not version their API, so the libraries are unversioned.
  
  [Maintenance]
  The package is maintained by the Ubuntu Foundations team.
  
  [Background information]
  As noted above, the package is a dependency of the recently added 
raspi-common seed 
(https://lists.ubuntu.com/archives/ubuntu-release/2020-September/005086.html). 
As it is a dependency for keeping the boot EEPROM on the Raspberry Pi 4 up to 
date, the intention is to install this by default in all pi-related images 
going forward.

** Summary changed:

- [MIR] rpi-eeprom
+ [MIR] rpi-eeprom; raspberrypi-userland

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1895137

Title:
  [MIR] rpi-eeprom; raspberrypi-userland

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/raspberrypi-userland/+bug/1895137/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1895137] Re: [MIR] rpi-eeprom

2020-10-02 Thread Christian Ehrhardt 
Thanks Dave and Dimitri!
Former issues:
- subscription - done
- install in other places is now working fine
  The service fails (split to bug 1898160), but that isn't too bad as at least
  no half-installed packages are happening anymore.
- updated to the most recent version
- version depends on libraspberrypi-bin fixed

- Still no tests, but ok I guess there isn't much you can test for an eeprom
  package at build time ?! :-/

MIR Team Ack for rpi-eeprom - is is already in component mismatch, so
settign Fix Committed.

@Doko:
Since overall you need all or nothing - what about the raspberrypi-userland 
review?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1895137

Title:
  [MIR] rpi-eeprom

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/raspberrypi-userland/+bug/1895137/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1895137] Re: [MIR] rpi-eeprom

2020-10-02 Thread Christian Ehrhardt 
Arr I forgot, we still wait for Securtity on rpi-eeprom.
But ok, the MIR Ack you have - it can go to Fix Committed as soon as they are 
happy as well.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1895137

Title:
  [MIR] rpi-eeprom

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/raspberrypi-userland/+bug/1895137/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1895137] Re: [MIR] rpi-eeprom

2020-09-30 Thread Dimitri John Ledkov
@christian updated rpi-eeprom is now in groovy, and it is now "done
right".

** Changed in: rpi-eeprom (Ubuntu)
   Status: Fix Released => Triaged

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1895137

Title:
  [MIR] rpi-eeprom

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/raspberrypi-userland/+bug/1895137/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1895137] Re: [MIR] rpi-eeprom

2020-09-30 Thread Launchpad Bug Tracker
This bug was fixed in the package rpi-eeprom - 9.0-1ubuntu1

---
rpi-eeprom (9.0-1ubuntu1) groovy; urgency=medium

  * Ubuntu port (LP: #1884748), including changes for MIR (LP: #1895137)
  * Added d/watch
  * Added d/p/use_python3_no_env.patch to remove env from rpi-eeprom-config
  * Removed redundant postinst and prerm scripts
  * Adjusted d/control to remove redundant rpi-eeprom-images definitions,
correct Architecture to armhf and arm64 only, and the bootloader
definition to the Ubuntu package name (linux-firmware-raspi2)
  * Fixed paths for Ubuntu in d/defaults/rpi-eeprom-update
  * Updated d/s/lintian-overrides

rpi-eeprom (9.0-1) buster; urgency=medium

  [ Tim Gover ]
  * pieeprom-2020-09-03: Promote latest stable to default/critical
  * Update releases.md
  * Update README.md
  * Archive 2020-08-31 and 2020-09-02 beta releases.

rpi-eeprom (8.0-1) buster; urgency=medium

  [ Tim Gover ]
  * Promote pieeprom-2020-09-03 to STABLE
  * Update releases.md

rpi-eeprom (7.14-1) buster; urgency=medium

  [ Kyle J. McKay ]
  * rpi-eeprom-update: avoid any possible od accidents

  [ Andrew Scheller ]
  * Add BETA label to release notes

  [ Tim Gover ]
  * pieeprom-2020-09-03.bin - Fix filename

rpi-eeprom (7.13-1) buster; urgency=medium

  [ Tim Gover ]
  * Use od instead of hexdump to simplify package dependencies
  * pieeprom-2020-09-02: Simplify green activity LED behavior

  [ MichaIng ]
  * Remove rpi-eeprom-images from dependencies

rpi-eeprom (7.12-1) buster; urgency=medium

  [ Tim Brooks ]
  * Fix #211 - hexdump error on older Pi models

rpi-eeprom (7.11-1) buster; urgency=medium

  [ Tim Gover ]
  * pieeprom-2020-08-31 - Disable self update mode from SD cards
  * Update link to latest stable release
  * Update releases.md
  * Update README.md

  [ andrum99 ]
  * Update README.md

  [ Hristo Venev ]
  * rpi-eeprom-update: Upstream kernel fix

  [ Serge Schneider ]
  * Use Python 3

rpi-eeprom (7.10-1) buster; urgency=medium

  [ Andrew Scheller ]
  * Typos

  [ Tim Gover ]
  * Promote beta 2020-07-31 to stable

rpi-eeprom (7.9-1) buster; urgency=medium

  [ Tim Gover ]
  * Update releases.md
  * rpi-eeprom-update: Set file permissions on the EEPROM update files
  * Rename .config.yml to config.yml
  * pieeprom-2020-07-31.bin - Standardize USB port power off across Pi4 models

rpi-eeprom (7.8-1) buster; urgency=medium

  [ Tim Gover ]
  * pieeprom-2020-07-16.bin - Promote to STABLE
  * recovery.bin - Update beta/stable after rebase

 -- Dave Jones   Thu, 24 Sep 2020 13:46:31
+0100

** Changed in: rpi-eeprom (Ubuntu)
   Status: Incomplete => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1895137

Title:
  [MIR] rpi-eeprom

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/raspberrypi-userland/+bug/1895137/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [Bug 1895137] Re: [MIR] rpi-eeprom

2020-09-17 Thread Christian Ehrhardt 
> > - Please consider updating to a newer version before you SRU things to
> >=Focal
>
> Is it best at this point to fix the existing 7.8 upload, or reject that
> and fix all this in a new 9.0 upload? Happy to do whichever is easier
> from the MIR/security team's perspective.

IMHO cancel what is there, get it right in Groovy or later and then
SRU the correct thing.
The usual reason is this, right now nothing is in Focal, so you can
(under constraints) backport anything.
But if you have 7.8+fixes there first and then plan to update to 9.0
this update would have to follow SRU rules.
Which means you'd need to retain any behavior of the former version
making it much harder for you.

TL;DR: "Get it right first, SRU once afterwards" usually is the right
approach

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1895137

Title:
  [MIR] rpi-eeprom

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/raspberrypi-userland/+bug/1895137/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [Bug 1895137] Re: [MIR] rpi-eeprom

2020-09-17 Thread Christian Ehrhardt 
> > - You refer to an empty VCS, having the changes commit-by-commit in this or
> >   another one (depending where you push) woud be great. Please fix the VCS
> >   entry to point at such a valid repo.
>
> Ah, I was under the misapprehension that the launchpad repo would be
> populated by the git-ubuntu import (in other words the Vcs-Browser entry
> was "pre-emptive"). As I'm not an uploader for this (or any) package,
> would it be more correct to just remove that for now?

Well, you'll maintain it somewhere atm - point there.

It will be imported once it is in main (or could be whitelisted now) -
then you could leave the current VCS entry.
The problem is that in any case we will miss all the history as it
never was in Debian to import from.
Gladly you know racb to talk about options from here.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1895137

Title:
  [MIR] rpi-eeprom

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/raspberrypi-userland/+bug/1895137/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [Bug 1895137] Re: [MIR] rpi-eeprom

2020-09-17 Thread Christian Ehrhardt 
> Just to clarify, is this suggesting it should install cleanly on non-pi
> arm hardware, but *then* refuse to work (with some appropriate error
> message) or should it refuse to install at all e.g. at dependency
> resolution time. I'd love to implement the latter but I've no idea how
> (is there such a thing as a package that's only available to pi
> images?). The former is rather more complex as it means fixing how
> linux-firmware-raspi2 installs its boot firmware (which is something
> that's been sat on my TODO list for yonks, but it means some rather
> invasive flash-kernel changes where we're already carrying a huge
> delta).

Either way works, but I'm not aware of any differentiation beyond
architecture that you can use.
And since arm64/armhf can be so many different things I'd ask to get
something into e.g. postinst that detects if it runs on the right HW
and if it doesn't skips the rest.
That way the binaries are available for evaluation but have no function.
If there are other active bits/hooks, then yes you'd want to disable
them as well in that case.

We've had similar cases where a package makes no sense in a container context.
But making it fail gracefully avoided people getting stuck with broken
packages which can be a big problem especially for less experienced
users.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1895137

Title:
  [MIR] rpi-eeprom

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/raspberrypi-userland/+bug/1895137/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1895137] Re: [MIR] rpi-eeprom

2020-09-16 Thread Dave Jones
> This one is hard to decide as it has binary blobs in the form of
> the RPI firmware. Usually for normal package that would be a denial
> reason, but other microcode delivering packages work the same way.

Just a quick note on this one, in case it changes anything: as rpi-
eeprom is currently intended to migrate to multiverse I assumed it would
be MIR'd to restricted rather than main (as you note: it primarily
consists of the binary blobs for the second stage bootloader).

In contrast, libraspberrypi{-bin,0} contains no binary blobs and should
indeed be targetted to main.

> - Get Foundations-bug subscribed to the package(s)

Now done for both rpi-eeprom and raspberrypi-userland

> - Even not being used there avoid packages to totally fail on install
>  and breaking apt thereby. Please get it to be gracefully-unusable there.
>  Raspbian only publishes for Pi, we do have more arm* models to support.
>  On non Pi arm* HW this is on install:
[snip]

Just to clarify, is this suggesting it should install cleanly on non-pi
arm hardware, but *then* refuse to work (with some appropriate error
message) or should it refuse to install at all e.g. at dependency
resolution time. I'd love to implement the latter but I've no idea how
(is there such a thing as a package that's only available to pi
images?). The former is rather more complex as it means fixing how
linux-firmware-raspi2 installs its boot firmware (which is something
that's been sat on my TODO list for yonks, but it means some rather
invasive flash-kernel changes where we're already carrying a huge
delta).

> - The Diff from 7.5-1 to our 7.8-0 can't be explained by the changelog.
>   It seems we have much more than just the new version.
>   Could you please ensure that the changelog clearly indicates what our Delta
>   over Raspbian is?

Will do (as you've probably guessed this all started out with 7.5 and I
must've bungled the migration of the changelog while dealing with 7.7
then 7.8 (3 days later!).

> - You refer to an empty VCS, having the changes commit-by-commit in this or
>   another one (depending where you push) woud be great. Please fix the VCS
>   entry to point at such a valid repo.

Ah, I was under the misapprehension that the launchpad repo would be
populated by the git-ubuntu import (in other words the Vcs-Browser entry
was "pre-emptive"). As I'm not an uploader for this (or any) package,
would it be more correct to just remove that for now?

> - Please investigate if it makes sense to be arch:all since it depends on
>  arm only packages:

Yup, that's definitely an issue - in fact that's the reason rpi-eeprom's
stuck in proposed because the dependency (libraspberrypi-bin) is
armhf/arm64 only. I've already fixed that in an upload for 8.0 to my PPA
(https://launchpad.net/~waveform/+archive/ubuntu/eeprom), but of course
that's now been superseded by 9.0!

> - Please clarify the Focal situation, the same version is stuck in proposed
>  there as well.

rpi-eeprom on Focal is currently awaiting the SRU of
libraspberrypi{-bin,0} to Focal (LP: #1883111), but as mentioned above
there's also the Arch: all issue. Still the intention is indeed to have
this in the current LTS and Groovy (possibly Bionic as well given the Pi
4 is supported there, but additional bumps to the linux-firmware-raspi2
package may be needed there).

> - Any chance to add some tests verifying the functional integrity of the 
> package
>  to run at build or autopkgtest time?

It should be possible to add their test script for autopkgtest usage
(although it only exercises rpi-eeprom-config that's about as much as we
could safely do). I'll get on with that.

> - Please consider updating to a newer version before you SRU things to
>=Focal

Is it best at this point to fix the existing 7.8 upload, or reject that
and fix all this in a new 9.0 upload? Happy to do whichever is easier
from the MIR/security team's perspective.

> [Dependencies]
> OK:
> - no other Dependencies to MIR due to this
>   Only libraspberrypi-bin out of raspberrypi-userland which is part of this 
> MIR

I think libraspberrypi0 is needed from raspberrypi-userland too as
that's a dependency of libraspberrypi-bin

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1895137

Title:
  [MIR] rpi-eeprom

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/raspberrypi-userland/+bug/1895137/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1895137] Re: [MIR] rpi-eeprom

2020-09-16 Thread Christian Ehrhardt 
FYI: Fused the thematically and use-case wise raspberry-userland MIR
with the bug here.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1895137

Title:
  [MIR] rpi-eeprom

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/raspberrypi-userland/+bug/1895137/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1895137] Re: [MIR] rpi-eeprom

2020-09-16 Thread Christian Ehrhardt 
[Summary]
This one is hard to decide as it has binary blobs in the form of
the RPI firmware. Usually for normal package that would be a denial
reason, but other microcode delivering packages work the same way.
I'll need to discuss and co-ack with other MIR Team members and
also need security to have a word.

For now call it "ok enough to get security review", but there are
enough todos listed for you to start right away - for that I'll also
mark it incomplete. Set it back to new once the mentioned TODOs are
done for re-evaluation.

This does need a security review, so I'll assign ubuntu-security

List specific binary packages to be promoted to main: rpi-eeprom

Info:
In this cases this isn't from Debian but from Raspbian and the upstream
is https://github.com/raspberrypi/rpi-eeprom

Required TODOs:
- Get Foundations-bug subscribed to the package(s)
- Even not being used there avoid packages to totally fail on install
  and breaking apt thereby. Please get it to be gracefully-unusable there.
  Raspbian only publishes for Pi, we do have more arm* models to support.
  On non Pi arm* HW this is on install:
Unpacking rpi-eeprom (7.8-0ubuntu2) ...
Setting up linux-firmware-raspi2 (1.20200601+arm64-0ubuntu3) ...
Error: missing /boot/firmware, did you forget to mount it?
dpkg: error processing package linux-firmware-raspi2 (--configure):
 installed linux-firmware-raspi2 package post-installation script
 subprocess returned error exit status 1
Setting up binutils-common:arm64 (2.35-3ubuntu1) ...
Setting up libctf-nobfd0:arm64 (2.35-3ubuntu1) ...
Setting up libraspberrypi0 (0~20200520+git2fe4ca3-0ubuntu2) ...
dpkg: dependency problems prevent configuration of rpi-eeprom:
 rpi-eeprom depends on linux-firmware-raspi2 (>= 1.20190819); however:
  Package linux-firmware-raspi2 is not configured yet.
dpkg: error processing package rpi-eeprom (--configure):
- The Diff from 7.5-1 to our 7.8-0 can't be explained by the changelog.
  It seems we have much more than just the new version.
  Could you please ensure that the changelog clearly indicates what our Delta
  over Raspbian is?
- You refer to an empty VCS, having the changes commit-by-commit in this or
  another one (depending where you push) woud be great. Please fix the VCS
  entry to point at such a valid repo.

Recommended TODOs:
- Please investigate if it makes sense to be arch:all since it depends on
  arm only packages:
  rpi-eeprom : Depends: libraspberrypi-bin but it is not installable
Depends: linux-firmware-raspi2 (>= 1.20190819) but it is not installable
- Please clarify the Focal situation, the same version is stuck in proposed
  there as well.
- Any chance to add some tests verifying the functional integrity of the package
  to run at build or autopkgtest time?
- Please consider updating to a newer version before you SRU things to >=Focal

[Duplication]
OK:
We don't have this package or a similar function. Also The Internet is full
of people asking for it - so it is important nad not otherwise available.
There is no other package in main providing the same functionality.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
  Only libraspberrypi-bin out of raspberrypi-userland which is part of this MIR
- no -dev/-debug/-doc packages that need exclusion

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking (well roms, but nothing that this rule tried to avoid)

Problems:
- The ROMs are all prebuilt. Usually this is a "hard no" as Debian packages
  shall be servicable and buildable from source so one knows what is in there.
  OTOH packges of similar scope like intel-microcode behave no different :-/
  Functional maintenance will be your job so you only can make your own job
  harder by not having sources, but this needs a security review to make sure
  they consider this serviceable.

[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not parse data formats
- does not open a port
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)

Problems:
- changes SW stacks below the control of the latter Linux system.
  This needs a security evaluation.

[Common blockers]
OK:
- does not FTBFS currently
- The package has a team bug subscriber
- no translation present, but none needed for this case (user visible)?
- not a python/go package, no extra constraints to consider int hat regard

Problems:
- does not have a test suite that runs at build time
- does not have a test suite that runs as autopkgtest

These are common issues with such low level things, but how would a drive
by contributor test anything. Is there a chance to get the file
test/test-rpi-eeprom-config working in a virtual environment and add some
guidance 

[Bug 1895137] Re: [MIR] rpi-eeprom

2020-09-16 Thread Christian Ehrhardt 
** Also affects: raspberrypi-userland (Ubuntu)
   Importance: Undecided
   Status: New

** Description changed:

  [Availability]
  The package is in proposed, pending a correction to Architecture to permit it 
to migrate to multiverse (LP: #1884748).
  
  [Rationale]
  The package is required for updating the boot EEPROM on the Raspberry Pi 4.
  
  [Security]
  I am not aware of any open CVEs against the tools in rpi-eeprom.
  
  [Quality assurance]
  The package is extensively used upstream on Raspbian, and is obviously 
actively maintained there. There is no meaningful test suite included in the 
package, but the contents of the package are regularly exercised in image 
testing (and boot EEPROM testing).
  
  [UI standards]
  Manual pages are included for both utilties included in the package 
(rpi-eeprom-config and rpi-eeprom-update), but localization is missing from 
both utilities at present. However, most users will never use these utilities 
directly. Rather, they are typically launched by a systemd service on boot 
which automatically applies new versions of the boot EEPROM.
  
  [Dependencies]
  The package depends on binutils, python3, and pciutils, all of which are 
already in main. It also depends on linux-firmware-raspi2 and 
libraspberrypi-bin which are the subject of other MIRs (LP: #1867813, LP: 
#1895133).
  
  [Standards compliance]
  The package installs its scripts under /usr/bin.
  
  [Maintenance]
  The package is maintained by the Ubuntu Foundations team.
  
  [Background information]
  As this is a dependency for keeping the boot EEPROM on the Raspberry Pi 4 up 
to date, the intention is to install this by default in all pi-related images 
going forward.
+ 
+ 
+ ---
+ 
+ 
+ [Availability]
+ The package is already in universe.
+ 
+ [Rationale]
+ The package is depended upon by the new raspi-common seed, for inclusion in 
all pi related images. The reason for its inclusion in the seed is that the 
libraspberrypi-bin package provides the vcgencmd and dtoverlay utilities which 
are both required by rpi-eeprom (the subject of a separate MIR, LP: #1895137) 
for updating the boot EEPROM on the Raspberry Pi 4.
+ 
+ The libraspberrypi0 package is a dependency of libraspberrypi-bin and
+ both are built from the raspberrypi-userland source package.
+ 
+ [Security]
+ I am not aware of any open CVEs against the tools in libraspberrypi-bin or 
the libraries in libraspberrypi0.
+ 
+ It may be worth noting that the -bin package installs a udev rule (in
+ /lib/udev/10-local-rpi.rules) permitting members of the "video" group
+ access to /dev/vchiq, which is required for all the VC related utilities
+ (including vcgencmd, raspivid, and raspistill) to be operated without
+ root privileges.
+ 
+ [Quality assurance]
+ The package is extensively used upstream on Raspbian, and is obviously 
actively maintained there. There is no meaningful test suite included in the 
package, but the contents of the package are regularly exercised in image 
testing (and boot EEPROM testing).
+ 
+ [UI standards]
+ I've added manual pages for all the utilities I'm able to, but localization 
is missing from all utilities at present. However, most users will never use 
these utilities directly (bar, perhaps, the raspivid and raspistill utilities 
for the camera module). Instead the most common scenario is that the utilities 
will be used (invisibly) by other scripts (e.g. rpi-eeprom-update) for 
maintenance purposes like manipulating the boot EEPROM.
+ 
+ [Dependencies]
+ As noted above, libraspberrypi-bin depends on libraspberrypi0. It also 
depends on device-tree-compiler and libc6, both of which are already in main. 
libraspberrypi0 in turn merely depends on libc6.
+ 
+ [Standards compliance]
+ The package installs its binaries under /usr/bin, and its libraries under 
/usr/lib. Upstream does not version their API, so the libraries are unversioned.
+ 
+ [Maintenance]
+ The package is maintained by the Ubuntu Foundations team.
+ 
+ [Background information]
+ As noted above, the package is a dependency of the recently added 
raspi-common seed 
(https://lists.ubuntu.com/archives/ubuntu-release/2020-September/005086.html). 
As it is a dependency for keeping the boot EEPROM on the Raspberry Pi 4 up to 
date, the intention is to install this by default in all pi-related images 
going forward.

** Changed in: raspberrypi-userland (Ubuntu)
 Assignee: (unassigned) => Matthias Klose (doko)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1895137

Title:
  [MIR] rpi-eeprom

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/raspberrypi-userland/+bug/1895137/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1895137] Re: [MIR] rpi-eeprom

2020-09-15 Thread Christian Ehrhardt 
** Changed in: rpi-eeprom (Ubuntu)
 Assignee: (unassigned) => Christian Ehrhardt  (paelzer)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1895137

Title:
  [MIR] rpi-eeprom

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rpi-eeprom/+bug/1895137/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs