Re: 10.6 planning

2020-09-09 Thread Cyril Brulebois
Hi,

Adam D. Barratt  (2020-09-09):
> We're slightly off our previous schedule because of delaying 10.5, but
> we should really get on with arranging 10.6.
> 
> Please could you confirm your availability, and any preferences, for
> the following:
> 
> - September 26/27
> - October 3/4

I should be able to accomodate whatever date gets picked.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Re: stretch EOL point release (9.13) and 10.5 planning

2020-07-18 Thread Cyril Brulebois
Adam D. Barratt  (2020-07-18):
> Now that stretch EoL is (more or less) out of the way, it would be good
> to get 10.5 done as soon as we sensibly can, so as not to slip too far
> off schedule.
> 
> Next weekend is probably a little too soon - I'd at least like to not
> jump straight back into freezing - but how about one of:
> 
> - August 1st/2nd
> - August 8th/9th

Both should work equally for me regarding the installer.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Re: stretch EOL point release (9.13) and 10.5 planning

2020-06-15 Thread Cyril Brulebois
Hi,

Adam D. Barratt  (2020-06-15):
> stretch transitions from oldstable-with-security-support to LTS support
> on Saturday July 4th. As usual, we should aim for the final point
> release to be soon after that, most likely pulling in any remaining
> updates from security.d.o that are still in oldstable-new.
> 
> I think Saturday July 11th makes most sense (so freezing opu during the
> transition weekend), but we could potentially stretch (no pun intended)
> slightly further if need be.
> 
> We also need to look at the next buster point release in a similar
> timeframe. Can anyone see a reason not to do the two at the same time,
> as usual?
> 
> To get the ball rolling, please could you confirm your availability
> for:
> 
> - July 11/12
> - July 18/19

Haven't looked at stretch in a while from a d-i point of view, but I
don't think we have any bugfixes pending? I'll have to check what's
happening on the buster front, if anything.

Anyway, I should be available, whatever date(s) get picked.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Re: Default security sources are slow very much.

2020-04-18 Thread Cyril Brulebois
Hi,

ykla  (2020-02-05):
> OK, the install cd ask me to change mirrors to download somethings but not
> changes security sources. Default source is http://security.debian.org/
> that is slow very much, about 1kb/s on my area. Please change security
> sources when os changes main source or ban security while installing
> system.

You can disable the security sources by using the expert install.

You can also set apt-setup/security_host to something else if needed.

You can also tweak apt-setup/services-select to exclude security if needed.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Re: Weekly Builds should be more robust

2020-04-18 Thread Cyril Brulebois
Hi Daniel,

Daniel Lewart  (2019-11-18):
> Debian CD [sic] Group,
> 
> Weekly builds haven't run successfully recently:
>   * Nov  4  Daily Failed
>   * Nov 11  Daily Failed
>   * Nov 18  Building 10.2
> 
> These failures are too common and affect those of us who are trying to
> use Testing from USB flash drives.
> 
> Could the weekly live cron job be changed to a daily one that builds
> things either:
>   * Mon
>   * Tue-Sun only if there has been no success since Mon
> 
> This would greatly improve things when problems arise,
> without any manual intervention.

Or you could just use alpha releases of the Debian Installer.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Re: Flawless Accessible Installation onto Old Thinkpad (X60 I think)

2020-04-18 Thread Cyril Brulebois
Hi Sam,

Thanks for your report; forwarding to debian-accessibility@ and
debian-boot@ for their information.

Sam Hartman  (2019-12-20):
> This is written as a thank you, and there are no actionable bits.
> So mail not a bug report to installation-reports.
> 
> I had an old laptop and I needed to be able to give someone a computer
> to use to do office work.  So I booted a 10.2.0 amd64 firmware netinst.
> I needed help selecting the boot device, but that's not Debian's
> problem.
> I pressed s at the installation prompt and got speech as expected.
> 
> Everything worked fine, and I got an  accessible system after the
> reboot.
> 
> I realize a lot of effort goes into makeing that happen, and it is
> greatly appreciated.
> 
> I was even able to install over an encrypted wifi connection.
> 
> 
> Thanks so much.
> 
> --Sam

Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Re: 10.4 planning

2020-04-06 Thread Cyril Brulebois
Adam D. Barratt  (2020-04-06):
> I realise things are a little unusual right now, but it's about time
> that we started looking at dates for 10.4.
> 
> I guess the biggest impact of current circumstances on the process is
> likely to be around image testing, as there won't be a bunch of people
> with local access to Steve's mirror.
> 
> I've listed some potential dates below; as usual, please indicate which
> you would be available for.
> 
> - April 25th
> - May 2nd
> - May 9th

All those should be just fine for me, thanks for asking.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Re: Planning 10.3 and 9.12

2020-01-06 Thread Cyril Brulebois
Adam D. Barratt  (2020-01-06):
> It's (really past) time to consider a date for the next point releases
> for buster and stretch.
> 
> I've listed some suggested dates below; please indicate which you would
> be available for.
> 
> - January 25th
> - February 1st
> - February 8th
> - February 15th

Any time should be fine by me.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Bug#944697: security.debian.org: please bring back MD5Sum, at least for buster/updates

2019-11-13 Thread Cyril Brulebois
Package: ftp.debian.org
Severity: serious
Justification: breaks image generation tools

Hi,

I've mentioned this on #debian-ftp already, but filing a bug report in
addition to make sure it's not lost.

Assuming the FTP team is responsible for security's dak setup as well,
we'd like to get MD5Sum back in buster/updates.

python-apt relies on md5 fields internally, as documented in #944696,
and a current symptom is live-wrapper's tracebacking accordingly when
packages are available in security; this has been the case for the
intel-microcode package, for a few hours.

jessie/updates and stretch/updates seem fine (MD5Sum is present there).
I don't have an opinion regarding bulleyes/updates (MD5Sum is missing
there) at this point, but given at least some apt bindings don't support
missing MD5Sum, it would seem premature to remove it from there as well?


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/



Bug#944696: python-apt: relies on MD5 internally to download packages

2019-11-13 Thread Cyril Brulebois
Package: python-apt
Version: 1.8.4
Severity: serious
Justification: some people want to get rid of MD5Sum in indices

Hi,

While debugging a live-wrapper (lwr) failure that started occurring
(literally) overnight, I ended up discovering it was triggered by the
intel-microcode package's getting a security upgrade.

live-wrapper 0.10 isn't affected, but live-wrapper's master branch has
an extra commit that automatically enables security sources for stable
releases.

Here's the traceback for a simple build (with a local mirror but anyone
would do) with that master branch:

$ sudo lwr -d buster -m http://wodi.home/debian -f intel-microcode
[…]
DEBUG environment: LWR_MIRROR = 'http://wodi.home/debian'
DEBUG environment: LWR_EXTRA_PACKAGES = ''
DEBUG environment: LWR_BASE_DEBS = ''
DEBUG environment: LWR_DISTRIBUTION = 'buster'
DEBUG environment: LWR_FIRMWARE_PACKAGES = 'intel-microcode'
DEBUG environment: LWR_TASK_PACKAGES = ''
[…]
Downloading udebs for Debian Installer...
INFO Downloading udebs for Debian Installer...
Updating a local cache for amd64 buster ...
DEBUG Updating local cache...
CRITICAL Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/cliapp/app.py", line 193, in _run
self.process_args(args)
  File "/usr/lib/python2.7/dist-packages/lwr/run.py", line 143, in 
process_args
self.start_ops()
  File "/usr/lib/python2.7/dist-packages/lwr/run.py", line 286, in start_ops
apt_udeb.download_udebs(exclude_list)
  File "/usr/lib/python2.7/dist-packages/lwr/apt_udeb.py", line 157, in 
download_udebs
self.download_apt_file(pkg_name, pool_dir, False)
  File "/usr/lib/python2.7/dist-packages/lwr/apt_udeb.py", line 141, in 
download_apt_file
version.fetch_binary(destdir=pkg_dir)
  File "/usr/lib/python2.7/dist-packages/apt/package.py", line 867, in 
fetch_binary
if _file_is_same(destfile, self.size, self._records.md5_hash):
SystemError: error return without exception set


After some debugging, it turned out that merely accessing the
self._records.md5_hash item is sufficient to reproduce this issue.

Looking at the current (as of 2019-11-14 00:27:00 UTC) indices for
buster/updates on security.debian.org, one can only see SHA256 entries
in Release and Packages files, which is likely the reason for
python-apt's explosion. I've asked #debian-ftp to add MD5Sum entries
back at least for buster/updates, and will file another bug report for
that in a moment to make sure it isn't lost.

Looking at even the most recent python-apt code in experimental (1.9.0),
MD5 still seems hardwired, e.g. in apt/packages.py's fetch_binary():


def fetch_binary(self, destdir='', progress=None):
# type: (str, AcquireProgress) -> str
"""Fetch the binary version of the package.

The parameter *destdir* specifies the directory where the package will
be fetched to.

The parameter *progress* may refer to an apt_pkg.AcquireProgress()
object. If not specified or None, apt.progress.text.AcquireProgress()
is used.

.. versionadded:: 0.7.10
"""
base = os.path.basename(self._records.filename)
destfile = os.path.join(destdir, base)
if _file_is_same(destfile, self.size, self._records.md5_hash):
logging.debug('Ignoring already existing file: %s' % destfile)
return os.path.abspath(destfile)
acq = apt_pkg.Acquire(progress or apt.progress.text.AcquireProgress())
acqfile = apt_pkg.AcquireFile(acq, self.uri, self._records.md5_hash,  # 
type: ignore # TODO: Do not use MD5 # nopep8
  self.size, base, destfile=destfile)
acq.run()

if acqfile.status != acqfile.STAT_DONE:
raise FetchError("The item %r could not be fetched: %s" %
 (acqfile.destfile, acqfile.error_text))

return os.path.abspath(destfile)


Notice the TODO on the apt_pkg.AcquireFile(), but it would probably
break in the same way as in the live-wrapper case a few lines before, on
the self._records.md5_hash item.

The same goes for fetch_source().


Since getting rid of MD5Sum entirely is a topic that comes up on a
regular fashion (with fingers being pointed at jigdo in particular), it
looks to me python-apt should get some attention as well; hence filing
at serious severity. Feel free to adjust as required.


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


Re: Scheduling 10.2

2019-10-22 Thread Cyril Brulebois
Adam D. Barratt  (2019-10-21):
> It's (really past) time to consider a date for the second buster point
> release.

I haven't been paying close attention to -boot over the past few days,
but I don't have anything to get fixed in buster right away AFAICT, so
please take the following with a grain of salt.

> I've listed some suggested dates below; please indicate which you
> would be available for.
> 
> - November 2nd
>   - I'm not available; also means that the freeze would have to be
> this coming weekend

Heavy week+travels before and after, clearly not the best for me.

> - November 9th

Doable (if what I wrote above regarding close to nothing to pu before
the deadline is correct).

> - November 16th
> - November 23rd
> - November 30th
>   - a little late, and I'm not available

All those are good for me.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Re: Download of old CD images not possible?

2019-08-01 Thread Cyril Brulebois
Michael Kesper  (2019-08-01):
> Hi all,
> 
> On 01.08.19 11:46, Samuel Thibault wrote:
> > Michael Kesper, le jeu. 01 août 2019 11:40:59 +0200, a ecrit:
> >> There seems to be currently no way to download other
> >> CD images than current and current-live:
> >>
> >> https://cdimage.debian.org/debian-cd/
> >> There are no links to oldstable or oldoldstable and no paths to other 
> >> releases.
> > 
> > They are in the archive: https://cdimage.debian.org/cdimage/archive/
> 
> Ok but this is not mentioned anywhere on the download pages.
> -> Documentation bug?

Are you sure?
 - https://www.debian.org/releases/stretch/ → “installation information” link
 - https://www.debian.org/releases/stretch/debian-installer/ → links to 
/cdimage/archive/

Also, if you want to talk to people behind cdimage/debian-cd, that would
be… (surprise) debian-cd@lists.debian.org (copied).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Re: Scheduling 10.1 and maybe 9.10

2019-07-14 Thread Cyril Brulebois
Hi,

Jonathan Wiltshire  (2019-07-14):
> So, the first point release for buster would normally be about a month
> after release, or something like 3rd August. But I'm aware that
> already doesn't work for some people, so we might have to get a bit
> creative with it.
> 
> Please indicate your availablility out of:
> 
>  - August 3rd
>  - August 10th
>  - August 17th
> 
> and failing those, let's look ahead as far as:
> 
>  - August 24th
>  - Auguest 31st
>  - September 7th
> 
> We also have a point release of 9.10 to fit in some time - would the
> same day or adjacent weekends be preferable?

Everything should work fine for me regarding d-i (except maybe the last
one on September 7th, as beginning of that week should be busy on the
Tails side; this should work though if you're fine with possibly getting
d-i in on Wed or Thu only).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Unblocking base-installer and debian-installer-utils, D-I Buster RC 3

2019-07-01 Thread Cyril Brulebois
Hi release team,

As mentioned during our last meeting, the last bit I was meaning to fix
before r0 was the (non-)installation of Recommends that was (mostly)
impacting the kernel.

Ben was kind enough to take this off from my shoulders, and two
components needed fixing:

 - base-installer:
   * Enable installation of Recommends while installing the kernel
 (Closes: #929667)
   → 
https://tracker.debian.org/news/1041865/accepted-base-installer-1189-source-into-unstable/

 - debian-installer-utils:
   * Always set APT option if --{with,no}-recommends options are used
 (Closes: #931287)
   → 
https://tracker.debian.org/news/1041866/accepted-debian-installer-utils-1132-source-into-unstable/

The former sets an extra option when installing the kernel, and the
latter makes sure this option is being used. This is slightly different
from what we first thought we could do (that is: a single revert in
base-installer) because that would be more invasive.

For context:
  https://bugs.debian.org/929667#22


I've checked the results comparing the list of packages after a basic,
full disc installation using:
 - a d-i monolithic image built against buster
 - a d-i monolithic image built against buster; plus updated binaries for
   both source packages.

but also by comparing the results of an encrypted LVM installation
using:
 - a d-i monolithic image built against buster with extra
   partman-auto-{crypto,lvm} packages
 - a d-i monolithic image built against buster with extra
   partman-auto-{crypto,lvm} packages; plus updated binaries for both
   source packages.

In both cases, the results were matching our expectations:

+iiapparmor   2.13.2-10amd64user-space parser 
utility for AppArmor
+iifirmware-linux-free3.4  all  Binary firmware for 
various drivers in the Linux kernel

That's why I've just added hints for both packages, and I thought I'd
let you know through this mail.


Even if my tests were as careful as possible, monolithic isn't what's
getting used to build installation images, so we've just agreed with
Steve that we would publish a D-I Buster RC 3 release, so we can make
extra sure. That means once those two packages are in and
debian-installer has been uploaded and dak copy-installer'd.

This last debian-installer build will then be used again for r0,
similarly to what we've done previously.


With extra thanks to Ben, that was really helpful!


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Re: Bug#929476: Debian 9 installation.

2019-05-26 Thread Cyril Brulebois
Hi Mauro,

mb  (2019-05-24):
> The installation in Graphic mode after the language, country and locales 
> stops because cannot find the CD.
> It is not clear what is such "CD"? All installation software isn't in 
> thedebian-9.9.0-amd64-DVD-1.iso  
> <https://cdimage.debian.org/debian-cd/current/amd64/iso-dvd/debian-9.9.0-amd64-DVD-1.iso>
>   file loaded on the USB pen drive?

The ISO image is indeed what you copied onto your USB device. I'm not
sure why there's an issue detecting it here, and I'm cc-ing the
debian-cd folks who are responsible for producing installation images,
and know a lot about this specific area.

Did you verify the checksum of what you downloaded? Wondering whether it
could be corrupted in some way, which could maybe explain why all copy
methods you tried gave the same results.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Re: Bug#923651: debian-installer: U-Boot and device trees missing on debian-testing-arm64-netinst.iso

2019-03-03 Thread Cyril Brulebois
Control: notfound -1 20190302-5

Hi,

Heinrich Schuchardt  (2019-03-03):
> Package: debian-installer
> Version: 20190302-5
> Severity: normal
> 
> Dear Maintainer,
> 
> I used
> https://cdimage.debian.org/cdimage/daily-builds/daily/20190302-5/arm64/iso-cd/debian-testing-arm64-netinst.iso
> to install Debian Buster on a Pine A64 LTS board.
> 
> The CD image lacks U-Boot binaries and device trees.
> 
> It would be preferable to have all installation files on a single medium.

Thanks for your report.

Looping debian-cd@ in.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Re: Scheduling 9.9

2019-02-20 Thread Cyril Brulebois
Steve McIntyre  (2019-02-20):
> On Wed, Feb 20, 2019 at 06:28:05PM +, Jonathan Wiltshire wrote:
> >Hi,
> >
> >Please indicate your availablility out of:
> >
> > - April 13
> > - April 20 (Easter weekend)
> 
> I'm away on holiday for both of these, I'm afraid, and so is chief CD
> tester Andy.
> 
> > - April 27
> 
> But this works.

All dates should be OK for d-i preparations on my side.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Re: Bug#900918: debian-installer: Please make the generated images reproducible

2019-01-21 Thread Cyril Brulebois
Hi Chris,

Chris Lamb  (2019-01-21):
> > That's looking good but I'm seeing new warnings because of gzip's
> > being unhappy about the GZIP environment variable.
> 
> Interesting. However when you say "new" warnings I don't believe my
> patch set actually added/changed this; indeed, it has not changed
> since:
> 
>
> https://salsa.debian.org/lamby/debian-installer/commit/28b863340cc5fd73fbaac85a3fb89e72e842b15c

I think I got stuff mixed up (hard to tell now as I deleted the 10+ GB
of build logs and artefacts I accumulated while testing various things
with your patch series and a couple of extra patches on top of it),
maybe because those warnings were moving around by a line or two in the
logs… Maybe that's why I thought they were new.

Putting the confusion aside, I pushed that to avoid the warnings:
  
https://salsa.debian.org/installer-team/debian-installer/commit/0b025d7f485ecf7ed8969068f98e49d3141d77fd

> … so I'm just checking what you are requesting to be done here.

All in all, I'm not requesting you to do anything more on the d-i level
(there's been quite a lot of work already); just a mere suggestion to
maybe include an example of direct “gzip -n” specification for tar
invokations on the wiki, so that others don't have to look around how to
do that.


> > All gtk files have fontconfig-related cache/uuid changes…
> […]
> > FWIW, dropping all fontconfig-related bits (see attached patch)
> 
> This is #864082 in src:fontconfig — I've been playing whack-a-mole
> with fontconfig over the past 18 months or so and this was a fairly
> recent regression.
> 
> Are you planning on applying this patch to debian-installer.git?
> Naturally, I would prefer if #864082 was applied and in buster, or
> otherwise closed again.

I don't plan to apply that patch; it was only meaning to serve as a
basis to double check there were no other reproducibility issues in the
gtk images.


> > The mini.iso has apparently other changes… I'm attaching the
> > diffoscope output. Could this be because of missing tweaks to the
> > xorriso calls in build/config/x86.cfg?
> 
> Possibly. Let me try and reproduce and reload all of that into my
> brain and get back to you on this; IIRC there was some pushback
> against making it change behaviour only on SOURFE_DATE_EPOCH being
> present so — as you imply — a command-line change might be required.

OK. I think I'd prefer closing this very bug report whenever what's in
git gets uploaded (it's been a long run and thread already), and see
other issues discussed in a fresh bug report; would that work for you?


> > (Including lintian runtime, using pigz on a 8-way machine cuts real
> > time from 8m8s to 4m23s.)

Now less than 4m, after an extra commit:
  
https://salsa.debian.org/installer-team/debian-installer/commit/234058c033ef05c9aab3ced7a7c8cd4917daff9b

> TIL pigz; thanks.
> 
> > Checking what happens [it] seems successive builds with pigz lead to
> > the same results. But those aren't the same as the results generated
> > with gzip. I don't suppose this is going to be a particularly huge
> > problem though?
> 
> Alas, it is a problem in thatfrom the outside nobody will know whether
> one built with pigz or gzip and thus it will be unclear how to
> reproduce the bit-for-bit identical binary. In other words, there is
> currently no ".buildinfo" equivalent here that specifies "I used
> Arch^Wpigz, btw" and got a SHA of $foo.

Ah right, pigz isn't in Build-Depends, so it's not included in the
.buildinfo file…

> One easy solution would be if that, if SOURCE_DATE_EPOCH is present,
> then we force the use of one tool. Although that would regrettably
> mean the lowest common denominator (ie. gzip)  which probably isn't
> the ideal due to the aforementioned performance gain for using pigz.

Right, for a development build (meaning without the generation of the
big debian-installer-images tarball), my gut feeling without specific
clocking data is that half the build time is spent waiting for gzip
to finish its work on a single core. Reproducibility is very nice but
I would definitely hate to lose this huge speed-up.

> Alternatively, we could make pigz a strict build requirement but
> that sounds a little antisocial.

Right.

> Perhaps we need to record the environment after all; again, I will
> reload all of this into my head anyway due to mini.iso (^) so this
> will be top-of-stack again.

Not having looked into the format or tool(s) generating it, would it
be reasonable to have an opt-in mechanism so that a package could
declare “please record the state of this package that might or might not
be installed”. So that pigz could be registered in some way, akin to:
“not-really-in-build-depends-but-oh-look-it-was-present-at-version-X”


Thanks again for your valuable feedback.

Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Re: Bug#900918: debian-installer: Please make the generated images reproducible

2019-01-19 Thread Cyril Brulebois
Control: tag -1 pending

Cyril Brulebois  (2019-01-19):
> The mini.iso has apparently other changes… I'm attaching the diffoscope
> output. Could this be because of missing tweaks to the xorriso calls in
> build/config/x86.cfg? (In which case build/config/arm.cfg might need an
> update as well.) Checking all MINIISO occurrences might also make sense
> I suppose?

FWIW, dropping all fontconfig-related bits (see attached patch) makes it
possible to confirm only mini.iso (regular and gtk ones) are showing
differences now:

installer-amd64/20190119/images/MD5SUMS
installer-amd64/20190119/images/netboot/gtk/mini.iso
installer-amd64/20190119/images/netboot/mini.iso
installer-amd64/20190119/images/SHA256SUMS


I had purged the pigz package during my experiments, just to be sure it
wouldn't interfere:

build/Makefile:gzip = $(shell which pigz >/dev/null 2>&1 && echo "pigz -n 
-T" || echo "gzip -n")

(Including lintian runtime, using pigz on a 8-way machine cuts real time
from 8m8s to 4m23s.)

Checking what happens, and forgetting about the aforementioned mini.iso
images temporarily, it seems successive builds with pigz lead to the
same results. But those aren't the same as the results generated with
gzip. I don't suppose this is going to be a particularly huge problem
though?


Anyway, summarizing: likely more work to be done on the xorriso front,
(on the debian-installer side) for the mini.iso images produced for
netbooting; and fontconfig needs to get fixed in some way at some point
(but I know it's been a long run as well…); but all the rest looks good.

Pushing once I have updated the changelog; marking as pending, thanks!


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
From b1de326f8e97105e97beaf8b14c4af88894a62f0 Mon Sep 17 00:00:00 2001
From: Cyril Brulebois 
Date: Sat, 19 Jan 2019 22:09:23 +
Subject: [PATCH] Remove unreproducible bits due to fontconfig.

---
 build/Makefile | 5 +
 1 file changed, 5 insertions(+)

diff --git a/build/Makefile b/build/Makefile
index 22abaac1d..2e6a0c76c 100644
--- a/build/Makefile
+++ b/build/Makefile
@@ -634,6 +634,11 @@ endif
 		fc-cache -s -y "$(TREE)"; \
 	fi
 
+	# Clean everything to check reproducibility:
+	@echo "HACK ALERT: fontconfig clean-up"
+	rm -v -rf "$(TREE)/var/cache/fontconfig"
+	find "$(TREE)" -name .uuid -print -delete
+
 	# Remove some unnecessary dpkg files.
 	set -e; \
 	for file in `find $(TREE)/var/lib/dpkg/info -name '*.md5sums' -o \
-- 
2.20.1



signature.asc
Description: PGP signature


Re: Bug#900918: debian-installer: Please make the generated images reproducible

2019-01-19 Thread Cyril Brulebois
Cyril Brulebois  (2019-01-19):
> Back to d-i results: I'm seeing small differences in the generated
> -images tarball, that I'll try to investigate. I'll probably push the
> series anyway, as these patches are helping anyway. :)

Here are the differences I'm seeing by building multiple times in the
same sid devel chroot:

installer-amd64/20190119/images/cdrom/gtk/initrd.gz
installer-amd64/20190119/images/hd-media/boot.img.gz
installer-amd64/20190119/images/hd-media/gtk/initrd.gz
installer-amd64/20190119/images/MD5SUMS
installer-amd64/20190119/images/netboot/gtk/debian-installer/amd64/initrd.gz
installer-amd64/20190119/images/netboot/gtk/mini.iso
installer-amd64/20190119/images/netboot/gtk/netboot.tar.gz
installer-amd64/20190119/images/netboot/mini.iso
installer-amd64/20190119/images/SHA256SUMS

*SUMS are no-brainers due to changes in other files.

All gtk files have fontconfig-related cache/uuid changes…

Excluding those, remaining files are:

installer-amd64/20190119/images/hd-media/boot.img.gz
installer-amd64/20190119/images/netboot/mini.iso

The boot.img includes two initrds: initrd.gz and initrdg.gz; the latter
is the one with graphical support, which explains why it's also hit by
the fontconfig cache/uuid problem.

The mini.iso has apparently other changes… I'm attaching the diffoscope
output. Could this be because of missing tweaks to the xorriso calls in
build/config/x86.cfg? (In which case build/config/arm.cfg might need an
update as well.) Checking all MINIISO occurrences might also make sense
I suppose?


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
--- d-i-8/extract/installer-amd64/20190119/images/netboot/mini.iso
+++ d-i-9/extract/installer-amd64/20190119/images/netboot/mini.iso
│┄ Format-specific differences are supported for this file format but none were detected (DOS/MBR boot sector; partition 2 : ID=0xef, start-CHS (0x3ff,254,63), end-CHS (0x3ff,254,63), startsector 240, 5376 sectors; partition 3 : ID=0x1, start-CHS (0x28,0,1), end-CHS (0x2d,63,32), startsector 81920, 12288 sectors)
@@ -21,25 +21,25 @@
 0140: 04b3 07cd 103c 0a75 f1cd 18f4 ebfd   .<.u
 0150:          
 0160:          
 0170:          
 0180:          
 0190:          
 01a0:          
-01b0: f015    bd2c ea2e  8000  .,..
+01b0: f015    f3a8 811b  8000  
 01c0: 0100 003f 2027   0040 0100 00fe  ...? '.@
 01d0:  effe  f000  0015    
 01e0: 0128 013f 202d 0040 0100 0030    .(.? -.@...0
 01f0:        55aa  ..U.
 0200: 4546 4920 5041 5254  0100 5c00   EFI PART\...
-0210: 6d39 8060   0100     m9.`
+0210: eaae c021   0100     ...!
 0220: ff3f 0100   2200     .?.."...
-0230: de3f 0100   e54d 5a45 8789 8e48  .?...MZE...H
-0240: 94f8 d8a5 4fef 9546 0200     O..F
-0250: 8000  8000  2e4a 6260    .Jb`
+0230: de3f 0100   c3d2 f8ef b4ab 7940  .?y@
+0240: bcb6 4ce6 6ef7 1afc 0200     ..L.n...
+0250: 8000  8000  a705 e2f2    
 0260:          
 0270:          
 0280:          
 0290:          
 02a0:          
 02b0:          
 02c0:          
@@ -59,23 +59,23 @@
 03a0:          
 03b0:          
 03c0:          
 03d0:          
 03e0:          
 03f0:          
 0400: a2a0 d0eb e5b9 3344 87c0 68b6 b726 99c7  ..3D..h..&..
-0410: 39a0 b199 1b8e 6243 b6c7 10a4 2fa5 da3f  9.bC/..?
+0410: 169b 0fd6 bf07 7441 9901 f113 33d4 9991  ..tA3...
 0420:     473f 0100    .

Re: Bug#900918: debian-installer: Please make the generated images reproducible

2019-01-19 Thread Cyril Brulebois
Hi Chris,

Chris Lamb  (2019-01-19):
> >  * 0c19a29645a6a3136f3a51da5d5cf1cfcec5fdfb mentions file system
> >ordering only, but that's just the sort part
> 
> I've split this commit and it is much clearer now.

Perfect, thanks.

> >  * 71391967763708055a65ed68999db8f4ea6fc6e6 sets “deb1” as the
> >FAT volume ID; have you checked with people like debian-cd@
> >whether another constant might make more sense?
> 
> Clarified where this comes from in the commmit and in the code
> itself.

Thanks.

> >  * ea1a896181daa3b82c5a62ae31839b457a0dbe0b modifies BUILD_DATE,
> >adding a few characters (“:SS”); that ends up in various help
> >screens
> 
> In my tests, this did not break any visual text wrapping, etc.

Perfect.

> >  * f181b4fe90b9030f515c7e6129239b96131b3926 oh more en_GB, yay.
> 
> Fixed (use 'results' instead).

(I was genuinely happy to learn about the en_GB version; always
struggling to remember how to spell it in French vs. (American) English,
was happy to discover the British English version. :))

> §
> 
> Thank you again for your review. Let me know if you would require any
> further modifications before merging. :-)

That's looking good but I'm seeing new warnings because of gzip's being
unhappy about the GZIP environment variable. This seems to have been
deprecated in gzip 1.8:

gzip: warning: GZIP environment variable is deprecated; use an alias or 
script

I'm attaching the patch I've deployed locally, and it seems to me that
[1] might want an update.

 1. https://wiki.debian.org/ReproducibleBuilds/TimestampsInGzipHeaders

An other solution would be to use tar | gzip instead of passing -I to
tar, but I thought I'd learn about that option in the process. :)

Back to d-i results: I'm seeing small differences in the generated
-images tarball, that I'll try to investigate. I'll probably push the
series anyway, as these patches are helping anyway. :)


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Re: Scheduling 9.7

2019-01-19 Thread Cyril Brulebois
Hi,

Jonathan Wiltshire  (2019-01-18):
> Please indicate your availablility out of:
> 
>  - (Feb 2 unlikely, FOSDEM)
>  - Feb 9
>  - Feb 16

I should be able to make anything work regarding d-i preparations/checks
before the point release, thanks.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Re: Bug#900918: debian-installer: Please make the generated images reproducible

2019-01-18 Thread Cyril Brulebois
Hello Chris,

First off: Thanks a lot for your work, and for your patience.

Chris Lamb  (2019-01-12):
> I would dearly love to have reproducible installer images for buster
> and indeed this would be a good thing to provide and offer, let alone
> announce in the release notes, etc.
> 
> Now that mtools has been sorted out, could this bug & corresponding
> merge request get a closer look? Thanks in advance.

There's a new alpha coming up and I've just spent some time cleaning up
things in debian-installer.git (debhelper compat, standards-version,
etc.) right after the upload; I've almost merged your patch series as
is, but I'd like to raise a few points first. I'm fine with amending the
patches myself, just wanted to check with you first…

 * 0c19a29645a6a3136f3a51da5d5cf1cfcec5fdfb mentions file system
   ordering only, but that's just the sort part AFAIUI; you're also
   resetting some timestamps with the find | xargs touch loop aren't
   you? I'd be happy to see this documented in the commit message as
   well.
   [ basically the clamp_mtimes function in build/Makefile in later
 commits. ]

 * 71391967763708055a65ed68999db8f4ea6fc6e6 sets “deb1” as the FAT
   volume ID; have you checked with people like debian-cd@ whether
   another constant might make more sense? (cc-edd)
   [ also: “determinstic” in commit message. ]
   [ post-scriptum: ok, now I see we already had that in place
 elsewhere; keeping the cc anyway. ]

 * 7c533fa721c3ae89ca81d1336b5928a80ed0d531 thanks for the clarity, much
   appreciated.
   [ also: “becuase” in commit message. ]

 * c35b8688696b1b4563a45d0feeabc3a0c0f2eccb “determinstic” in commit
   message.

 * ea1a896181daa3b82c5a62ae31839b457a0dbe0b modifies BUILD_DATE, adding
   a few characters (“:SS”); that ends up in various help screens
   (hopefully not an issue) but also on some files: version.info,
   disk.lbl, etc.

   Also, coming to think about BUILD_DATE, it's defined with ?= in
   build/config/common but we also set it from debian/rules… I guess
   I'll have to check what happens.

 * f181b4fe90b9030f515c7e6129239b96131b3926 oh more en_GB, yay.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Re: Scheduling 9.6

2018-10-09 Thread Cyril Brulebois
Hi,

Adam D. Barratt  (2018-10-06):
> That didn't work out so well in the end, and in the meantime we rather let
> the ball drop. :-(
> 
> In the interests of getting things moving, some more current
> suggestions:
> 
> - October 20th (means freezing next weekend)
> - October 27th
> - November 3rd
> - November 10th

All of these look good to me. The first one is a bit close (esp. with my
backlog, as you pointed out a few days ago), but that should be doable.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Re: Towards Debian Buster Alpha 4

2018-08-29 Thread Cyril Brulebois
John Paul Adrian Glaubitz  (2018-08-29):
> On 08/29/2018 02:53 PM, Cyril Brulebois wrote:
> > Turns out August was pretty busy as well… and I haven't been able to prepare
> > things as I wanted. Thankfully Holger's been invested with some extra powers
> > and we now have a huge bunch of packages uploaded. Let's see if I can manage
> > to make the new alpha happen in the next few days or weeks.
> 
> There is one regression on powerpc/ppc64 (I know, not release architectures)
> as a result of changes in the kernel packaging (linux-bootwrapper package)
> that I would like to get fixed before the next upload.

OK, I'll try to accomodate that. I guess this would mean you don't need
extra steps on the ports side after the debian-installer upload, if we
managed to make that happen in the right order?

Am I correct in assuming you'll need a fixed src:linux in testing?


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Re: Towards Debian Buster Alpha 4

2018-08-29 Thread Cyril Brulebois
Hi,

Cyril Brulebois  (2018-07-31):
> Being back from a rather busy quarter, I'd like to resume releasing d-i
> more frequently. I'd like to publish a new alpha somewhen during the
> next few days/weeks (if that's fine with debian-cd).
> 
> If you have changes pending in master branches that need uploading, or
> specific packages that need to reach testing, please mention which, and
> why.
> 
> On the release team side, there's an ongoing qt transition. I'll assess
> whether/when it makes sense to freeze all udeb-producing packages once
> I've received feedback regarding needed packages.

Turns out August was pretty busy as well… and I haven't been able to prepare
things as I wanted. Thankfully Holger's been invested with some extra powers
and we now have a huge bunch of packages uploaded. Let's see if I can manage
to make the new alpha happen in the next few days or weeks.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Re: Status and open questions for debian-installer with backports support

2018-08-13 Thread Cyril Brulebois
John Paul Adrian Glaubitz  (2018-08-13):
> Can we also add the patches for choose-mirror and net-retriever to support
> Debian Ports at some point? We have lots of users that are confused that
> debian-installer does not provide a mirror list from where they can choose
> but rather have to type in the mirror information manually.
> 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879145 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879130
> 
> There is also:
> 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879147 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879151

I'm aware of these issues, but it seems to make sense to concentrate
on release architectures, which have a huge user base, and which need
improved hardware support.

There are enough moving parts as it is to avoid adding ports-specific
issues to the mix (as already mentioned in my reply to one of those
bug reports). Please let us figure out how to deal with release archs
and backports first.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Re: Status and open questions for debian-installer with backports support

2018-08-02 Thread Cyril Brulebois
e and the images team anyway.

> > => Choice to make: netinst and maybe CD1(s)? Something else?
> > 
> > It's probably a good idea to consider building matching unofficial
> > image(s) with firmwares embedded. I'm not an expert regarding debian-cd
> > so help is much welcome. Tweaks might be needed to get firmwares
> > installed and/or upgraded from the backports repository, be it to embed
> > them on the image, or to make them available to the installed system.
> 
> Yes, firmware would need to come from backports.
> 
> Since there is no dependency relation between the kernel and firmware
> package, I don't prune old files until they are no longer referenced by
> the kernel version in any supported suite.  So the CD image build would
> only need to use firmware packages from backports, not two different
> versions.

OK, thanks for mentioning this.

I'm not sure about the code path(s) responsible for enabling firmwares
on the installed system based on what was used/available on the
installation image. I hope Steve knows more about that, and will help me
figure out whether some more modifications are needed in some udebs to
make sure we have the right firmware packages/versions installed.

> [...]
> > Last question: how often do we produce such an image? I don't think it's
> > reasonable to do that every time a new major version of linux is made
> > available in the backports repository. Doing that once around the middle
> > of the release cycle would look good to me. This would kind of mimic the
> > “and a half” thing we had in the past. Once we get the process right, we
> > might think about doing so another time or two, but we already have limited
> > humanpower to deal with stable point releases and alphas for testing
> > (at least oldstable is gone now)…
> 
> Doing this even once per release is a nice improvement, but I think
> it's not enough to solve the problem of unsupported hardware (even on
> x86).  And I think the more often this is done, the easier it will get.
> Still, I realise that you are likely to end up doing most of the work,
> and only you can decide how much time to spend on it.

Thanks for sharing this as well. I don't spend enough time on hardware
related topics so I didn't realize how much of an issue that can be.

Given how few changes were needed when I forward-ported my patch series,
it might indeed be rather easy to get more builds with newer kernels.

If we manage to get the debian-cd bits correctly, this might even be
very low maintenance.

But for now I'll concentrate on getting a single such release out, just
to make it official we actually did it.

> > => Question: what to advertise/communicate on? One-shot only is probably
> >a good rule of thumb?
> [...]
> 
> I think what you're proposing is to announce this as a one-off, and not
> to immediately make any promises about regular builds.  If so, I agree.

Thanks for bearing with my poor choice of words. That's exactly what I
meant.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Status and open questions for debian-installer with backports support

2018-08-02 Thread Cyril Brulebois
ain if anything breaks).

We would be able to rely on their having built-in support for backports
(remember, it's only enabled when a specific file is present). We could
then just upload src:debian-installer to stretch-backports (after dak's
been patched to allow that), and point debian-cd to the resulting
images.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Towards Debian Buster Alpha 4

2018-07-30 Thread Cyril Brulebois
Hi,

Being back from a rather busy quarter, I'd like to resume releasing d-i
more frequently. I'd like to publish a new alpha somewhen during the
next few days/weeks (if that's fine with debian-cd).

If you have changes pending in master branches that need uploading, or
specific packages that need to reach testing, please mention which, and
why.

On the release team side, there's an ongoing qt transition. I'll assess
whether/when it makes sense to freeze all udeb-producing packages once
I've received feedback regarding needed packages.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Re: Scheduling 9.5

2018-06-12 Thread Cyril Brulebois
Adam D. Barratt  (2018-06-12):
> Given all of the above, I think the sanest option is to concentrate on
> getting 8.11 done and jessie off our radar and then get 9.5 sorted.
> 
> For suggested dates for 9.5, we know that June 30th is a no-go, Debcamp
> starts on July 21st and then Debconf on the 28th. So that leaves us with:
> 
> - July 7th
> - July 14th
> 
> Are people available for either or both of those dates?

Will try hard to be available for the timing of your choosing.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Re: Scheduling final Jessie point release, 8.11

2018-05-15 Thread Cyril Brulebois
Hi,

Jonathan Wiltshire <j...@debian.org> (2018-05-14):
> According to my records main security support for Jessie can end any
> time after 17th June. 
> 
> So to the security team: do you have a date in mind?
> 
> I also presume that LTS will take over the existing security suites as
> before. [1] lists the current delta between security and o-p-u-new
> which would ideally be as short as possible before the EOL date.
> 
> For everyone else, assuming it'll be soon after that date please
> indicate your availability from:
> 
>  - 23rd Jun
>  - (30th Jun I already know is impossible, for the sake of completeness)
>  - 7th July

Anything June/July-ish should be good for me.


debian-boot@, if there's anything needing a fix in jessie, please follow
up to the list and myself.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Re: Scheduling 9.5

2018-05-15 Thread Cyril Brulebois
Heya,

Jonathan Wiltshire <j...@debian.org> (2018-05-14):
> We're due a point release any day now. Please indicate your
> availablility out of:
> 
>  - May 26th (meaning freeze this coming weekend, which might be a big
>ask)
>  - Jun 2nd (which may require an unusual SRM)
>  - Jun 9th (getting quite a way out of cadence, but maybe that can't
>be helped)

I'm fine with any pick.

I don't think we have any pending ABI bump for linux (this time), and
the stretch branch in debian-installer.git seems quiet, so binNMUing d-i
might be sufficient. I might have missed pu requests for d-i components
though, but hopefully debian-boot@ will correct me if I'm wrong on this.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Re: Scheduling 9.4

2018-02-11 Thread Cyril Brulebois
Julien Cristau <jcris...@debian.org> (2018-02-10):
> we shipped 9.3 a couple of months ago, so we're overdue for 9.4.
> 
> Can you please let us know your availability on the following:
> - March 3
> - March 10
> - March 17
> - March 24
> - March 31

All dates equally OKish for me.

AFAICT:
 - There's a busybox I need to look at.
 - The kernel ABI bump is already in git, and we'll need a source upload
   accordingly.

debian-boot@ people, feel free to mention other things that should be in
the next stretch point release (ideally cc-ing me).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Re: override: downgrade priority of all libraries to optional

2018-01-20 Thread Cyril Brulebois
Hi,

Luca Falavigna <dktrkr...@debian.org> (2018-01-19):
> could you please comment on the request of demoting library priorities
> from required and important to optional?

Just as a reminder, priority is archive-wise so we won't have that in
unstable then in testing, right?

That being said, that looks reasonable enough; a bit curious as to which
things might break, but let's do that, and we'll see…


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Re: override: wget:web/standard

2018-01-20 Thread Cyril Brulebois
Hi,

Luca Falavigna <dktrkr...@debian.org> (2018-01-19):
> could you please comment on the request of demoting wget priority from
> important to standard?

And thanks for checking with us. I might be missing something obvious but
I can't think of anything that would obviously break because of this.
Please do that, and we'll fix any breakages that might pop up.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Bug#882766: Proposal: reinstate automated device selection, blacklisting d-i?

2017-11-26 Thread Cyril Brulebois
Package: grub-installer
Severity: important

Hi,

If records/recollection are correct, we've been prompting for the boot
device to install grub on since this upload:
| grub-installer (1.86) unstable; urgency=low
| 
|   [ Vincent McIntyre ]
|   * Support menu selection of GRUB boot disk. Closes: #706112
| 
|  -- Cyril Brulebois <k...@debian.org>  Mon, 29 Apr 2013 13:53:27 +0200


One of the reasons was that there seemed to be no reliable way to detect
what device we've booted the installer from, and we've had issues with
wiping the d-i installation images for several years before that upload.

Proposal: restore the old device detection, and blacklist anything that
seems to be holding a Debian Installer image. Beware: we don't want to
trigger the same side effects as os-prober did (see os-prober uploads
between 1.72 and 1.75). One way to avoid the read-only mounting could be
to ensure a given token is present in a certain location of Debian
installation images.

Feedback welcome!


KiBi.



Re: Towards Debian Buster Alpha 2

2017-11-24 Thread Cyril Brulebois
Cyril Brulebois <k...@debian.org> (2017-11-24):
> I've just started working on the release from Cambridge, where the
> release team sprint and a mini-DebConf are being held this week.
> Let's see if we can manage to get stuff out the door. :)

Just discovered the glibc migration is still ongoing, so I'll have to
try my luck another time. :)


KiBi.


signature.asc
Description: PGP signature


Re: Towards Debian Buster Alpha 2

2017-11-24 Thread Cyril Brulebois
Heya,

Cyril Brulebois <k...@debian.org> (2017-10-31):
> Now that casulana is set up and knows how to build installation images,
> Steve gave me a green light for a new alpha release. We've been having
> a few issues on dillon (see previous mails on debian-boot@), but maybe
> I'm not going to block the release on fixing those.
> 
> I'll try and find some time this week to assess whether releasing looks
> feasible.

I've just started working on the release from Cambridge, where the release
team sprint and a mini-DebConf are being held this week. Let's see if we
can manage to get stuff out the door. :)


KiBi.


signature.asc
Description: PGP signature


Towards Debian Buster Alpha 2

2017-10-31 Thread Cyril Brulebois
Hi folks,

Now that casulana is set up and knows how to build installation images,
Steve gave me a green light for a new alpha release. We've been having
a few issues on dillon (see previous mails on debian-boot@), but maybe
I'm not going to block the release on fixing those.

I'll try and find some time this week to assess whether releasing looks
feasible.


KiBi.


signature.asc
Description: PGP signature


Re: Bug#879215: stretch-pu: package live-config/5.20170112

2017-10-29 Thread Cyril Brulebois
Hi Adam,

Adam D. Barratt <a...@adam-barratt.org.uk> (2017-10-29):
> On Fri, 2017-10-20 at 17:02 +0200, Cyril Brulebois wrote:
> > 
> > We've been having issues with KDE live images, and since this popped
> > up on #debian-cd again, a few days ago, I've looked into backporting
> > a fix from unstable to stable. The source debdiff is attached, and
> > here's the  changelog entry:
> > > live-config (5.20170112+deb9u1) stretch; urgency=medium
> > > 
> > >   [ Cyril Brulebois ]
> > >   * Cherry-pick the change below to improve KDE live images.
> > > 
> > >   [ Алексей Шилин ]
> > >   * Add components/0085-sddm to configure autologin for KDE /
> > > Plasma live images. Closes: #865382.
> 
> The meta-data for that bug is slightly unhelpful, as it's filed against
> the debian-live pseudo-package, so there's no useful version tracking.

I think I pondered fixing that, but wasn't sure because the bug was
archived already. I can definitely fix this along with uploading.


KiBi.


signature.asc
Description: PGP signature


Bug#879215: stretch-pu: package live-config/5.20170112

2017-10-20 Thread Cyril Brulebois
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

[ debian-cd/debian-live in copy. ]

Hi,

We've been having issues with KDE live images, and since this popped up
on #debian-cd again, a few days ago, I've looked into backporting a fix
from unstable to stable. The source debdiff is attached, and here's the 
changelog entry:
| live-config (5.20170112+deb9u1) stretch; urgency=medium
| 
|   [ Cyril Brulebois ]
|   * Cherry-pick the change below to improve KDE live images.
| 
|   [ Алексей Шилин ]
|   * Add components/0085-sddm to configure autologin for KDE / Plasma live
| images. Closes: #865382.
| 
|  -- Cyril Brulebois <k...@debian.org>  Fri, 20 Oct 2017 16:53:40 +0200

Until this gets reviewed and ACK/NACKed by the release team, I've pushed
a stretch branch to live-config.git, except for the final “dch -r”, in
case something needs fixing before the upload.

Thanks for your attention & time.


KiBi.
diff -Nru live-config-5.20170112/components/0085-sddm 
live-config-5.20170112+deb9u1/components/0085-sddm
--- live-config-5.20170112/components/0085-sddm 1970-01-01 01:00:00.0 
+0100
+++ live-config-5.20170112+deb9u1/components/0085-sddm  2017-10-19 
13:18:15.0 +0200
@@ -0,0 +1,81 @@
+#!/bin/sh
+
+## live-config(7) - System Configuration Components
+## Copyright (C) 2006-2015 Daniel Baumann <m...@daniel-baumann.ch>
+##
+## This program comes with ABSOLUTELY NO WARRANTY; for details see COPYING.
+## This is free software, and you are welcome to redistribute it
+## under certain conditions; see COPYING for details.
+
+
+#set -e
+
+Cmdline ()
+{
+   # Reading kernel command line
+   for _PARAMETER in ${LIVE_CONFIG_CMDLINE}
+   do
+   case "${_PARAMETER}" in
+   live-config.noautologin|noautologin)
+   LIVE_CONFIG_NOAUTOLOGIN="true"
+   ;;
+
+   live-config.nox11autologin|nox11autologin)
+   LIVE_CONFIG_NOX11AUTOLOGIN="true"
+   ;;
+
+   live-config.username=*|username=*)
+   LIVE_USERNAME="${_PARAMETER#*username=}"
+   ;;
+   esac
+   done
+}
+
+Init ()
+{
+   # Disables both console and graphical autologin.
+   case "${LIVE_CONFIG_NOAUTOLOGIN}" in
+   true)
+   exit 0
+   ;;
+   esac
+
+   # Disables graphical autologin, no matter what mechanism
+   case "${LIVE_CONFIG_NOX11AUTOLOGIN}" in
+   true)
+   exit 0
+   ;;
+   esac
+
+   # Checking if package is installed or already configured
+   if [ ! -e /var/lib/dpkg/info/sddm.list ] || \
+  [ -e /var/lib/live/config/sddm ]
+   then
+   exit 0
+   fi
+
+   echo -n " sddm"
+}
+
+Config ()
+{
+   # autologin
+   if [ -n "${LIVE_USERNAME}" ]
+   then
+   cat > /etc/sddm.conf << EOF
+[Autologin]
+User=${LIVE_USERNAME}
+Session=plasma.desktop
+EOF
+   fi
+
+   # Avoid xinit
+   touch /var/lib/live/config/xinit
+
+   # Creating state file
+   touch /var/lib/live/config/sddm
+}
+
+Cmdline
+Init
+Config
diff -Nru live-config-5.20170112/debian/changelog 
live-config-5.20170112+deb9u1/debian/changelog
--- live-config-5.20170112/debian/changelog 2017-01-12 18:11:22.0 
+0100
+++ live-config-5.20170112+deb9u1/debian/changelog  2017-10-20 
16:53:40.00000 +0200
@@ -1,3 +1,14 @@
+live-config (5.20170112+deb9u1) stretch; urgency=medium
+
+  [ Cyril Brulebois ]
+  * Cherry-pick the change below to improve KDE live images.
+
+  [ Алексей Шилин ]
+  * Add components/0085-sddm to configure autologin for KDE / Plasma live
+images. Closes: #865382.
+
+ -- Cyril Brulebois <k...@debian.org>  Fri, 20 Oct 2017 16:53:40 +0200
+
 live-config (5.20170112) unstable; urgency=medium
 
   * Team upload.


Re: syslinux: sponsor request

2017-10-17 Thread Cyril Brulebois
Hi Lukas,

Lukas Schwaighofer  (2017-10-17):
> sorry to ask for yet another sponsoring so soon.  Two days ago upstream
> merged the fix for allowing extlinux to boot from ext4 filesystems with
> the 64bit feature enabled, which I'd like to get uploaded soon.
> 
> With the patch applied, I can no longer reproduce the ext4+64bit
> problem, so I'm confident the fix works.  Booting from ext2/3 and btrfs
> still works fine. I've updated syslinux in our git repository
> accordingly:
> 
> https://anonscm.debian.org/git/debian-cd/syslinux.git
> 
> 
> Apart from the ext4 fix, I've also dropped my own patch for linking
> against the newer gnu-efi version in favor of the cleaner one that was
> proposed upstream.
> 
> I've set urgency to medium this time, as I don't want to delay the
> creation of testing images not suffering from Bug #857597 [1].
> Lukas
> 
> [1] https://bugs.debian.org/857597

I've just sponsored your upload, thanks!

Please push an appropriate tag for this commit:
  ce704619daaa2f973e6d569c0e0ac713984529e6


KiBi.

PS: I only read debian-cd@ infrequently when my attention is drawn to
it, like the cc in the subsequent mail. Please cc me if you need
me to see a specific reply/subthread.


signature.asc
Description: PGP signature


Re: syslinux: updating in stretch?

2017-10-17 Thread Cyril Brulebois
Hi Lukas,

And thanks for your mail. I'm adding debian-boot@ for their information.

Lukas Schwaighofer  (2017-10-17):
> as it turns out, syslinux in stretch is in a quite sorry state.  To
> summarize:
> 
> 1. Booting from ext4 partitions created with Debian stretch does not
>work, because ext4's 64bit feature is enabled by default (since
>Debian stretch) and not supported by syslinux [1].
> 2. Booting from btrfs does not work [2].
> 3. A bug in the isolinux isohybrid MBR causing boot failures with some
>old BIOS [3].
> 4. Booting from xfs does not work (which was already the case in
>jessie, so not a regression in stretch) [4].
> 
> You will notice that this does not really leave any modern Unix
> filesystem for syslinux/extlinux to boot from… from the above problems,
> 1-3 are a regression compared to Debian jessie.
> 
> [1] https://bugs.debian.org/833057
> [2] https://bugs.debian.org/865462
> [3] I didn't think to open a separate bug against syslinux, which would
> have been the right thing to do… the bug against debian-cd, which
> is affected by this problem, holds relevant information:
> https://bugs.debian.org/857597

It might be a good idea to have a bug report against syslinux as well,
which can be used for version tracking purposes, which is most
appreciated by people handling stable-proposed-updates requests (we
usually consider this mandatory, even if we sometimes let a few
exceptions go through).

> [4] https://bugs.debian.org/803938
> 
> 
> Problems 1 and 2 have an upstream fix each [5, 6] which is pretty small
> in size.  I'm able to locally reproduce each of the two problems and
> also confirm that the respective patches fix the problems.

On top of the stretch package? It's always reassuring for stable release
managers to have people actually test packages for stable.

> Problem 3 also has a small and self-contained upstream fix.  And
> although I have no way to test this myself, the built isohdpfx.bin file
> (with the fix applied) is identical to a known-good and tested version.

That seems reassuring enough as far as I'm concerned.

> Problem 4 is fixed upstream as well (which I have not tested yet), but
> the number of changes for that is pretty high.  Since this is both a
> large patch and a not a regression from jessie, I don't intend to fix
> this in Debian stretch.

That seems like an appropriate course of action indeed.

> [5] 
> http://git.zytor.com/syslinux/syslinux.git/commit/?id=af7e95c32cea40c1e443ae301e64b27f068b4915
> [6] 
> http://git.zytor.com/syslinux/syslinux.git/commit/?id=548386049cd41e887079cdb904d3954365eb28f3
> 
> 
> The current version in unstable contains the patches for 2 and 3
> already and I've just requested sponsorship for another update which
> also fixes 1.  Provided we do not find any regressions related to the
> fixes for problems 1-3, I would like to push those patches [7, 8, 9]
> to the version in Debian stretch in the next point release.
> 
> I know the next point release is still ~6 weeks off, but bootloader
> changes are obviously critical.  So I wanted to raise this issue well
> before the deadline to get an idea how (or if) I should proceed:
> 
> * Is this a reasonable request, or are these changes too dangerous
>   for a point release anyways?

Your proposed changes fit the stable-proposed-updates criteria exactly,
with fixes in unstable, backports/cherry-picks to stretch already tested
and confirmed good, and reasonably-sized diffs. Really nice!

> * What kind of testing is required / expected so these changes can be
>   considered?

I think debian-cd@ is most qualified on this topic, I'm not sure d-i
uses syslinux for many things except for booting from an ISO anyway.
Consequently, what follows is just generic advice:

If you get a green light from debian-cd@, I think you only need to:
 - open a bug report for bug #3 (see my first paragraph);
 - open a pu request with a source debdiff against the package in
   stretch with an appropriate version number (probably
   3:6.03+dfsg-14.1+deb9u1); including as many details as in this
   mail would probably do the trick.


KiBi.


signature.asc
Description: PGP signature


Re: Bug#878483: task-gnome-desktop: Drop extra Recommends

2017-10-13 Thread Cyril Brulebois
Hi debian-cd@,

Will the patch quoted below change anything for the installation image
generation?

ISTR we've had some fun regarding network-manager but I don't remember
the details exactly.

Thanks.

Jeremy Bicha  (2017-10-13):
> 

> From 6013d2f6f532ececf055e6cf926b3afa2ad99297 Mon Sep 17 00:00:00 2001
> From: Jeremy Bicha 
> Date: Fri, 13 Oct 2017 19:42:10 -0400
> Subject: [PATCH] Drop task-gnome-desktop Recommends already handled by gnome
> 
> - Let's let the gnome metapackage recommend packages instead of
>   task-gnome-desktop.
> - Drop Synaptic since it doesn't work in Wayland. See bug 8183366.
>   (Alternatives are gnome-software which is already installed, or
>   gnome-packagekit, or switch to the GNOME on Xorg session.)
> - The 'gnome' metapackage intentionally installs specific
>   LibreOffice packages instead of the 'libreoffice' metapackage.
> 
> Closes: #878483
> ---
>  debian/control | 14 --
>  1 file changed, 14 deletions(-)
> 
> diff --git a/debian/control b/debian/control
> index ef6a0a48..f3ba5c35 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -73,18 +73,6 @@ Recommends:
>  # The full gnome desktop environment should be included if possible
>  # even if the larger gnome metapackage doesn't fit.
>   gnome,
> -# GNOME support in LibreOffice
> - libreoffice-gnome,
> - libreoffice-evolution,
> -# temporarily moved from task-desktop due to #525077
> - gimp,
> -# Package management.
> - synaptic,
> -# firefox is the most popular web browser at the moment,
> -# although both gnome and kde offer their own too
> - firefox-esr | firefox,
> -# libreoffice is the best word processor / office suite at the moment
> - libreoffice,
>  # make help menu work
>   libreoffice-help-en-us,
>  # make thesaurus work
> @@ -93,8 +81,6 @@ Recommends:
>   hunspell-en-us,
>  # make hyphenation work
>   hyphen-en-us,
> -# we need a working network setup at least
> - network-manager-gnome,
>  
>  Package: task-kde-desktop
>  Architecture: all
> -- 
> 2.14.1
> 


KiBi.


signature.asc
Description: PGP signature


Re: Bug#874251: installation-reports: Debian 9.1 installer fails on HP ProLiant DL360 G4 with HP Smart Array 6i

2017-09-04 Thread Cyril Brulebois
Hi,

Adding kernel maintainers and debian-cd to the loop.

rpr //  (2017-09-04):
> Package: installation-reports
> Severity: important
> 
> -- Package-specific info:
> 
> Boot method: USB flash drive
> Image version: 
> https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-9.1.0-amd64-netinst.iso
> (2017-07-22)
> Date: 2017-08-26 17:00 UTC
> 
> Machine: HP ProLiant DL360 G4 with HP Smart Array 6i
> Partitions: 
> 
> 
> Base System Installation Checklist:
> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> 
> Initial boot:   [E]
> Detect network card:[O]
> Configure network:  [O]
> Detect CD:  [O]
> Load installer modules: [O]
> Clock/timezone setup:   [O]
> User/password setup:[O]
> Detect hard drives: [O]
> Partition hard drives:  [O]
> Install base system:[O]
> Install tasks:  [O]
> Install boot loader:[O]
> Overall install:[O]
> 
> Comments/Problems:
> Booting installer with default options locks up after
> Loading /install.amd/vmlinuz... ok
> Loading /install.amd/initrd.gz... ok
> 
> Booting in expert mode gives an error about "NMI watchdog: BUG: soft
> lockup" - see the screenshot in the attachment.
> 
> Booting and running installer was successful after adding acpi=off
> kernel parameter.

Is that something to be fixed on the kernel side? Or some buggy UEFI
that would need a workaround maybe?


KiBi.


signature.asc
Description: PGP signature


Re: Bug#867898: debian-installer-netboot-images: debian-installer-9-netboot-amd64 scsi modules missing. Netboot image unusable

2017-07-12 Thread Cyril Brulebois
Hi,

Paschedag, Robert  (2017-07-12):
> thank you for your hints on the packages, that *are* available for
> amd64. The package we need is
> 
> scsi-modules-4.9.0-3-amd64-di_4.9.30-2_amd64.udeb
> 
> this one contains the needed modules for the LSI logic controller (and
> several other)
> 
> ...
> ./lib/modules/4.9.0-3-amd64/kernel/drivers/message/
> ./lib/modules/4.9.0-3-amd64/kernel/drivers/message/fusion/
> ./lib/modules/4.9.0-3-amd64/kernel/drivers/message/fusion/mptbase.ko
> ./lib/modules/4.9.0-3-amd64/kernel/drivers/message/fusion/mptfc.ko
> ./lib/modules/4.9.0-3-amd64/kernel/drivers/message/fusion/mptsas.ko
> ./lib/modules/4.9.0-3-amd64/kernel/drivers/message/fusion/mptscsih.ko
> ./lib/modules/4.9.0-3-amd64/kernel/drivers/message/fusion/mptspi.ko

Ah, apt-file search is still a big pain as it doesn't look into udebs even
if I have udeb sources configured… debian-kernel@, sorry for the noise.

> But this package is also missing on the "release" DVDs for "amd64".
> Nearly every other architecture has this package within an image
> (whether "netinst" oder "DVD"). See
> https://cdimage-search.debian.org/?search_area=release=simple=scsi-modules=Search&.cgifields=search_area&.cgifields=type

Adding debian-cd@ accordingly.

> I apologize, if the message headers are lost. Somehow, your answer did
> not yet reach my mailbox

(With or without this issue) it would be helpful to cc me in your replies.


KiBi.


signature.asc
Description: Digital signature


Re: Scheduling 9.1, maybe 8.9

2017-06-25 Thread Cyril Brulebois
Hi,

Jonathan Wiltshire  (2017-06-25):
> A month or so from 9.0 bring us to about 15th July. How would any of
> these suit? Is 8.9 at the same time feasible?
> 
> 8/9 July (probably a bit soon)
> 15/16 July
> 22/23 July

I should be equally busy on all weeks leading to these week-ends, so no
preferences from me.


KiBi.


signature.asc
Description: Digital signature


Re: Bug#864970: www.debian.org: downloads page is missing download links

2017-06-18 Thread Cyril Brulebois
Control: tag -1 pending

Hi,

Stuart Prescott  (2017-06-18):
> Package: www.debian.org
> Severity: important
> 
> Hi!
> 
> in amongst all the excitement of the stretch release, the downloads page [1]
> has lost most of the download links. The only link currently displayed is
> the "multi-arch" image, which isn't being produced for 9.0 [2]
> 
> [1]  https://www.debian.org/CD/http-ftp/#stable

The missing define-tag for stretch-as-the-new-stable was just added to
installer.wml, and Paul rebuilt the website so that it's taken into
account. Marking this as pending…

(And note taken for the next release cycle.)

> [2]  https://wiki.debian.org/Teams/DebianCD/ReleaseTesting/Stretch (Errata #2)

Are we expected to see improvements in this area, or should we get rid
of the multi-arch dvd link as well? (… hence not closing this bug report
entirely). Added debian-cd@ to the loop.


KiBi.


signature.asc
Description: Digital signature


Bug#843943: debian-cd: please mention the dinstall serial in a trace file

2017-04-24 Thread Cyril Brulebois
Steve McIntyre  (2017-04-25):
> Looks good (ish!) The code's fine, but I'll move it to the setup.git
> repo. The code in debian-cd/contrib is just a convenience copy for
> publishing what we do in the package.

Alright, thanks!

> >> Also, as as side question, do we prevent the mirror from being updated
> >> during the n-hours build of all images?
> >
> >Answer welcome. :)
> 
> Nope. For any given architecture build, we do ~all the parsing
> up-front so it's going to be consistent. But from one arch to the next
> it's possible that things will update.

It looks good enough, yeah; at least it seems to have worked just fine
so far. :-)

Thanks again.


KiBi.


signature.asc
Description: Digital signature


Bug#843943: debian-cd: please mention the dinstall serial in a trace file

2017-04-23 Thread Cyril Brulebois
Hi,

Cyril Brulebois <k...@debian.org> (2017-04-13):
> Cyril Brulebois <k...@debian.org> (2016-11-11):
> > Since pettersson has a mirror with project/trace, which gives us access
> > to archive serial, it would be nice to have a look when the build starts
> > and to report this, maybe in a trace file alongside cdimage.debian.org?
> 
> Here's a prospective and untested patch.
> 
> ISTR we (ab)use cronjob.weekly for release builds, but feel free to
> test/adjust before pushing to the repository.
> 
> > Also, as as side question, do we prevent the mirror from being updated
> > during the n-hours build of all images?
> 
> Answer welcome. :)

Friendly ping. The sooner we get this merged, the sooner I can get easier,
quicker, and possibly more complete tools for release management.

Thanks already.


KiBi.


signature.asc
Description: Digital signature


Bug#843943: debian-cd: please mention the dinstall serial in a trace file

2017-04-13 Thread Cyril Brulebois
Cyril Brulebois <k...@debian.org> (2016-11-11):
> Since pettersson has a mirror with project/trace, which gives us access
> to archive serial, it would be nice to have a look when the build starts
> and to report this, maybe in a trace file alongside cdimage.debian.org?

Here's a prospective and untested patch.

ISTR we (ab)use cronjob.weekly for release builds, but feel free to
test/adjust before pushing to the repository.

> Also, as as side question, do we prevent the mirror from being updated
> during the n-hours build of all images?

Answer welcome. :)


KiBi.
From 07ad313e6d7ff5948c0ceed8b066687a580751b9 Mon Sep 17 00:00:00 2001
From: Cyril Brulebois <k...@debian.org>
Date: Thu, 13 Apr 2017 14:40:50 +0200
Subject: [PATCH] Store archive serial in trace directory.

Mostly useful for the Debian Installer release manager.

Closes: #843943
---
 contrib/common.sh  | 9 +
 contrib/cronjob.weekly | 5 +
 2 files changed, 14 insertions(+)

diff --git a/contrib/common.sh b/contrib/common.sh
index 9190a37..3ce712e 100644
--- a/contrib/common.sh
+++ b/contrib/common.sh
@@ -147,3 +147,12 @@ arch_has_firmware () {
 done
 return 1
 }
+
+get_archive_serial () {
+trace_file="$MIRROR/project/trace/ftp-master.debian.org"
+if [ -f "$trace_file" ]; then
+awk '/^Archive serial: / {print $3}' "$trace_file"
+else
+echo 'unknown'
+fi
+}
diff --git a/contrib/cronjob.weekly b/contrib/cronjob.weekly
index 5019508..f16e19e 100755
--- a/contrib/cronjob.weekly
+++ b/contrib/cronjob.weekly
@@ -64,6 +64,11 @@ if lockfile -r0 $BUILDLOCK ; then
 echo "git update debian-cd"
 cd debian-cd && git pull ; cd ..
 
+# Keep track of the serial for the archive we're building against,
+# for later archive diffing for release announce preparation:
+serial=$(get_archive_serial)
+echo "$serial" > $PUBDIRJIG/trace/archive-serial
+
 # Work out the default desktop, and do *not* build a CD1 for that
 # desktop - it'll be done in the full set anyway
 TASKSEL_DEB=$(./debian-cd/tools/which_deb ${MIRROR} testing task-desktop binary)
-- 
2.1.4



signature.asc
Description: Digital signature


Re: 8.8 planning

2017-03-16 Thread Cyril Brulebois
Hi,

Julien Cristau  (2017-03-14):
> It's time to start thinking about our next stable point release.  Here
> are some dates, please let us know which ones would work.
> 
> * April 8-9

Not ideal for me.

> * April 15-16
> * April 22-23
> * April 29-30
> * May 6-7

All those should work.


KiBi.


signature.asc
Description: Digital signature


Re: Bug#852002: override: libncurses5:libs/important

2017-02-15 Thread Cyril Brulebois
Hi,

Ansgar Burchardt  (2017-02-14):
> Control: retitle -1 override: libncurses5:libs/optional
> 
> Andreas Henriksson writes:
> > On Fri, Jan 20, 2017 at 06:05:15PM +0100, Sven Joachim wrote:
> > [...]
> >> Please downgrade the priority so that libncurses5 does not get installed
> >> in minimal chroots anymore and can be autoremoved in existing chroots by
> >> apt.
> >
> > Subject says "override: libncurses5:libs/important" but please
> > consider downgrading it to even lower than important!
> >
> > The important priority will pull it into a regular debootstrap.
> > It's a library, why now have dependencies just pull it in if needed?!
> >
> > (Yes, sure there might be some important package depending on it
> > and policy says yada, yada... but sooner or later policy
> > will get fixed -> #758234 )
> 
> I agree that we should try to downgrade libraries to Priority:
> optional if possible.
> 
> I would still like an ACK from the d-i team (X-Debbugs-Cc'ed).

It's rather late in the release cycle to be cleaning up things like
that… but since it's being pulled due to:
  [others] → udev (Priority:important → propcs (Priority:important)
  man-db (Priority:standard) → bsdmainutils
  openssh-client → libedit2

I think we should be able to do that nonetheless. Adding debian-cd@ to
the loop to make sure this wouldn't break image building and stuff we
need to put into various images.


KiBi.


signature.asc
Description: Digital signature


Re: Bug#855035: debian-installer: https does not work with stretch rc2 installer

2017-02-15 Thread Cyril Brulebois
Hi Hilko,

Cyril Brulebois <k...@debian.org> (2017-02-15):
> Eww, we have this code right now already:
> | # If we need SSL certificates, copy them in now.
> | if [ "$PROTOCOL" = "https" ] && [ -d /etc/ssl/certs ]; then
> | if find /etc/ssl/certs/ -name \*.crt | grep -q .; then
> | mkdir -p /target/usr/local/share/ca-certificates
> | cp -a /etc/ssl/certs/*.crt 
> /target/usr/local/share/ca-certificates/
> | chroot /target update-ca-certificates || true
> | fi
> | fi
> 
> → It's likely not getting run with netinst images…
> 
> I think I'll file this as another bug report for reference.

Actually I've fixed it along the way, and I've just uploaded
base-installer 1.168 with these two fixes:
  
https://anonscm.debian.org/cgit/d-i/base-installer.git/commit/?id=ee95d8a89a0a95f7d9082a83b15ee5a406f99c43
  
https://anonscm.debian.org/cgit/d-i/base-installer.git/commit/?id=7a79b4556436d5f8a40f6aa161fc4237794182d4

(Note: I haven't tested the codepath for the second issue.)

Testing with the same parameters as you mentioned earlier shows the
issue with a netinst rc2 image, and a fixed behaviour with a rebuilt
image. Do you want to give it a try, or will you wait for rc3?


KiBi.


signature.asc
Description: Digital signature


Re: Bug#855035: debian-installer: https does not work with stretch rc2 installer

2017-02-15 Thread Cyril Brulebois
Cyril Brulebois <k...@debian.org> (2017-02-15):
> I should clarify a bit: we can't look at PROTOCOL at this point, since a
> netinst with mirror/protocol=https is going to use local files on the
> cdrom; if it was using https, debootstrap would do the job already
> (except it would fail to load both packages right now since Steve only
> added them to the images a few hours ago).

Eww, we have this code right now already:
|   # If we need SSL certificates, copy them in now.
|   if [ "$PROTOCOL" = "https" ] && [ -d /etc/ssl/certs ]; then
|   if find /etc/ssl/certs/ -name \*.crt | grep -q .; then
|   mkdir -p /target/usr/local/share/ca-certificates
|   cp -a /etc/ssl/certs/*.crt 
/target/usr/local/share/ca-certificates/
|   chroot /target update-ca-certificates || true
|   fi
|   fi

→ It's likely not getting run with netinst images…

I think I'll file this as another bug report for reference.


KiBi.


signature.asc
Description: Digital signature


Re: Bug#855035: debian-installer: https does not work with stretch rc2 installer

2017-02-15 Thread Cyril Brulebois
Cyril Brulebois <k...@debian.org> (2017-02-14):
> Philipp Kern <pk...@debian.org> (2017-02-14):
> > Given that Steve added it to the CD's force list, what about adding the two
> > packages to $include in the https check that already exists in
> > bootstrap-base.postinst (to set the proxy correctly)? I don't see a good way
> > of adding the two packages after debootstrap ran but telling debootstrap to
> > pull them in upon initial installation, assuming the media has it, seems
> > feasible to me.
> 
> That's exactly the solution I came up with while thinking about it. Since
> you agree I suppose this makes it a reasonable solution, and I'll be
> implementing and checking that in a moment. Thanks for the quick feedback.

I should clarify a bit: we can't look at PROTOCOL at this point, since a
netinst with mirror/protocol=https is going to use local files on the
cdrom; if it was using https, debootstrap would do the job already
(except it would fail to load both packages right now since Steve only
added them to the images a few hours ago).

So I'm adding a mirror/protocol check instead, and I have to adjust
include/exclude handling accordingly.

KiBi.


signature.asc
Description: Digital signature


Re: Bug#855035: debian-installer: https does not work with stretch rc2 installer

2017-02-14 Thread Cyril Brulebois
Philipp Kern  (2017-02-14):
> Given that Steve added it to the CD's force list, what about adding the two
> packages to $include in the https check that already exists in
> bootstrap-base.postinst (to set the proxy correctly)? I don't see a good way
> of adding the two packages after debootstrap ran but telling debootstrap to
> pull them in upon initial installation, assuming the media has it, seems
> feasible to me.

That's exactly the solution I came up with while thinking about it. Since
you agree I suppose this makes it a reasonable solution, and I'll be
implementing and checking that in a moment. Thanks for the quick feedback.


KiBi.


signature.asc
Description: Digital signature


Re: Bug#855035: debian-installer: https does not work with stretch rc2 installer

2017-02-13 Thread Cyril Brulebois
Thanks Hilko.

Hilko Bengen  (2017-02-13):
> Here. I have stripped out the kernel messages.

Nothing interesting there, same locally with my own tests with your boot
parameters. I guess it wouldn't hurt if we had more details in syslog
from bootstrap-base…

Anyway, adding a few debug bits, I can reproduce your issue and I think
it's quite clear: we run debootstrap from bootstrap-base using
file:///cdrom so we're not hitting the https code path. Cc-ing Philipp
and Marga who worked on adding https support since they might have ideas
on how to fix this.


KiBi.


signature.asc
Description: Digital signature


Re: Bug#855035: debian-installer: https does not work with stretch rc2 installer

2017-02-13 Thread Cyril Brulebois
Hi Hilko,

And thanks for your report.

Hilko Bengen  (2017-02-13):
> Dear Maintainers,
> 
> while working to build a more automated installation process around d-i
> Stretch RC 2 (using the netinst iso), I tried to preseed the following:
> 
> ,
> | choose-mirror-bin mirror/protocol   select  https
> | choose-mirror-bin mirror/https/hostname string  deb.debian.org
> | choose-mirror-bin mirror/https/directorystring  /debian
> `
> 
> This does not work as I expected: According to the log, fetching the
> Release files using wget seems to work, but the in-target apt emits the
> following:
> 
> ,
> | Reading package lists...
> | 
> | E: The method driver /usr/lib/apt/methods/https could not be found.
> | E: Failed to fetch https://deb.debian.org/debian/dists/stretch/InRelease
> | E: Some index files failed to download. They have been ignored or old
> | ones used instead.
> `
> 
> I guess that adding apt-transport-https to the base system (and
> including it in the netinst .ISO) ought to fix this problem.

Strange, debootstrap already has this:
| case $MIRRORS in
| https://*)
| base="$base apt-transport-https ca-certificates"
| ;;
| esac

Please share your installer's syslog?

Anyway, putting debian-cd@ in copy since package lists might need an
update for those two packages, so that they have a high(er) chance of
being available on installation images.


KiBi.


signature.asc
Description: Digital signature


Re: Bug#851514: Installer using virtio disk or CD-ROM fails to find itself

2017-02-04 Thread Cyril Brulebois
Josh Triplett  (2017-01-15):
> Package: installation-reports
> Severity: normal
> 
> An installation on a virtual machine booting the installer from a virtio
> disk or CDROM drive results in a "Detect and mount CD-ROM" failure ("No
> common CD-ROM drive was detected.") after the language prompts.  To
> reproduce this, try the following:
> 
> qemu-img create debian.img 10G
> kvm -m 1G -drive 
> file=debian-stretch-DI-rc1-amd64-netinst.iso,media=cdrom,if=virtio,format=raw 
> -drive file=debian.img,if=virtio,format=raw

Maybe it'd make sense to have some virtio modules in the cdrom image?
Right now, they're available here:

build/pkg-lists/cdrom/{ alpha.cfg arm64.cfg ppc64el.cfg }
build/pkg-lists/generic/{ s390.cfg s390x.cfg }
build/pkg-lists/hd-media/{ armhf.cfg }
build/pkg-lists/netboot/{ all? }

Adding debian-cd@ to the loop for input.


KiBi.


signature.asc
Description: Digital signature


Re: Planning for d-i Stretch Alpha 9

2016-12-17 Thread Cyril Brulebois
Hi,

Cyril Brulebois <k...@debian.org> (2016-11-21):
> Ben Hutchings <b...@decadent.org.uk> (2016-11-20):
> > Yes, there will be an ABI bump in the next upload to unstable
> > (probably within the next week).
> 
> Thanks! I'll wait for that to happen & migrate to testing before
> preparing for the next d-i release.

FWIW linux migrated a few days ago so I'll start working on a release
as soon as my free time permits. Probably somewhen around Christmas.

As usual (sadly) I'm way behind reading/checking what happens on
debian-boot@ so feel free to mention specific things you would want me
to notice, through a mail cc'd to <k...@debian.org>.


KiBi.


signature.asc
Description: Digital signature


Re: Planning for d-i Stretch Alpha 9

2016-11-21 Thread Cyril Brulebois
Ben Hutchings <b...@decadent.org.uk> (2016-11-20):
> On Sun, 2016-11-20 at 04:06 +0100, Cyril Brulebois wrote:
> [...]
> > [Actual question]
> > 
> > I'd like to know whether you already have some kind of planning for the
> > next ABI bump(s?) on the linux side, so that we could align further d-i
> > releases accordingly.
> [...]
> 
> Yes, there will be an ABI bump in the next upload to unstable (probably
> within the next week).

Thanks! I'll wait for that to happen & migrate to testing before
preparing for the next d-i release.


KiBi.


signature.asc
Description: Digital signature


Planning for d-i Stretch Alpha 9

2016-11-19 Thread Cyril Brulebois
Hi kernel team,

[Context]

I've been busy on other topics and a few months happened between Stretch
Alpha 7 and Stretch Alpha 8. There were some hiccups when I tried to get
stuff in shape, so we ended up blocking quite a few packages in the
process, including the bump to linux 4.8.

As a side effect, lifting the block-udeb's right after the release
triggered linux's migration to testing, which immediately broke netboot
images… Of course, letting that happen or picking the new version and
hoping for the best was an easy choice: releasing with what had been
tested over the last few days seemed better…


[Actual question]

I'd like to know whether you already have some kind of planning for the
next ABI bump(s?) on the linux side, so that we could align further d-i
releases accordingly.

We have at least another regression in debian-installer (remote installs
were broken due to screen-related changes), in addition to the broken
netboot images, plus themes-related updates, so I think it would make
sense to release Stretch Alpha 9 in the near future; but we can of
course wait a bit if another ABI bump is due soon.


By the way, this will likely be the last Alpha. Given we've entered the
freeze, (winter and) RCs are coming.


KiBi.


signature.asc
Description: Digital signature


Re: Bug#808874: debian-installer: FTBFS on i386: 586 vs. 686

2016-11-19 Thread Cyril Brulebois
Version: 20160101

Adam D. Barratt  (2016-02-21):
> It looks like the 20160101 upload included relevant changes, and built
> happily on i386. Is there anything remaining to fix?

In the “better late than never” category: I think we're all set.

(I had forgotten I uploaded that on Jan 01… :D)


KiBi.


signature.asc
Description: Digital signature


Bug#843943: debian-cd: please mention the dinstall serial in a trace file

2016-11-10 Thread Cyril Brulebois
Package: debian-cd
Severity: normal

(X-D-Cc: debian-b...@lists.debian.org)

Hi,

Since pettersson has a mirror with project/trace, which gives us access
to archive serial, it would be nice to have a look when the build starts
and to report this, maybe in a trace file alongside cdimage.debian.org?

Also, as as side question, do we prevent the mirror from being updated
during the n-hours build of all images?


Some context: This would help figure out what changed between two d-i
releases, in addition to log parsing scripts I'm already running (which
only accounts for udebs installed during the build, plus build-deps):
looking at packages getting ACCEPTED between two dates in my
debian-boot@ mailbox is not practical and is missing non-debian-boot@
packages; plus: those udebs might not have reached testing anyway.

Thanks for considering.


KiBi.



Cleaning up old d-i images

2016-10-31 Thread Cyril Brulebois
When last requesting a dak copy-installer (to get the installer-$arch
files copied from unstable to testing), I've been thinking about (and
right after that poked about) getting rid of old d-i images.

Right now, unstable has the following versions:
  20150422
  20150718
  20150813
  20150828
  20150911
  20151023
  20160101
  20160106
  20160516
  20160516+b1
  20160630
  20161027

jessie has:
  20150422
  20150422+deb8u4+b1

Also, cdimage has a bunch of d-i releases, which are a subset of the
versions listed above (see http://cdimage.debian.org/cdimage/):
  stretch_di_alpha1
  stretch_di_alpha2
  stretch_di_alpha3
  stretch_di_alpha4
  stretch_di_alpha5
  stretch_di_alpha6
  stretch_di_alpha7

so I think it's fair to suggest getting rid of all least all 2015*
versions. The first one was for jessie anyway (and it's not even
current anymore due to uploads from the jessie branch, and later
binNMU).

Does anyone see any objections to dropping everything from 2015, and
possibly 201601*? What use cases would need keeping them around? It's
been almost a year already, not sure we could be missing stuff that
can't be found in the stretch_di_alphaN images anyway.

As far as testing is concerned, being in sync with unstable should do
the trick.

Feedback welcome; please cc me.


KiBi.


signature.asc
Description: Digital signature


Re: 8.6 planning

2016-08-29 Thread Cyril Brulebois
Hi,

Adam D. Barratt  (2016-08-29):
> We seem to have converged on these two. The 10th is doable, but means
> freezing over the coming weekend and I'm not sure how much time I'll
> have between now and then, so I'm tempted to opt for the 17th and get
> the announcement out ASAP.
> 
> Last minute comments, thoughts, confirmations, etc. welcome.

If anything needs my attention before/during pu freeze, I'd welcome the
17th as well.


KiBi.


signature.asc
Description: Digital signature


Re: 8.6 planning

2016-08-14 Thread Cyril Brulebois
Adam D. Barratt  (2016-08-07):
> It's time for another Jessie point release; as wheezy's EOL, we don't
> have to worry about trying to fit two in at the same time. Some possible
> dates:
> 
> August 20th/21st - doesn't work for me
> 
> August 27th/28th - public holiday weekend in the UK; doesn't work for me
> 
> September 3rd/4th 
> 
> September 10th/11th
> 
> September 17th/18th

I'm unlikely to be available during september weekends, but I'll try and
deal with d-i bits during weeks.


KiBi.


signature.asc
Description: Digital signature


Re: [RFC] Switching dpkg-deb --uniform-compression by default

2016-07-14 Thread Cyril Brulebois
Hi,

Guillem Jover  (2016-07-06):
> I'd like consider switching dpkg-deb --uniform-compression by default,
> so that both control.tar and data.tar members use the same
> compression, which currently would be xz (or gzip with -Zgzip).

(AFAICT 'none' is still supported, contrary to 'bzip2' and 'lzma').

That wouldn't seem crazy to me.

> This would give us more uniform and smaller packages. I think the d-i
> people wanted something like this (?).

[ Adding debian-boot@, where “the d-i people” are, and debian-cd@ for
  completeness. ]

A few years ago we pushed for xz compression in some key packages to try
and squeeze more packages into installation images, notably CD#1; ISTR
that would only change the data part and not the control one, which
would limit the size gain for some specific packages. debian-cd only
generates netinst CDs nowadays so that's no longer a hot topic for us
AFAIK.

> Not all .deb parsers support control.tar.xz yet, but most do:
> 

udpkg's status there seems correct (supports gz/xz/no compression), and
just to be sure: I've just checked that compression_type is indeed
handled independently for control (in udpkg.c's dpkg_unpackcontrol) and
for data (dpkg_dounpack).

> Would there be any objections to this?

Bottom-line from a d-i point of view: having both compression in sync by
default shouldn't change anything on our side (shouldn't gain us much
but shouldn't do much harm either).


KiBi.


signature.asc
Description: Digital signature


Re: Next d-i alpha release: late June

2016-06-28 Thread Cyril Brulebois
Hi,

Nicholas D Steeves  (2016-06-28):
> Could someone please tell me what the deadline is for adding expanded
> partman-btrfs functionality?  My proposal is in a thread on
> debian-b...@lists.debian.org, subject: "Re: btrfs subvolume naming
> scheme".  A résumé of the read is: add the volume-manager-like
> subvolume setup, and hopefully also add btrfs-style raid1 profile
> support, and also the question of whether Debian should follow Ubuntu
> and openSUSE subvolume naming conventions or Fedora/CentOS/RHEL ones.
> The upstream wiki advocates Fedora/CentOS/RHEL-style.

The upcoming release will use whatever is in testing at this point, so
it'll be for a later release.


KiBi.


signature.asc
Description: Digital signature


Next d-i alpha release: late June

2016-06-24 Thread Cyril Brulebois
Hi,

I've just checked with Ben, it seems we could be getting a 4.6 kernel
suitable for testing (no regressions reported from previous version +
mips* FTBFS fix) shortly. We could think about urgenting it into testing
and releasing a new d-i early in the week, which seems OK on the -cd
side too.

Glibc maintainers (esp. Aurélien): you should then have a clear path for
the new glibc in unstable. I'm not sure how much time it'll need to be
ready, that's why I'd slightly prefer if we could go for a d-i release
first (as outlined above). In case major blockers pop up, we would
probably let you go ahead with the new glibc upload and postpone d-i
until glibc reaches testing.

Having checked with -release already, I'm freezing udebs right away.

(Please cc me on replies.)


KiBi.


signature.asc
Description: Digital signature


Bug#827610: Debian Pure Blends installation menu unclear (Stretch)

2016-06-21 Thread Cyril Brulebois
Control: tag -1 stretch

Michael Wilson  (2016-06-18):
> Package: installation-reports cdrom
> Version: Alpha 6 release
> Tags: stretch
> 
> Maintainers,
> 
> As a Debian Science end-user, I applaud the inclusion of Debian Pure
> Blends in the installation menu. However, currently there is not
> enough information (within the installer or the documentation) which
> indicates what selecting one of these options actually does. For
> instance, I am unsure whether selecting the “DebianScience Pure Blend”
> option will install all 1397 packges in all Debian Science
> metapackage. If this is the case, this is superfluous.
> 
> Suggestions were made in #758116 that it should prompt a menu on first
> boot to select specific metapackages. Regardless of it’s actual
> function, if we want users to utilize this feature, it is important to
> have clear documentation on the Wiki (at minimum) which describes
> specifically what these options do. I decided not to install the blend
> out of concern it would install all 1397 packages. A thorough read of
> installation guides, Wiki, and the #758116 failed to provide any
> insight.
> 
> Thanks for any consideration, it would be wasteful to include this
> feature and users never utilise it out of misunderstanding its
> function.

That's a very valid concern; for the record, the canonical place for
such documentation is the installation guide, and we should update it
when the situation on the “what to do with Pure Blends” front settles.


KiBi.


signature.asc
Description: Digital signature


Re: Improving firmware reporting

2016-05-22 Thread Cyril Brulebois
Ben Hutchings  (2016-05-22):
> All the binary packages built from firmware-nonfree get it
> automatically, but I forgot there were so many other firmware packages.
> Maybe your way is better for now.

ACK. Easy enough to toggle between both anyway. Maybe I should even
keep both codepaths active and use them to detect inconsistencies
between file list in Contents and Appstream metadata in Components…

> > amd64-microcode
> > atmel-firmware
> > bluez-firmware
> > dahdi-firmware-nonfree
> > firmware-crystalhd
> > firmware-ipw2x00
> 
> firmware-ipw2x00 does have it.

Alright. I ran diff plus some pipes, without checking each and every
package, which explains this kind of false positive.

It seems the following files are under lib/firmware but not listed in
Appstream metadata:
  lib/firmware/ipw2x00.LICENSE
  lib/firmware/isci/isci_firmware.bin

Not sure about the former but I suppose the latter should be listed
there?

> > firmware-linux-free
> > firmware-zd1211
> > intel-microcode
> > ixp4xx-microcode
> > prism2-usb-firmware-installer
> > 
> > (firmware-linux-free might be special because in main; not sure.)
> 
> That means it's built from a separate source package which I haven't
> yet added DEP-11 generation to.  But it's also recommended by linux-
> image-* so gets installed by default anyway.

Well, as far as I can tell from a debian-installer build, this package
isn't used at build-time. That it gets installed by default is one
thing; but as I mentioned in my initial reply, we might need to load
firmware(s) within the installer context, sometimes before having
network set up, or the /target filesystem, etc.

(I have no idea whether that is relevant for any of the firmwares
included in this particular package.)

Also: Thanks for your feedback.


KiBi.


signature.asc
Description: Digital signature


Re: Improving firmware reporting

2016-05-22 Thread Cyril Brulebois
Cyril Brulebois <k...@debian.org> (2016-05-22):
> Ben Hutchings <b...@decadent.org.uk> (2016-05-22):
> > That information already exists in DEP-11 metadata that APT will
> > download for us.
> 
> Right, forgot about that. But what the mapping is built from doesn't
> really change the need for embedding it, see below.

I've modified the script to use dep11 information. Comparing results, it
seems some packages are missing those “AppStream metadata”, and should
probably get a bug report accordingly?

amd64-microcode
atmel-firmware
bluez-firmware
dahdi-firmware-nonfree
firmware-crystalhd
firmware-ipw2x00
firmware-linux-free
firmware-zd1211
intel-microcode
ixp4xx-microcode
prism2-usb-firmware-installer

(firmware-linux-free might be special because in main; not sure.)

In the meanwhile I've pushed the commit to the dep11 branch instead of
the master one (still in the hw-detect repository).


KiBi.


signature.asc
Description: Digital signature


Re: Improving firmware reporting

2016-05-22 Thread Cyril Brulebois
Ben Hutchings <b...@decadent.org.uk> (2016-05-22):
> On Sun, 2016-05-22 at 19:26 +0200, Cyril Brulebois wrote:
> > [ Note: I've added d-l-e to the loop since people there might have some
> >   insight about the prompt update I'm proposing. ]
> > 
> > Hi,
> > 
> > An email earlier today reminded me of this old topic: it would be nice
> > if hw-detect would point us to the right firmware package(s) instead of
> > letting D-I only report the list of missing firmware files.
> > 
> > I've modified hw-detect to make it possible to build (and update) such
> > a mapping:
> > 
> > ${firmware_filename} ${firmware_package} ${section}
> 
> That information already exists in DEP-11 metadata that APT will
> download for us.

Right, forgot about that. But what the mapping is built from doesn't
really change the need for embedding it, see below.

> > which is going to be shipped as usr/share/hw-detect/firmware-map in
> > the hw-detect binary.
> > 
> > Like choose-mirror, this file is generated outside of the source and
> > binary builds (since it needs network access), and will need updating
> > from time to time (ideally once before every release, but I'll probably
> > add a cron job on d-i.debian.org to get notifications).
> [...]
> 
> Please use the existing index which will stay up-to-date.

Well, this needs to be embedded within d-i for a number of installation
images. We can't rely on a network mirror in any cases, and we don't
have dep11 in cdrom images at the moment either. Checking with
debian-stretch-DI-alpha6-i386-netinst.iso:

dists/stretch/contrib/binary-i386/Release
dists/stretch/main/binary-i386/Packages.gz
dists/stretch/main/binary-i386/Release
dists/stretch/main/debian-installer/binary-i386/Packages.gz
dists/stretch/main/debian-installer/binary-i386/Release
dists/stretch/main/i18n/Translation-ca.gz
dists/stretch/main/i18n/Translation-cs.gz
dists/stretch/main/i18n/Translation-da.gz
dists/stretch/main/i18n/Translation-de_DE.gz
dists/stretch/main/i18n/Translation-de.gz
dists/stretch/main/i18n/Translation-en.gz
dists/stretch/main/i18n/Translation-eo.gz
dists/stretch/main/i18n/Translation-es.gz
dists/stretch/main/i18n/Translation-eu.gz
dists/stretch/main/i18n/Translation-fi.gz
dists/stretch/main/i18n/Translation-fr.gz
dists/stretch/main/i18n/Translation-hr.gz
dists/stretch/main/i18n/Translation-hu.gz
dists/stretch/main/i18n/Translation-id.gz
dists/stretch/main/i18n/Translation-it.gz
dists/stretch/main/i18n/Translation-ja.gz
dists/stretch/main/i18n/Translation-km.gz
dists/stretch/main/i18n/Translation-ko.gz
dists/stretch/main/i18n/Translation-nb.gz
dists/stretch/main/i18n/Translation-nl.gz
dists/stretch/main/i18n/Translation-pl.gz
dists/stretch/main/i18n/Translation-pt_BR.gz
dists/stretch/main/i18n/Translation-pt.gz
dists/stretch/main/i18n/Translation-ro.gz
dists/stretch/main/i18n/Translation-ru.gz
dists/stretch/main/i18n/Translation-sk.gz
dists/stretch/main/i18n/Translation-sr.gz
dists/stretch/main/i18n/Translation-sv.gz
dists/stretch/main/i18n/Translation-uk.gz
dists/stretch/main/i18n/Translation-vi.gz
dists/stretch/main/i18n/Translation-zh_CN.gz
dists/stretch/main/i18n/Translation-zh.gz
dists/stretch/main/i18n/Translation-zh_TW.gz
dists/stretch/Release


KiBi.


signature.asc
Description: Digital signature


Improving firmware reporting

2016-05-22 Thread Cyril Brulebois
[ Note: I've added d-l-e to the loop since people there might have some
  insight about the prompt update I'm proposing. ]

Hi,

An email earlier today reminded me of this old topic: it would be nice
if hw-detect would point us to the right firmware package(s) instead of
letting D-I only report the list of missing firmware files.

I've modified hw-detect to make it possible to build (and update) such
a mapping:

${firmware_filename} ${firmware_package} ${section}

which is going to be shipped as usr/share/hw-detect/firmware-map in
the hw-detect binary.

Like choose-mirror, this file is generated outside of the source and
binary builds (since it needs network access), and will need updating
from time to time (ideally once before every release, but I'll probably
add a cron job on d-i.debian.org to get notifications).


=> The question is now: how do we present this to users?

The current template is:
| Template: hw-detect/load_firmware
| Type: boolean
| Default: true
| # :sl2:
| _Description: Load missing firmware from removable media?
|  Some of your hardware needs non-free firmware files to operate. The
|  firmware can be loaded from removable media, such as a USB stick or
|  floppy.
|  .
|  The missing firmware files are: ${FILES}
|  .
|  If you have such media available now, insert it, and continue.

The FILES variable gets set by check-missing-firmware.sh through:

db_subst hw-detect/load_firmware FILES "$files"

and we could do the same with a PACKAGES variable which would contain
e.g.:

firmware-atheros (non-free), prism2-usb-firmware-installer (contrib)

(by looping over $files and grepping into this new mapping file.)


Quick idea:
| _Description: Load missing firmware from removable media?
|  Some of your hardware needs non-free firmware files to operate. The
|  firmware can be loaded from removable media, such as a USB stick or
|  floppy.
|  .
|  The missing firmware files are: ${FILES}
|  .
|  The following packages contain some of these files: ${PACKAGES}
|  .
|  If you have such media available now, insert it, and continue.

The trick is: we might reach some point where (at least) it's not
possible to resolve a filename to a package. That's why I've used a
rather cautious wording above. Having an extra line with the list of
unresolved filenames would be cumbersome in the general case. Having it
only conditionally would mean having troubles translating it.

Maybe sticking to the simple sentence below would be appropriate for
most cases:
| They can be found in the following packages: ${PACKAGES}


What do you think?


KiBi.


signature.asc
Description: Digital signature


Re: Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

2016-05-22 Thread Cyril Brulebois
Petter Reinholdtsen <p...@hungry.com> (2016-05-22):
> [Cyril Brulebois]
> > There's no udebs involved in what I summarized for Blends.
> 
> Exactly.

Thanks for confirming that your “Being able to add extra tasks using
udebs is a feature, not a bug.” wasn't really on topic then.

> I suspect using udebs to enable blends is be a better idea than
> making the Blends tasksel tasks priority standard.

Having this kind of move forced on us doesn't seem reasonable to me,
which has been exactly my point over the past few mails.

Let me reiterate: I don't want this to happen ever again.


> > Also: If pkgsel changes the way it calls tasksel, debian-edu udebs can
> > certainly interact with it so that it behaves as desired.
> 
> You misunderstand the role of the udebs.

Please explain how you came to that conclusion.

> The Debian Edu udeb ask for education-tasks to be installed, and
> then the normal d-i take care of the rest to get the correct Debian
> Edu tasks installed using tests and the locale settings.  Sure, we
> can come up with a new way to do it, but my point is that we are
> using this feature of tasksel today, and there is no alternative I
> know of that is equally robust and well integrated into the
> installer.

What? I'm talking about a future evolution. I can't see why something
using a pre-pkgsel.d hook to prepare things for d-i couldn't be
updated to create e.g. an extra file to get pkgsel to behave as
intended. I don't see why such implementation details would be
important in this discussion, and that's why I mentioned “debian-edu
udebs can certainly interact with it so that it behaves as desired”.

Pretty sure I'm not the one “misunderstanding” anything here.


KiBi.


signature.asc
Description: Digital signature


Re: Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

2016-05-21 Thread Cyril Brulebois
Petter Reinholdtsen <p...@hungry.com> (2016-05-21):
> [Cyril Brulebois]
> > I'm very much not happy with tasksel's picking up whatever people have
> > managed to get into a basic system, and I would very much prefer if it
> > would only look at its own debian-tasks.desc when running from the
> > installer. Any objections?
> 
> Yes.
> 
> Debian Edu uses the current behaviour to install its tasks during
> installation, but we do not use standard priority tasks to get into the
> installer, we use udebs to trigger the installation of education-tasks.
> 
> Being able to add extra tasks using udebs is a feature, not a bug.

There's no udebs involved in what I summarized for Blends.


Also: If pkgsel changes the way it calls tasksel, debian-edu udebs can
certainly interact with it so that it behaves as desired.


KiBi.


signature.asc
Description: Digital signature


Re: Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

2016-05-21 Thread Cyril Brulebois
Cyril Brulebois <k...@debian.org> (2016-05-21):
> I'm very much not happy with tasksel's picking up whatever people have
> managed to get into a basic system, and I would very much prefer if it
> would only look at its own debian-tasks.desc when running from the
> installer. Any objections?

As a side note, pkgsel calls tasksel with --new-install, but maybe
others are using this flag outside d-i contexts. So I'd probably add
a --internal-tasks-only there.

As another side note, tasksel-data in Debian only has:
  /usr/share/tasksel/descs/debian-tasks.desc

while latest Ubuntu has:
  /usr/share/tasksel/descs/debian-tasks.desc
  /usr/share/tasksel/descs/ubuntu-tasks.desc

so it would be nice to support all desc files shipped in tasksel-data
rather than hardcoding debian-tasks.desc when the --internal-tasks-only
flag is passed.

Martin, I think this would go along the lines of the idea you mentioned
briefly on IRC?


KiBi.


signature.asc
Description: Digital signature


Re: debian-installer issues with no wireless network connection after a text based Jessie installation

2016-05-20 Thread Cyril Brulebois
Hi Nick,

Nick Gawronski  (2016-05-20):
> Hi, The name of the iso I was using is firmware-8.0.0-amd64-netinst.iso
> 
>  and it is in the archive for the debian-installer.  I ran the installation
> using this image as my network cards both wired and wireless require
> firmware and I also ran the installation on low priority and choose to
> install everything like non-free as well as backports.  For the main tasks
> for this text based installation I selected just the standard system as I
> want this system to be small.  Everything installed just fine and I was
> connected to the installation over the network as I wanted to test out the
> network console using my windows 10 system and was able to follow all
> prompts but then once the Debian system rebooted no internet settings were
> on the system in the /etc/network/interfaces or any other wifi packages that
> were installed such as wpa_supplicant.  My question is why does the
> installer not copy over the wireless networking settings from the installer
> to the target system when doing a text only install with speech?  Nick
> Gawronski

In the general case, the installer (through its netcfg component) should
be copying the network settings over from the installer system to the
installed system.

I'm not familiar with the firmware version of installer images, so I'm
adding the debian-cd@ list to the loop, so that people building those
images can comment on this. They might appreciate if you could extract
the following log file from your system and attach it to an email:

/var/log/installer/syslog

We might have a missing integration bit to enable non-free packages on
the installation system (this might be by design because of freeness
issues, or maybe an oversight; no idea), or maybe a buggy behaviour.

The log file mentioned above might help them figure out what happened on
your system.


KiBi.


signature.asc
Description: Digital signature


Re: Torrent file for netinst non-free firmware doesn't work

2016-05-16 Thread Cyril Brulebois
Hi,

Albin Otterhäll  (2016-05-15):
> The torrent for the 8.4.0 64-bit netinst CD image[1] doesn't work. I
> haven't tested the torrents other architecture.
> 
> [1]
> http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/8.4.0/amd64/bt-cd/

Adding debian-cd@ to the loop.


KiBi.


signature.asc
Description: Digital signature


Re: Bug#819719: override: apt:admin/required

2016-05-04 Thread Cyril Brulebois
Hi Ansgar,

And thanks for the prod/sorry for the lag.

Ansgar Burchardt  (2016-04-01):
> Package: ftp.debian.org
> Severity: normal
> 
> apt is currently at Priority: important, but debootstrap treats it
> like Priority: required by including it in every variant explicitly:
> 
> +---
> | if doing_variant - || doing_variant fakechroot; then
> | #required="$required $(get_debs Priority: important)"
> | #  ^^ should be getting debconf here somehow maybe
> | base="$(get_debs Priority: important)"
> | elif doing_variant buildd || doing_variant scratchbox; then
> | base="apt build-essential"
> | elif doing_variant minbase; then
> | base="apt"
> | fi
> +---[ file:///usr/share/debootstrap/scripts/sid ]
> 
> If apt was Priority: required, debootstrap wouldn't need to pretend it
> was. It also seems more honest ;)

We will likely need to keep it in there (debootstrap) for a while anyway
given scripts are used (through symlinks) for many distributions. But it
looks like a good idea to get overrides in line with reality anyway.

So ack from d-i rm; if anything breaks, things should be easy enough to
fix (famous last words).

[ Extra cc for debian-cd@ to cover all the bases. ]


KiBi.


signature.asc
Description: Digital signature


Re: Bug#816682: live-installer: Inaccessible utility

2016-03-07 Thread Cyril Brulebois
Samuel Thibault  (2016-03-08):
> There was also a bug in at-spi2-atk, I have uploaded a fixed package.
> 
> So, to summarize the needed steps to get d-i accessible from debian live:
> 
> - at-spi2-atk fix (debian/patches/p2p), done.
> - adding a udeb for libgail-common & libgail18, filed as #816720
> - setting GTK_MODULES=gail:atk-bridge in the debian-installer.sh script,
> filed as #816705
> - adding the content of libgail-common-udeb and libatk-adaptor-udeb to
> the d-i image used by the live installer.  I don't know which image the
> live installer uses, is it just using the standard gtk d-i image (in
> which case we can just add the packages to g-i), or is it building its
> own image?

Would probably make sense to include debian-live/debian-cd at some
point… Doing so to get their input, along with irl@ who helped with
getting live stuff built on d.o machines IIRC.


KiBi.


signature.asc
Description: Digital signature


Mirror cdimage.debian.org?

2016-01-02 Thread Cyril Brulebois
Hi,

A friend of mine noted cdimage.debian.org was rather slow from France,
and thought there might be some CDN misconfiguration. AFAICT,
cdimage.debian.org is served from two IPs at acc.umu.se; would it make
sense to have its contents mirrored somewhere else? Any estimate as far
as size goes?

Mraw,
KiBi.


signature.asc
Description: Digital signature


Bug#809698: debian-cd: please switch d-i.debian.org URIs from http to https.

2016-01-02 Thread Cyril Brulebois
Package: debian-cd
Version: 3.17
Severity: normal

Hi,

We now have https for daily images[1], so please consider applying (and
testing!) the attached, untested patch.

 1. https://lists.debian.org/debian-boot/2016/01/msg00032.html

Mraw,
KiBi.
>From a4ec2be603f60730c48c497231d1e9c0ba02463f Mon Sep 17 00:00:00 2001
From: Cyril Brulebois <k...@debian.org>
Date: Sun, 3 Jan 2016 01:03:24 +0100
Subject: [PATCH] Switch d-i.debian.org URIs from http to https.

---
 debian/changelog   | 3 +++
 tools/boot/jessie/boot-alpha   | 2 +-
 tools/boot/jessie/boot-arm | 4 ++--
 tools/boot/jessie/boot-arm64   | 2 +-
 tools/boot/jessie/boot-hppa| 2 +-
 tools/boot/jessie/boot-hurd| 2 +-
 tools/boot/jessie/boot-ia64| 2 +-
 tools/boot/jessie/boot-kfreebsd| 4 ++--
 tools/boot/jessie/boot-mips| 2 +-
 tools/boot/jessie/boot-mipsel  | 2 +-
 tools/boot/jessie/boot-powerpc | 2 +-
 tools/boot/jessie/boot-ppc64el | 2 +-
 tools/boot/jessie/boot-s390x   | 2 +-
 tools/boot/jessie/boot-sparc   | 2 +-
 tools/boot/jessie/boot-x86 | 4 ++--
 tools/boot/stretch/boot-alpha  | 2 +-
 tools/boot/stretch/boot-arm| 4 ++--
 tools/boot/stretch/boot-arm64  | 2 +-
 tools/boot/stretch/boot-hppa   | 2 +-
 tools/boot/stretch/boot-hurd   | 2 +-
 tools/boot/stretch/boot-ia64   | 2 +-
 tools/boot/stretch/boot-kfreebsd   | 4 ++--
 tools/boot/stretch/boot-mips   | 2 +-
 tools/boot/stretch/boot-mipsel | 2 +-
 tools/boot/stretch/boot-powerpc| 2 +-
 tools/boot/stretch/boot-ppc64el| 2 +-
 tools/boot/stretch/boot-s390x  | 2 +-
 tools/boot/stretch/boot-sparc  | 2 +-
 tools/boot/stretch/boot-x86| 4 ++--
 tools/boot/wheezy/boot-alpha   | 2 +-
 tools/boot/wheezy/boot-arm | 4 ++--
 tools/boot/wheezy/boot-hppa| 2 +-
 tools/boot/wheezy/boot-hurd| 2 +-
 tools/boot/wheezy/boot-ia64| 2 +-
 tools/boot/wheezy/boot-kfreebsd| 4 ++--
 tools/boot/wheezy/boot-mips| 2 +-
 tools/boot/wheezy/boot-mipsel  | 2 +-
 tools/boot/wheezy/boot-powerpc | 2 +-
 tools/boot/wheezy/boot-s390-common | 4 ++--
 tools/boot/wheezy/boot-sparc   | 2 +-
 tools/boot/wheezy/boot-x86 | 4 ++--
 41 files changed, 53 insertions(+), 50 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 8af16ef..d75a4f2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -40,6 +40,9 @@ debian-cd (3.1.18) UNRELEASED; urgency=medium
   * Drop the remaining s390 bits from stretch and jessie. (s390x remains.)
   * Drop the d390oco loader from stretch and jessie.
 
+  [ Cyril Brulebois ]
+  * Switch d-i.debian.org URIs from http to https.
+
  -- Steve McIntyre <93...@debian.org>  Mon, 20 Apr 2015 12:36:57 +0100
 
 debian-cd (3.1.17) unstable; urgency=medium
diff --git a/tools/boot/jessie/boot-alpha b/tools/boot/jessie/boot-alpha
index 8908967..762ae2e 100755
--- a/tools/boot/jessie/boot-alpha
+++ b/tools/boot/jessie/boot-alpha
@@ -26,7 +26,7 @@ N=$1
 CDDIR=$2
 BOOTDIR=
 if [ "$DI_WWW_HOME" = "default" ];then
-DI_WWW_HOME="http://d-i.debian.org/daily-images/alpha/daily/cdrom/;
+DI_WWW_HOME="https://d-i.debian.org/daily-images/alpha/daily/cdrom/;
 try_di_image_cache
 fi
 
diff --git a/tools/boot/jessie/boot-arm b/tools/boot/jessie/boot-arm
index 80da3cb..d34c155 100755
--- a/tools/boot/jessie/boot-arm
+++ b/tools/boot/jessie/boot-arm
@@ -20,9 +20,9 @@ if [ "$DI_WWW_HOME" = "default" ];then
 # do *not* do that - these defs are parsed out by other scripts that
 # won't cope with that
 if [ "$ARCH" = armel ]; then
-DI_WWW_HOME="http://d-i.debian.org/daily-images/armel/daily;
+DI_WWW_HOME="https://d-i.debian.org/daily-images/armel/daily;
 elif [ "$ARCH" = armhf ]; then
-DI_WWW_HOME="http://d-i.debian.org/daily-images/armhf/daily;
+DI_WWW_HOME="https://d-i.debian.org/daily-images/armhf/daily;
 else
 echo "$0: unknown arch $ARCH; abort"
 	exit 1
diff --git a/tools/boot/jessie/boot-arm64 b/tools/boot/jessie/boot-arm64
index 5cd35da..66e2815 100755
--- a/tools/boot/jessie/boot-arm64
+++ b/tools/boot/jessie/boot-arm64
@@ -18,7 +18,7 @@ CDDIR=$2
 BOOTDIR=
 INSTALLDIR="install.a64"
 if [ "$DI_WWW_HOME" = "default" ];then
-DI_WWW_HOME="http://d-i.debian.org/daily-images/arm64/daily;
+DI_WWW_HOME="https://d-i.debian.org/daily-images/arm64/daily;
 try_di_image_cache
 fi
 
diff --git a/tools/boot/jessie/boot-hppa b/tools/boot/jessie/boot-hppa
index 84fa250..8e66f50 100755
--- a/tools/boot/jessie/boot-hppa
+++ b/tools/boot/jessie/boot-hppa
@@ -14,7 +14,7 @@ set -e
 N=$1
 CDROOT=$2
 if [ "$DI_WWW_HOME" = "default" ];then
-DI_WWW_HOME="http://d-i.debian.org/daily-images/hppa/daily/cdrom/2.6;
+DI_WWW_HOME="https://d-i.debian.org/daily-images/h

Re: Bug#808874: debian-installer: FTBFS on i386: 586 vs. 686

2015-12-25 Thread Cyril Brulebois
Ben Hutchings <b...@decadent.org.uk> (2015-12-24):
> On Thu, 2015-12-24 at 03:30 +0100, Cyril Brulebois wrote:
> > Ben Hutchings <b...@decadent.org.uk> (2015-12-24):
> > > I already updated base-installer for this, and I think the only other
> > > change needed was in build/config/i386.cfg.  I've pushed a change to
> > > that.
> > 
> > Checking my notes, it appears the following bits were involved last time:
> > base-installer, debian-installer, debian-cd, installation guide.
> > 
> > The first two seem covered now, thanks.
> > 
> > Adding debian-cd@ for the third (sorry, didn't do any research for this
> > one).
> 
> I opened bug #808958 with a patch.
> 
> > The last one seems to have been dealt with in r69410, r69411, r69412
> > last time; something similar might do the trick this time.
> 
> Updated in r70113, r70114.

Perfect, thanks!

Mraw,
KiBi.


signature.asc
Description: Digital signature


Re: Bug#808874: debian-installer: FTBFS on i386: 586 vs. 686

2015-12-23 Thread Cyril Brulebois
Ben Hutchings  (2015-12-24):
> I already updated base-installer for this, and I think the only other
> change needed was in build/config/i386.cfg.  I've pushed a change to
> that.

Checking my notes, it appears the following bits were involved last time:
base-installer, debian-installer, debian-cd, installation guide.

The first two seem covered now, thanks.

Adding debian-cd@ for the third (sorry, didn't do any research for this
one).

The last one seems to have been dealt with in r69410, r69411, r69412
last time; something similar might do the trick this time.

Mraw,
KiBi.


signature.asc
Description: Digital signature


Re: Tentative last d-i release for 2015?

2015-12-20 Thread Cyril Brulebois
Emilio Pozuelo Monfort  (2015-12-18):
> My apologies. I didn't think this through... I guess we've been
> waiting for this transition for so long that I just was too happy to
> be able to start it. I guess I also thought you were building d-i out
> of testing, and that's why I said we could wait (for the migration) to
> happen until the block was lifted. My bad.

Just as a reminder/clarification for another time:
 - src:debian-installer is special in two ways:
   - it fetches stuff over the network, from testing;
   - it builds a tar archive with installation images, to be included
 along with a tiny .deb (which bundles a few docs).

 - src:debian-installer isn't special in the following ways:
   - it's uploaded to, and built within, unstable;
   - its build-deps are fetched from unstable as well.
   (that's why we had the syslinux thing a few years ago; and the perl
thing right now.)

> Not sure if it helps, but at this rate, we will have rebuilt
> everything on the "fast" architectures (everywhere except mips*) by
> the end of today. Migration to testing will take longer as there are
> issues to sort out, though again I don't know if that is a problem for
> you or if having an installable sid is enough.

That doesn't help: src:debian-installer has to be built everywhere and
dak copy-installer has to happen before we start building “CD” images;
changelog datamining (used to prepare release announces) also relies on
the build having happened on all archs. So the fast vs. slow archs makes
this moot. There's also the part where developers have to be around (and
have access to the right hardware/tools) to actually do the work…

Mraw,
KiBi.


signature.asc
Description: Digital signature


Re: Tentative last d-i release for 2015?

2015-12-17 Thread Cyril Brulebois
Emilio Pozuelo Monfort  (2015-12-13):
> We're getting close to start the Perl transition. I guess there are packages 
> in
> there building udebs, and I guess the transition won't be over by the weekend
> (so the block may be alright, and in any case we could wait a couple of days 
> if
> things happened to be ready).

It would have been nice to leave me a chance to upload d-i before starting perl…

Mraw,
KiBi.


signature.asc
Description: Digital signature


Re: Tentative last d-i release for 2015?

2015-12-15 Thread Cyril Brulebois
Hi,

Emilio Pozuelo Monfort  (2015-12-13):
> We're getting close to start the Perl transition. I guess there are
> packages in there building udebs, and I guess the transition won't be
> over by the weekend (so the block may be alright, and in any case we
> could wait a couple of days if things happened to be ready).

Thanks for the update.

I've set a few unblock-udebs/urgents for d-i packages, and an
unblock-udeb glibc since it's always a good idea to have the same major
version in testing and in unstable (we've seen random crashes in the
past when there was a mismatch; I'm not sure if that's likely with the
current state of affairs but let's be cautious).

I haven't toyed with d-i builds locally yet though; Steve confirmed this
week-end would work fine, so I'll try and have d-i ready by then. If too
many issues happen, I'll let you know and lift the block-udeb * so that
you don't block on me for further debian-release work.

Mraw,
KiBi.


signature.asc
Description: Digital signature


Tentative last d-i release for 2015?

2015-12-13 Thread Cyril Brulebois
Hi,

I'm not entirely sure I'll manage to get that to work but I'd like to
consider performing a last d-i release for 2015. I haven't been paying
attention closely enough over the past few days but if things are in shape
somewhat, and if image builds can be performed, then maybe… Would debian-cd
people be available say next week-end (2015-12-19/20)?

Release people, would a global block-udeb disrupt anything going on on your
side?

Mraw,
KiBi.


signature.asc
Description: Digital signature


Re: 8.3 planning

2015-12-04 Thread Cyril Brulebois
Adam D. Barratt  (2015-12-04):
> 2nd/3rd - depends how much people are still suffering. :-)

I'd rather avoid this one, but might be able to.

> 9th/10th
> 16th/17th
> 23rd/24th - likely to be bad for me

Any of those should work as far as d-i goes.

Mraw,
KiBi.


signature.asc
Description: Digital signature


Preparing d-i Stretch Alpha 4

2015-10-25 Thread Cyril Brulebois
Hi Steve,

Cyril Brulebois <k...@debian.org> (2015-10-24):
> Steve, feel free to start building images after the 1352Z dinstall and
> associated mirror pulse which should propagate this new d-i version.

It looks like the build finished. Any chance you could sign stuff and
put it into place if it looks good to you? Just trying to figure out
whether we're announcing the release today or tomorrow. I'd welcome
“release announce” style description of the CD-side changes if you have
some extra minutes to kill. ;) (I'll be working on the rest in the
meanwhile.)

Thanks already!

Mraw,
KiBi.


signature.asc
Description: Digital signature


Re: Preparing d-i Stretch Alpha 4

2015-10-25 Thread Cyril Brulebois
Steve McIntyre <st...@einval.com> (2015-10-25):
> On Sun, Oct 25, 2015 at 12:25:25PM +0100, Cyril Brulebois wrote:
> >Hi Steve,
> >
> >Cyril Brulebois <k...@debian.org> (2015-10-24):
> >> Steve, feel free to start building images after the 1352Z dinstall and
> >> associated mirror pulse which should propagate this new d-i version.
> >
> >It looks like the build finished. Any chance you could sign stuff and
> >put it into place if it looks good to you? Just trying to figure out
> >whether we're announcing the release today or tomorrow. I'd welcome
> >“release announce” style description of the CD-side changes if you have
> >some extra minutes to kill. ;) (I'll be working on the rest in the
> >meanwhile.)
> 
> Just doing some testing now.

Perfect, thanks. I'll get back to this in a few hours.

Given we're basically only trimming the CD set, I suppose most changes
needed on the documentation side should appear in installation-guide?
(I suppose it might talk a bit about CD sets, alternative desktops etc.)

There are also per-directory headers on cdimage, but those were touched
by one of the commits in debian-cd IIRC.

The website will still point to the existing CD directories, but the
contents will be way lighter. No broken links as far as I can imagine?

Does anybody see something that might be missing on this topic?

Mraw,
KiBi.


signature.asc
Description: Digital signature


Re: Preparing d-i Stretch Alpha 4

2015-10-25 Thread Cyril Brulebois
Steve McIntyre  (2015-10-25):
> On Sun, Oct 25, 2015 at 05:58:28PM +, Steve McIntyre wrote:
> >XFCE and KDE both seem to work fine. \o/

Great.

> As does Gnome on real hardware. Sigh at YA place where Gnome looks to
> be failing in VM installations. :-(

That (especially given Ben's follow-up) doesn't worry me too much, I'll
add it to errata.

> Testing has also confirmed:
> 
>  * the fix for the stupid systemd /etc/mtab sym-link issue works fine

Thanks.

>  * xfs on / is a no-go with Grub

OK, errata plus reference to a bug report it is.

> Otherwise, I think we look good. Do you want me to sign and publish? 

A totally broken gnome would have gotten me a bit worried and I would
have had to think about it a bit more. Given the end results, I think
going ahead and signing/publishing looks good to me, please go ahead.

And many thanks for your work.

Mraw,
KiBi.


signature.asc
Description: Digital signature


Re: Please dak copy-installer 20151023

2015-10-24 Thread Cyril Brulebois
Hi,

Ansgar Burchardt <ans...@debian.org> (2015-10-24):
> Cyril Brulebois <k...@debian.org> writes:
> > FTPmasters, please sync the installer from sid to testing:
> >
> >   dak copy-installer 20151023
> 
> Done.

Thanks, ftp & release people.

Steve, feel free to start building images after the 1352Z dinstall and
associated mirror pulse which should propagate this new d-i version.

Mraw,
KiBi.


signature.asc
Description: Digital signature


Re: Towards D-I Stretch Alpha 4

2015-10-20 Thread Cyril Brulebois
Hi again,

Steve McIntyre <st...@einval.com> (2015-10-08):
> On Thu, Oct 08, 2015 at 05:14:17AM +0200, Cyril Brulebois wrote:
> > I've just pushed a patch in D-I bumping the linux kernel ABI for the
> > latest linux migration to testing, and therefore pondering when to
> > schedule a release. I'm thinking somewhen before the end of October
> > would be nice, if feasible on the debian-cd side.
> 
> Works for me...

Great! I'll try and shape things up until the end of this week. I'll
reinstate a block for all udebs after tonight's britney run, and I'll
be running some more checks before a possible upload in a few days.

> > I don't think I've seen many changes lately, except for those planned
^
> > on the CD side (thanks for the detailed announce!), so I'm currently
^^
> > not anticipating bad surprises (but I'm probably lacking imagination
> > or wisdom).
> 
> OK. I would like to disable the CD set builds properly again - I'm
> just about to commit that change again now. OK?

The highlighted part above was meant to be an ACK for the change, but I
agree I should have made that more explicit. To recap quickly: my main
objection last time was the lack of prior notice (visible to outside the
huge yet limited DC'15 crowd); now that it's been announced on lists and
discussed a bit, and that the feedback loop has been quiet for a while,
I'm fine with moving things ahead (even if I suspect we might hear some
more about users once the change has actually happened ;)).

> After the DC15 discussion and follow-up on the list I think I'll leave
> *one* CD1 option around, XFCE.

I've already checked with Steve that the plan looks like this:
 - getting netinst on i386/amd64 would still install Gnome;
 - but CD#1 would be specifically marked as CD1-xfce in some manner
   (through the filename), and would default to Xfce instead.

Mraw,
KiBi.


signature.asc
Description: Digital signature


Towards D-I Stretch Alpha 4

2015-10-07 Thread Cyril Brulebois
Hi,

I've just pushed a patch in D-I bumping the linux kernel ABI for the
latest linux migration to testing, and therefore pondering when to
schedule a release. I'm thinking somewhen before the end of October
would be nice, if feasible on the debian-cd side.

I don't think I've seen many changes lately, except for those planned
on the CD side (thanks for the detailed announce!), so I'm currently
not anticipating bad surprises (but I'm probably lacking imagination
or wisdom).

(Letting debian-release@ know about the possible upcoming udeb block;
even if that would likely be after the October 17th/18th weekend.)

Mraw,
KiBi.


signature.asc
Description: Digital signature


Bug#798908: debian-cd: Please support grub menuentry shortcuts

2015-10-02 Thread Cyril Brulebois
Steve McIntyre  (2015-10-02):
> [ Adding CC: to d-boot for KiBi and others to see too... ]
> 
> On Sat, Oct 03, 2015 at 12:47:35AM +0200, Samuel Thibault wrote:
> >Steve McIntyre, le Thu 01 Oct 2015 18:43:04 +0100, a écrit :
> >> ACK. Fix in git now so stretch images from today *should* have this
> >> working I hope.
> >
> >Yep, correct, thanks!
> >
> >Does it also mean that the next Jessie point release will have the fix?
> >That would be nice.
> 
> I was just waiting for the stretch images to work before backporting
> the change to the jessie branch of debian-cd. Just done that now...

Yep, thanks for the notice.

Mraw,
KiBi.


signature.asc
Description: Digital signature


  1   2   3   >