Removal of linux-base from jessie-backports broke Xen upstream CI
Introduction I would like to recount a situation. I'm not sure where, if anywhere, the root bug(s) lie, but I am inclined to say that a big part of the problem was a change to the contents of jessie-backports. I would be interested to hear what the backports team and ftpmaster have to say; in particular, if anyone knows the answers to my questions below. My tentative conclusions are that: 1. Packages should not be removed from foo-backports just because a similar package is in foo-security, because there are situations where a host may have been relying on the package being in foo-backports and a similar (even, newer) package being in foo-security is not sufficient. 2. Cruft removal in stable releases, including in -backports, should perhaps be done with care/caution/announcement or something. Background -- The upstream Xen project CI system does baremetal testing of Xen hypervisors etc. and therefore needs to reinstall hosts quite often. This is done by running a debian-installer netinst image with a preseed file. For Reasons we are still mostly on jessie. We have some arm64 boxes. They don't work with the kernel from jessie. So we arrange to use the kernel from jessie-backports. Using the jessie-backports kernel with the jessie installer involves using the preseed hook mechanism to add jessie-backports to the target's apt sources, and an in-target apt-get install rune to install the kernel package. (Using the jessie-backports kernel also involves editing the installer image to have the jessie-backports kernel and modules, but that is not relevant to this tale.) The arm64 kernel in jessie-backports is this package linux-image-4.9.0-0.bpo.2-arm64 (4.9.18-1~bpo8+1) It Depends on `linux-base (>= 4.3~)'. So it is necessary to have a newer linux-base. According to my git commit logs, in January 2017 I added the equivalent of apt-get install -t jessie-backports linux-base to the commands run via the preseed mechanism: at that time a newer linux-base was available in backports. Breakage According to snapshot.d.o, until the 6th of February, linux-base 4.3~bpo8+1 was available in jessie-backports. So things worked fine. Around 16:00 UTC on the 7th of February, linux-base was removed from jessie-backports, presumably because it was considered cruft. After all, linux-base 4.5~deb8u1 is now in jessie-security. However, after that change to the archive, the dependency resolver from jessie's apt, in our CI, is no longer willing to update to linux-base from jessie-security. (I have not yet investigated in detail but I suspect that the apt-get -t jessie-backports rune above is part of that causal chain.) The result is that linux-image-4.9.*'s version dependency on linux-base could not be satisfied. In our CI this resulted in a mysterious failure where despite us not having changed anything, the host would fail to boot when it wanted to reboot into the installed system, because it would try to use the original jessie 3.16 kernel (which does not run on our hardware). Logs For the very curious, and for my reference, complete logs of an example failure are preserved here: http://logs.test-lab.xenproject.org/~iwj/132973.test-arm64-arm64-xl/info.html Mostly you want to look at the `Logfiles etc.'. You can also click on the entries in the `status' column to see the output from the CI system perl scripts. The installer syslog is here: http://logs.test-lab.xenproject.org/~iwj/132973.test-arm64-arm64-xl/3.ts-syslog-server.log When looking at the serial log: http://logs.test-lab.xenproject.org/~iwj/132973.test-arm64-arm64-xl/serial-laxton0.log it is important to realise that that logfile contains a fair amount of previous output. Look at the timestamps: you want the part of the log starting at 2019-02-07 15:13:32 Z. Analysis and questions -- I'm almost certain that the proximate cause of the breakage was the removal of linux-base from jessie-security. I think, but I am not sure, that that apt-get rune to request linux-base from backports was was previously necessary. The reason I say that I am not sure is that the CI commit which added that rune had, according to its commit message, an additional effect of putting backports in the apt sources; perhaps that latter would have been sufficient. (After I have sent this mail I am going to mess about with the system to find a way to get it working properly again.) Q: Was `apt-get install -t backports linux-base' unnecessary (and wrong) ? It is unfortunate that something which worked for a period of over 2 years was broken by an archive change. I don't know for sure that the removal this was cruft removal but it seems like the most plausible explanation. I haven't so far found any explanation somewhere but perhaps I looked in the wrong places. Q. Why was linux-base removed from jessie-backports ? Opinions and suggestions welcome. Thanks, Ian. -- Ian JacksonThese
Re: Removal of linux-base from jessie-backports broke Xen upstream CI
On Wed, 13 Feb 2019, Ian Jackson wrote: > Introduction > > > I would like to recount a situation. I'm not sure where, if anywhere, > the root bug(s) lie, but I am inclined to say that a big part of the > problem was a change to the contents of jessie-backports. I would be > interested to hear what the backports team and ftpmaster have to say; > in particular, if anyone knows the answers to my questions below. > > My tentative conclusions are that: > > 1. Packages should not be removed from foo-backports just because a > similar package is in foo-security, because there are situations where > a host may have been relying on the package being in foo-backports and > a similar (even, newer) package being in foo-security is not > sufficient. > > 2. Cruft removal in stable releases, including in -backports, should > perhaps be done with care/caution/announcement or something. Jessie backports doesn't exist anymore. For some time now. It is already on its way to archive.d.o. And I don't think we should inform everybody for a simple maintenance task like crufting. Alex
Bug#922226: ITP: intel-mediasdk -- Intel Media SDK
Package: wnpp Severity: wishlist Owner: Timo Aaltonen * Package name: intel-mediasdk Version : 18.4.0 Upstream Author : Intel Corporation * URL : https://github.com/Intel-Media-SDK/MediaSDK * License : MIT Programming Lang: C Description : Intel Media SDK Intel® Media SDK provides an API to access hardware-accelerated video decode, encode and filtering on Intel® platforms with integrated graphics.
Re: Removal of linux-base from jessie-backports broke Xen upstream CI
Alexander Wirt writes ("Re: Removal of linux-base from jessie-backports broke
Xen upstream CI"):
> Jessie backports doesn't exist anymore. For some time now. It is already on
> its way to archive.d.o.
Thanks are due to to folks on #debian-uk who pointed out this
announcement (from June!) that I missed;
https://lists.debian.org/debian-backports-announce/2018/07/msg0.html
I have to say I'm not sure this removal is very helpful but then I'm
not helping maintain -backports so I guess my opinion doesn't carry
much weight.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Removal of linux-base from jessie-backports broke Xen upstream CI
On Wed, 13 Feb 2019, Ian Jackson wrote:
> Alexander Wirt writes ("Re: Removal of linux-base from jessie-backports broke
> Xen upstream CI"):
> > Jessie backports doesn't exist anymore. For some time now. It is already on
> > its way to archive.d.o.
>
> Thanks are due to to folks on #debian-uk who pointed out this
> announcement (from June!) that I missed;
> https://lists.debian.org/debian-backports-announce/2018/07/msg0.html
And https://lists.debian.org/debian-backports/2018/06/msg00052.html
and https://lists.debian.org/debian-backports/2017/06/msg00055.html
Alex
signature.asc
Description: PGP signature
Re: Bug#922155: [Pkg-matrix-maintainers] ITP: matrix-archive-keyring -- OpenPGP archive key for the Matrix.org package repository
On Tue, Feb 12, 2019 at 09:40:30PM +0100, Jonas Smedegaard wrote: > Quoting Jonas Smedegaard (2019-02-12 19:38:57) > > I believe this package belongs in contrib, as its only use-case is with > > together with software outside of Debian main. > > ...and now posting to the actual bugreport as well. I'm not opposed to having this matrix-archive-keyring package in the contrib area, although for comparison I should note leap-archive-keyring has no rdepends, the keyring package is available from Debian's main archive area and is valid for verifying package signatures from leap.se. An example of a package from deb.leap.se is bitmask-core (which is not available in Debian), and it's not in the contrib area in the leap.se repository. Maybe this is an error/bug in the leap-archive-keyring package, but it does seem confusing. The other *-archive-keyring packages in Debian main seem to be at least vaguely related to the Debian Project or its teams, although they are all (with the exception of debian-archive-keyring) meant to be used with third-party data sources (usually with APT). As of yesterday, there is also this high-priority debconf(1) question template in the matrix-archive-keyring package: Template: matrix-archive-keyring/sources.list Type: boolean Default: false _Description: Use APT data sources from Matrix.org? The Matrix.org Debian package repository distributes supplemental Matrix.org related packages intended to work with the Debian distribution, but require software software outside of the distribution to either build or function. These packages are digitally signed with keys from matrix-archive-keyring. . The Debian Project will be unable to directly support issues faced from using supplemental packages from this third-party repository. Packages from these APT sources may be non-conforming to the technical requirements set in the Debian Policy for the Debian distribution. (Sorry if I fell under the assumption the package will be usable on Debian only, and not derivative distributions with different names.) Choosing "yes" here would obviously enable the contrib bits from the default of "false". And as I said, packages from Matrix.org are already in the contrib area (Section: contrib/*). If this debconf(1) question makes it a hard-requirement of contrib archive area, I could split the main parts (keyring) and the debconf(1) question (sources.list) to seperate packages in main and contrib sections respectively if that is more desirable. I have currently set the package's "Section:" to "contrib/misc", in any case. What do you think?
Re: Removal of linux-base from jessie-backports broke Xen upstream CI
On Wed, 2019-02-13 at 12:46 +, Ian Jackson wrote:
> Alexander Wirt writes ("Re: Removal of linux-base from jessie-backports broke
> Xen upstream CI"):
> > Jessie backports doesn't exist anymore. For some time now. It is already on
> > its way to archive.d.o.
>
> Thanks are due to to folks on #debian-uk who pointed out this
> announcement (from June!) that I missed;
> https://lists.debian.org/debian-backports-announce/2018/07/msg0.html
>
> I have to say I'm not sure this removal is very helpful but then I'm
> not helping maintain -backports so I guess my opinion doesn't carry
> much weight.
More importantly Jessie has reached end-of-life[1]. Please do not
expect related suites (such as -security, -backports, -proposed-
updates, -updates) to continue working after this.
(Related to that: arm64 is gone from jessie-security; arm64 wasn't
removed from -backports as there is no LTS for backports and jessie-
backports will eventually be archived as is.)
Ansgar
[1] https://www.debian.org/News/2018/20180623
Re: Bug#922155: [Pkg-matrix-maintainers] ITP: matrix-archive-keyring -- OpenPGP archive key for the Matrix.org package repository
On Wed, 2019-02-13 at 15:41 +, Linda Lapinlampi wrote: > Template: matrix-archive-keyring/sources.list > Type: boolean > Default: false > _Description: Use APT data sources from Matrix.org? > The Matrix.org Debian package repository distributes supplemental Matrix.org > related packages intended to work with the Debian distribution, but require > software software outside of the distribution to either build or function. > These packages are digitally signed with keys from matrix-archive-keyring. > . > The Debian Project will be unable to directly support issues faced from using > supplemental packages from this third-party repository. Packages from these > APT sources may be non-conforming to the technical requirements set in the > Debian Policy for the Debian distribution. More important is the question if the system should /trust/ the keys. IMHO installing a non-Debian keyring should *not* make the keys trusted by APT by default (i.e. with the default answer if debconf is used). ubuntu-keyring does that; most other keyrings sadly do not follow this. Ansgar
Re: Bug#922155: [Pkg-matrix-maintainers] ITP: matrix-archive-keyring -- OpenPGP archive key for the Matrix.org package repository
On Wed, Feb 13, 2019 at 05:17:27PM +0100, Ansgar wrote: > More important is the question if the system should /trust/ the keys. > > IMHO installing a non-Debian keyring should *not* make the keys trusted > by APT by default (i.e. with the default answer if debconf is used). agreed. > ubuntu-keyring does that; most other keyrings sadly do not follow this. file bugs? -- tschau, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#922244: ITP: intel-cm-compiler -- Intel C-for-Media compiler
Package: wnpp Severity: wishlist Owner: Timo Aaltonen * Package name: intel-cm-compiler Version : git Upstream Author : Intel Corporation * URL : https://github.com/intel/cm-compiler * License : MIT Programming Lang: C Description : Intel C-for-Media compiler The Intel(R) C-for-Media compiler is a open source compiler that implements C-for-Media (CM) programming language. CM is a new GPU kernel programming language for Intel HD Graphics.
Re: Removal of linux-base from jessie-backports broke Xen upstream CI
Ansgar writes ("Re: Removal of linux-base from jessie-backports broke Xen
upstream CI"):
> More importantly Jessie has reached end-of-life[1]. Please do not
> expect related suites (such as -security, -backports, -proposed-
> updates, -updates) to continue working after this.
>
> (Related to that: arm64 is gone from jessie-security; arm64 wasn't
> removed from -backports as there is no LTS for backports and jessie-
> backports will eventually be archived as is.)
I have switched my CI to use jessie-backports from snapshot.d.o.
(I have a good cache setup, so this ought not to cause snapshot any
difficulties.) Thanks to everyone behind snapshot.d.o which is, as
ever, invaluable.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Bug#922155: [Pkg-matrix-maintainers] ITP: matrix-archive-keyring -- OpenPGP archive key for the Matrix.org package repository
Quoting Linda Lapinlampi (2019-02-13 16:41:06) > On Tue, Feb 12, 2019 at 09:40:30PM +0100, Jonas Smedegaard wrote: > > Quoting Jonas Smedegaard (2019-02-12 19:38:57) > > > I believe this package belongs in contrib, as its only use-case is > > > with together with software outside of Debian main. > > > > ...and now posting to the actual bugreport as well. > > I'm not opposed to having this matrix-archive-keyring package in the > contrib area, although for comparison I should note > leap-archive-keyring has no rdepends, the keyring package is available > from Debian's main archive area and is valid for verifying package > signatures from leap.se. An example of a package from deb.leap.se is > bitmask-core (which is not available in Debian), and it's not in the > contrib area in the leap.se repository. > > Maybe this is an error/bug in the leap-archive-keyring package, but it > does seem confusing. The other *-archive-keyring packages in Debian > main seem to be at least vaguely related to the Debian Project or its > teams, although they are all (with the exception of > debian-archive-keyring) meant to be used with third-party data sources > (usually with APT). Thanks for comparing with similar packages: That indicates you go that extra mile in striving towards perfection in your packaging - Cool! Please file bugreports for such other packages that you notice - should be fine filing such bugs with high severity, since it is a violation of a "must" in Debian Policy § 2.2.1. > As of yesterday, there is also this high-priority debconf(1) question > template in the matrix-archive-keyring package: > > Template: matrix-archive-keyring/sources.list > Type: boolean > Default: false > _Description: Use APT data sources from Matrix.org? > The Matrix.org Debian package repository distributes supplemental Matrix.org > related packages intended to work with the Debian distribution, but require > software software outside of the distribution to either build or function. > These packages are digitally signed with keys from matrix-archive-keyring. > . > The Debian Project will be unable to directly support issues faced from using > supplemental packages from this third-party repository. Packages from these > APT sources may be non-conforming to the technical requirements set in the > Debian Policy for the Debian distribution. Cool! > (Sorry if I fell under the assumption the package will be usable on > Debian only, and not derivative distributions with different names.) > > Choosing "yes" here would obviously enable the contrib bits from the > default of "false". And as I said, packages from Matrix.org are > already in the contrib area (Section: contrib/*). > > If this debconf(1) question makes it a hard-requirement of contrib > archive area, I could split the main parts (keyring) and the > debconf(1) question (sources.list) to seperate packages in main and > contrib sections respectively if that is more desirable. > > I have currently set the package's "Section:" to "contrib/misc", in > any case. > > What do you think? The addition of a debconf question - with default being false - seems an excellent improvement over the package silently activating the keys (if that was the previous behaviour - I am only guessing here). I find the keys themselves to be the reason for the package belonging in contrib, however - regardless of adding that nice debconf message. Thanks a lot for your contribution to Debian! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Bug#922155: [Pkg-matrix-maintainers] ITP: matrix-archive-keyring -- OpenPGP archive key for the Matrix.org package repository
On Wed, Feb 13, 2019 at 05:17:27PM +0100, Ansgar wrote: > More important is the question if the system should /trust/ the keys. > > IMHO installing a non-Debian keyring should *not* make the keys trusted > by APT by default (i.e. with the default answer if debconf is used). I've agreed, it's the problem I'm trying to solve with this matrix-archive-keyring package. As said in the OP of Bug#922155 (ITP): > I have made this package install an OpenPGP-armored keyring to > /usr/share/keyrings (instead of /etc/apt/trusted.gpg.d); Since they are not in Dir::Etc::trusted or Dir::Etc::trustedparts, the system won't trust the Matrix archive keys for APT by default (unless the sysadmin has explicitly configured otherwise). By default, sources.list(5) entries will need to specifically have [signed-by:/usr/share/keyrings/matrix-archive-keyring.gpg] for APT to trust the data sources with this package. To clarify, trust to keys in the matrix-archive-keyring package is all a multi-step opt-in: 1. Using the keyring to manually verify packages from Matrix.org (yes) 2. Trusting the keyring for Matrix.org APT sources (default: no) 3. Trusting the keyring for any APT sources (default: hell no) What the Internet says to do and what's currently happening in practice: 1. Using the repository key to manually verify packages from Matrix.org 2. Trusting the repository key for Matrix.org APT sources (yes, but...) 3. Trusting the repository key for any APT sources (yikes) There is an additional low priority debconf(1) question in matrix-archive-keyring if #3 should be true, but with sane default of "false" and a warning about it being unnecessary in most cases. Although it's so trivial, I'm open to removing this option altogether if desired for lacking much real use. The other debconf(1) question (#2) serves to answer if the user should trust packages from the third-party repository. If you meant the description of that question does not adequately ask if the user should /trust/ packages from that repository (instead of just mentioning they are supplemental packages which are not officially supported), would you like me to change the description for the release to point out trust more prominently? The alternative may be a seperate contrib package for a sources.list source. > ubuntu-keyring does that; most other keyrings sadly do not follow this. I'd suggest to file bugs. I've found many issues in the past few days.
