Bug#1019919: cdebconf: Missing GPL-2+ license in d/copyright

2022-09-16 Thread Bastian Germann 

Source: cdebconf
Severity: important
Version: 0.264

The debian/po/* files are licensed under debian-installer's license, which is 
GPL-2+.
This license and some copyright statements are missing in your debian/copyright 
file.
Please find a copyright file attached that fixes these issues and come in the 
machine-readable format.Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Comment: CDebConf was initially written by Randolph Chung 

Files: *
Copyright: 2000-2009 by Randolph Chung , the d-i team, and 
Canonical Ltd.
   Anthony Towns 
   David Whedon 
   Dan Jacobowitz 
   Tollef Fog Heen 
   Attilio Fiandrotti 
   Colin Watson 
   Regis Boudin 
Comment: CDebConf includes ideas and code from:
 debconf - The original, de facto, perl implementation
   (c) Joey Hess 
 apt - The Debian Advanced Package Tool
   (c) Jason Gunthorpe 
   (derived portions are public domain)
License: BSD-2-Clause

Files: debian/po/*
Copyright: 2003-2015, 2017-2018 Software in the Public Interest, Inc.
   2000-2012 Free Software Foundation, Inc.
Comment: This file is distributed under the same license as debian-installer.
License: GPL-2+

Files: debian/po/pt.po
Copyright: 2003 Software in the Public Interest, Inc.
   2003-2014 Miguel Figueiredo 
License: GPL-2+

Files: debian/po/bg.po
Copyright: 2003 Software in the Public Interest, Inc.
   2004, 2010 Free Software Foundation, Inc.
   2004, 2005, 2006 Ognyan Kulev 
   2004 Nikola Antonov 
   2007 Tobias Quathamer 
   2001, 2004 Georgi Georgiev 
   2001 Alastair McKinstry 
   2004 Ognyan Kulev 
   2006, 2007, 2008, 2009, 2010 Damyan Ivanov 
   2010 Roumen Petrov 
   2006-2015, 2017 Damyan Ivanov 
License: GPL-2+

Files: debian/po/ml.po
Copyright: 2006-2010 Debian Project
License: GPL-2+

Files: debian/po/bn.po
Copyright: 2005, 2006 Debian Foundation
License: GPL-2+

Files: debian/po/oc.po
   debian/po/kab.po
   debian/po/te.po
Copyright: 2006, 2007, 2008 Canonical Ltd, and Rosetta Contributors
License: GPL-2+

Files: debian/po/de.po
Copyright: 2003 Software in the Public Interest, Inc.
   2006, the console-setup package'c copyright holder
   2006, Matthias Julius
   2007-2009 Helge Kreutzmann
   2008-2011 Holger Wansing
License: GPL-2+

Files: debian/po/pl.po
Copyright: 2003 Software in the Public Interest, Inc.
   2004-2010 Bartosz Feński 
License: GPL-2+

Files: debian/po/fi.po
Copyright: 2003 Software in the Public Interest, Inc.
   2007 Tobias Toedter 
   2005-2006, 2008-2010 Free Software Foundation, Inc.
License: GPL-2+

Files: debian/po/ko.po
Copyright: 2003,2004,2005,2008 Software in the Public Interest, Inc.
   2001 Alastair McKinstry 
   2004, 2008, 2009, 2010, 2011 Changwoo Ryu , .
   2000, 2001, 2003 Free Software Foundation, Inc.
   2001 Eungkyu Song 
   2001 Jaegeum Choe 
   2000 Kang, JeongHee 
   2006-2007 Sunjae Park 
   2007 Tobias Quathamer 
License: GPL-2+

Files: debian/po/sr.po
Copyright: 2010-2012 Software in the Public Interest, Inc.
   2008 THE cp6Linux'S COPYRIGHT HOLDER
   2003, 2004 Free Software Foundation, Inc.
License: GPL-2+

Files: debian/rules
Copyright: 1997-1999 Joey Hess
License: GPL-2+

License: BSD-2-clause
 Redistribution and use in source and binary forms, with or without
 modification, are permitted provided that the following conditions
 are met:
 .
 1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
 2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
 .
 THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' AND
 ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
 FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 SUCH DAMAGE.

License: GPL-2+
 On Debian systems, the complete text of the GNU General
 Public License version 2 can be found in "/usr/share/common-licenses/GPL-2".

Status of Debian Installer Bookworm Alpha 1: 2 blockers

2022-09-16 Thread Cyril Brulebois 
Hi folks,

As you might know, the installer is prepared this way:
 - debian-installer MMDD uploaded to unstable;
 - a debian-installer-images tarball (one per arch) gets generated
   during the build and gets unpacked into installer-/ directories
   for unstable (scripts/debian/byhand-di in dak.git);
 - we ask the ftp team to copy-installer MMDD, to get those copied
   for testing (dak/copy_installer.py in dak.git);
 - debian-installer migrates to testing via britney.

Currently the last step is blocking. Britney reports two issues:

 1. debian-installer unsatisfiable Build-Depends(-Arch) on ppc64el: 
grub-ieee1275-bin:ppc64el [ppc64el]
 2. Built-Using: debian-installer u-boot

Let's dive in!


(1) cross building

I'd like to thank Frédéric and Samuel for being interested in cross
building, but it appears the directives introduced in the following
commit aren't supported by britney, and were considered inappropriate
when I asked about it on #debian-release. Johannes and Helmut suggested
contacting debian-cross@ to get better ideas.

  
https://salsa.debian.org/installer-team/debian-installer/-/commit/23e4451d7132e3bac7bd589747a44a776ea69834

Grepping around in Sources, I could only find u-boot using a similar
syntax, but only for Build-Depends that are annotated with a cross
profile, which might explain why britney hasn't considered that to be an
issue.

To get back on track with the release, I'm tempted to just revert that
commit right away, and to ask interested parties to submit a better
patch for consideration after the release. That would just mean a new
upload, that would be the easy topic…


(2) u-boot

debian-installer registers a number of packages via Built-Using, to help
keep source packages around (for license compliance mainly, I think, but
I'm definitely not an expert there). Since it's built in unstable, and
since it build-depends on u-boot, it ends up listing that particular
version.

Right now, u-boot looks like that:

u-boot | 2022.04+dfsg-2 | testing| source
u-boot | 2022.07+dfsg-1 | unstable   | source

And there's an RC bug to prevent its migration to testing until it's
been tested on various boards. It's a critical component at boot-time so
I'm quite reluctant to even envision a severity downgrade, esp. since
first reports are not encouraging. Vagrant also mentioned that more
recent versions aren't looking better.

  https://bugs.debian.org/1016963

What are the options at this point (forgetting about the first issue
for a moment)?

 A. Force debian-installer into testing, breaking source compliance?
Looks like a rather bad idea, at the very least from a legal
standpoint. There might be other technical consequences, but anyway:
we would be using u-boot bits that are known to be bad for some
boards…
 B. Go for a 2022.07+really+2022.04-like version in unstable? Looks
like extra work for Vagrant, and confusion for everyone.
 C. Upload debian-installer via testing-proposed-updates (tpu)? I'll
focus on that option in the rest of this mail, but feel free to
propose anything else!

I think we discussed that possibility a few times, but a quick look
into dak acceptance notifications, we only used that to upload d-i
components via tpu, not the debian-installer package itself.

A few questions I can think of:
 - Is that a good idea in the first place? I think so, sidestepping
   temporary issues in unstable looks like a valid usecase? But
   maybe option B would just be better?
 - Do we have tpu set up dak-wise/chroot-wise/sbuild-wise already?
 - Would dak be happy to accept the relevant tarball? A quick look
   at scripts/debian/byhand-di suggests it should.
 - Would dak make it possible to copy installer-/ from tpu
   to testing? A quick look at dak/copy_installer.py's usage suggests
   its takes source and destination parameters (defaulting to unstable
   and testing respectively).
 - Would it be OK to use a higher version in tpu than in unstable?
   We have constraints on the version numbers (in dak), and I think
   we should be able to use 20220914~deb12u1 but we're really
   considering fixing 20220914 with 20220917 (or so) instead, and
   relying on an extra/hopefully final prop-up (as done during point
   releases…) might be more straightforward.


Thanks for reading up so far, and for any advice on the way forward!


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Status of Debian Installer Bookworm Alpha 1: 2 blockers

2022-09-16 Thread Samuel Thibault 
Hello,

Cyril Brulebois, le sam. 17 sept. 2022 01:41:52 +0200, a ecrit:
>   
> https://salsa.debian.org/installer-team/debian-installer/-/commit/23e4451d7132e3bac7bd589747a44a776ea69834
> 
> To get back on track with the release, I'm tempted to just revert that
> commit right away,

I have reverted it already :)

Discussion is going on in the corresponding MR, 
https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/24

Samuel

Re: Status of Debian Installer Bookworm Alpha 1: 2 blockers

2022-09-16 Thread Cyril Brulebois 
Samuel Thibault  (2022-09-17):
> Cyril Brulebois, le sam. 17 sept. 2022 01:41:52 +0200, a ecrit:
> >   
> > https://salsa.debian.org/installer-team/debian-installer/-/commit/23e4451d7132e3bac7bd589747a44a776ea69834
> > 
> > To get back on track with the release, I'm tempted to just revert that
> > commit right away,
> 
> I have reverted it already :)
> 
> Discussion is going on in the corresponding MR, 
> https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/24

At this point, I'm not really interested in diving in each and every
build-dep to figure out what makes sense and what doesn't. A partial
revert that doesn't document what it reverts and what it doesn't…
doesn't really help I'm afraid. If anything, that's more confusing.

I'll go for a wholesale revert when I get a better idea of what we're
going to do with u-boot.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Status of Debian Installer Bookworm Alpha 1: 2 blockers

2022-09-16 Thread Samuel Thibault 
Cyril Brulebois, le sam. 17 sept. 2022 02:21:27 +0200, a ecrit:
> Samuel Thibault  (2022-09-17):
> > Cyril Brulebois, le sam. 17 sept. 2022 01:41:52 +0200, a ecrit:
> > >   
> > > https://salsa.debian.org/installer-team/debian-installer/-/commit/23e4451d7132e3bac7bd589747a44a776ea69834
> > > 
> > > To get back on track with the release, I'm tempted to just revert that
> > > commit right away,
> > 
> > I have reverted it already :)
> > 
> > Discussion is going on in the corresponding MR, 
> > https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/24
> 
> At this point, I'm not really interested in diving in each and every
> build-dep to figure out what makes sense and what doesn't. A partial
> revert that doesn't document what it reverts and what it doesn't…

All build-deps are reverted. The only pieces that I haven't reverted are
the no-op for normal builds:

+   -o APT::Architecture=$deb_host_arch \\

-ARCH=$(shell dpkg-architecture -qDEB_BUILD_ARCH)
+ARCH=$(shell dpkg-architecture -qDEB_HOST_ARCH)

Samuel