Processed: Re: choose-mirror: use httpredir.debian.org by default

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 797340 choose-mirror: use deb.debian.org by default
Bug #797340 [choose-mirror] choose-mirror: use httpredir.debian.org by default
Changed Bug title to 'choose-mirror: use deb.debian.org by default' from 
'choose-mirror: use httpredir.debian.org by default'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
797340: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797340
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#797340: choose-mirror: use httpredir.debian.org by default

[Chris Lamb]

retitle 797340 choose-mirror: use deb.debian.org by default
thanks

> choose-mirror: use httpredir.debian.org by default

s/httpredir/deb/   \o/


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Re: Q: What's the relationship between Secure Boot and debootstrap?

[Hideki Yamane]

On Thu, 2 Aug 2018 15:31:38 +0800
Helen Koike  wrote:
> Yes, that was my fault, sorry about that, I meant we needed to check and
> update the tools that generate images.

 No problem.

 BTW, is there any planned schedule to complete to enable SB in Debian?
 I heard about there's a much progress for it but not sure when it will
 come to Debian.

-- 
Hideki Yamane 

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

[Cyril Brulebois]

Hi,

Thanks for your comments. I really should have thought about putting
the kernel team in copy but it's been a long write-up…

Ben Hutchings  (2018-08-03):
> This looks rather inefficient.  Maybe not a big deal for the small
> number of udebs though.

That's correct on both count: inefficient but also not a pratical issue.

> (Time to put a more powerful scripting language in the installer?
> Even awk would be a step up!)

I'd rather discuss that separately (too many topics already). The
net-retriever part is mainly going to be used by people preparing the
upload anyway.

> > base-installer
> > --
> [...]
> > We could probably modify library.sh to reuse it, but I'd like to have
> > minimal changes (for reasons explained in the very last section). We
> > could probably just iterate over all installed linux-image-'*' packages,
> > pick the one from the src:linux package, and upgrade it from the
> > backports repository.
> 
> You mean the src:linux-latest package, right?

Exactly, sorry for the typo.

> This is kind of unfortunate, but should work.  Even when the set of
> flavours for a architecture is changed, src:linux-latest builds
> transitional packages to support upgrades.

Right, that's what I had in mind, having witnessed the transition from
586 to 686.

> > debian-cd
> > =
> [...]
> > => It might be nice to have some kind of consistency check, at least
> >to make sure the ABI is the same for the linux kernel produced by
> >the d-i build, and for the modules available in the backports
> >suite. [Note: this might be true for weekly builds too, see recent
> >complaints/bug reports.] Bonus points if the source version is
> >checked too, for extra caution.
> 
> It is not a nice bonus, but really important that the source version is
> equal.  Using module udebs older than the kernel image will usually
> (but not always) work, but using newer module udebs will often result
> in unresolvable symbols for some modules.

Right now, we build debian-installer and trigger debian-cd builds under
a udeb freeze, so we cannot be out of sync for alpha releases. That's
why I called it a “bonus” for regular uploads.

But yeah, for weekly builds we don't have such a guarantee, and we won't
have that either for backports (even if we can just coordinate with the
kernel team when we're about to build images with backports enabled).

> > The finish-install script ran as expected, but I ended up with a 4.16
> > kernel from backports in the installed system, as the linux-latest
> > binaries still point to it rather than to 4.17 (presumably because
> > linux/stretch-backports is still Needs-Build on mipsel at the moment).
> 
> That was just forgotten, I'm afraid.  Bastian has just updated linux-
> latest.

Yes, I've seen the git notification pop up on IRC earlier today, thanks!

> > Users would have reproducible results over
> >time, instead of a jumpy target. I don't know debian-cd enough to
> >determine how feasible it would be. I'm also not sure what would happen
> >if we had “old” linux-image packages on the ISO, and “newer” ones on
> >mirrors.
> 
> If they *do* enable network sources then they should get the latest
> version.  This is not so different from installing stable and getting a
> security update instead of the version on the installation image.

Right, that seems reasonable.

(I think I was still a bit surprised by having had 4.16 installed with
4.17 running in d-i; which might not work too well… The other way
around, i.e. a higher version installed, shouldn't be an issue though.)

> > Open questions
> > ==
> > 
> > Now that I've explained (in length…) how it works, I think it's high
> > time we define what our target is.
> > 
> > Due to the volatility of a backports suite, I would tend to not even try
> > to support netboot.
> 
> Agreed.
> 
> > Aiming for a least a netinst image would look good
> > to me. If we can manage that, we can probably also produce a CD1 for
> > those who want to have more packages than just what's on a netinst (I've
> > had at least one such request). I'm not going to debate how many
> > desktops we should have CD1 for, that's really not my call. I'll just
> > mention that size constraints might be tricky since we'll have both the
> > linux-image packages for the base suite and those from the backports
> > suite. The whole DVD/BR thing is probably entirely overkill.
> 
> As I understand it, CD#1 is already fairly useless for non-networked
> (or limited network) installations and DVD#1 is a lot more useful.

OK, I'll leave that up to Steve 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 

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

[Ben Hutchings]

On Thu, 2018-08-02 at 10:56 +0200, Cyril Brulebois wrote:
[...]
> debian-installer
> 
[...]
> net-retriever
> -
[...]
>   
> https://salsa.debian.org/installer-team/net-retriever/commit/09535b0613a85e02d511b92b60683b20405b6d42

This looks rather inefficient.  Maybe not a big deal for the small
number of udebs though.

(Time to put a more powerful scripting language in the installer?  Even
awk would be a step up!)

[...]
> base-installer
> --
[...]
> We could probably modify library.sh to reuse it, but I'd like to have
> minimal changes (for reasons explained in the very last section). We
> could probably just iterate over all installed linux-image-'*' packages,
> pick the one from the src:linux package, and upgrade it from the
> backports repository.

You mean the src:linux-latest package, right?

This is kind of unfortunate, but should work.  Even when the set of
flavours for a architecture is changed, src:linux-latest builds
transitional packages to support upgrades.

[...]
> debian-cd
> =
[...]
> => It might be nice to have some kind of consistency check, at least
>to make sure the ABI is the same for the linux kernel produced by
>the d-i build, and for the modules available in the backports
>suite. [Note: this might be true for weekly builds too, see recent
>complaints/bug reports.] Bonus points if the source version is
>checked too, for extra caution.

It is not a nice bonus, but really important that the source version is
equal.  Using module udebs older than the kernel image will usually
(but not always) work, but using newer module udebs will often result
in unresolvable symbols for some modules.

[...]
> The finish-install script ran as expected, but I ended up with a 4.16
> kernel from backports in the installed system, as the linux-latest
> binaries still point to it rather than to 4.17 (presumably because
> linux/stretch-backports is still Needs-Build on mipsel at the moment).

That was just forgotten, I'm afraid.  Bastian has just updated linux-
latest.

> It was downloaded from the network mirror.
> 
> => It would be nice if we could include the linux-image-* packages from
>backports (and their dependencies) directly on the installation image,
>so as to be indpendent of what's happening in the stretch-backports
>suite on online mirrors.

I agree, it should be possible to install without network sources
enabled.

> Users would have reproducible results over
>time, instead of a jumpy target. I don't know debian-cd enough to
>determine how feasible it would be. I'm also not sure what would happen
>if we had “old” linux-image packages on the ISO, and “newer” ones on
>mirrors.

If they *do* enable network sources then they should get the latest
version.  This is not so different from installing stable and getting a
security update instead of the version on the installation image.

> Open questions
> ==
> 
> Now that I've explained (in length…) how it works, I think it's high
> time we define what our target is.
> 
> Due to the volatility of a backports suite, I would tend to not even try
> to support netboot.

Agreed.

> Aiming for a least a netinst image would look good
> to me. If we can manage that, we can probably also produce a CD1 for
> those who want to have more packages than just what's on a netinst (I've
> had at least one such request). I'm not going to debate how many
> desktops we should have CD1 for, that's really not my call. I'll just
> mention that size constraints might be tricky since we'll have both the
> linux-image packages for the base suite and those from the backports
> suite. The whole DVD/BR thing is probably entirely overkill.

As I understand it, CD#1 is already fairly useless for non-networked
(or limited network) installations and DVD#1 is a lot more useful.

> => 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.

[...]
> 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
> 

Bug#615646: [installation-guide] How do I know which CD has the package I need?

[Wouter Verhelst]

On Sun, Jul 29, 2018 at 02:41:44PM -0400, Nicholas D Steeves wrote:
> On Sun, Jul 29, 2018 at 11:59:34AM +0200, Wouter Verhelst wrote:
> > On Sun, Jul 29, 2018 at 07:50:18AM +0200, Holger Wansing wrote:
> > > +Also, keep in mind: if the CDs/DVDs you are using don't contain some 
> > > packages
> > > +you need, you can always install that packages afterwards from your 
> > > running
> > > +new Debian system (after the installation has finished). If you need to 
> > > know,
> > 
> > Drop the comma (you do need it in German, but English doesn't need it)
> 
> If the subordinate clause precedes the main clause, then the comma is
> mandatory.  Likewise, even if "then" is implied, the comma is
> mandatory.  That said, a comma separating the subordinate and main
> clause is not mandatory if the subordinate clause follows the main
> clause.   /\
> no comma
> If you need to know, on which CD/DVD to find a specific package,
> visit...  /\   /\
>   no comma, because/
>   "on which...package"  mandatory comma  =/
>   is a propositionalfor the "if...package"
>   phrasesubordinate clause
> 
> Are prepositional phrases enclosed by commas in German grammar?

I don't know all the grammatical jargon :-) and my German is old and
rusty, but yes, when translated to German the phrase above would need a
comma after "know". I didn't mean to say it wouldn't need one after
"package"; it does there, which is why I didn't quote that part of the
message.

In general, German requires a lot more commas than other languages do. I
guess they're more relaxed and can take breaks more often ;-)

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Processed: Re: Update comment about fsck.xfs

[Debian Bug Tracking System]

Processing control commands:

> retitle -1 Change passno to 1?
Bug #904093 [partman-xfs] Update comment about fsck.xfs
Changed Bug title to 'Change passno to 1?' from 'Update comment about fsck.xfs'.
> severity -1 normal
Bug #904093 [partman-xfs] Change passno to 1?
Severity set to 'normal' from 'minor'

-- 
904093: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904093
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#861065: Your email box account is about to be suspended

[Nora Westkott]

Email Verification Notification

Your email box account is about to be suspended because it has not be verify by 
the Microsoft verification team. Do verify now 
or it will be suspended.


Microsoft Verification Team



Microsoft © 2018 Webmail .Inc .





























?


THIS MESSAGE IS CONFIDENTIAL. This e-mail message and any attachments are 
proprietary and confidential information intended only for the use of the 
recipient(s) named above. If you are not the intended recipient, you may not 
print, distribute, or copy this message or any attachments. If you have 
received this communication in error, please notify the sender by return e-mail 
and delete this message and any attachments from your computer.

Bug#759428: [installation-guide] non-US is no longer existing, so there is also no "export-restricted" software

[Brian Potkin]

On Thu 02 Aug 2018 at 08:34:04 +0200, Holger Wansing wrote:

> Control: tags -1 + pending
> 
> 
> Ben Hutchings  wrote:
> > On Tue, 2018-07-31 at 11:00 +0200, Holger Wansing wrote:
> > > 
> > > diff --git a/en/post-install/orientation.xml 
> > > b/en/post-install/orientation.xml
> > > index 0ec05037f..f3eb00bee 100644
> > > --- a/en/post-install/orientation.xml
> > > +++ b/en/post-install/orientation.xml
> > > @@ -59,10 +59,13 @@ around this by putting packages on 
> > > hold in
> > >  
> > >  
> > >  One of the best installation methods is apt. You can use the command
> > > -line version of apt or full-screen text version
> > > -aptitude.  Note apt will also let you merge
> > > -main, contrib, and non-free so you can have export-restricted packages
> > > -as well as standard versions.
> > > +line version of apt as well as tools like
> > > +aptitude or 
> > > synaptic
> > > +(which are just graphical frontends for apt).
> > > +Note that apt will also let you merge
> > > +main, contrib, and non-free so you can have restricted packages
> > > +(strictly spoken not belonging to ) as well as packages from
> > > + at the same time.
> > >  
> > >  
> > >
> > 
> > Looks good to me.
> 
> Just committed. Tagging this bug as pending

 +Note that apt will also let you merge 
 
 +main, contrib, and non-free so you can have restricted packages   
 
 +(strictly spoken not belonging to ) as well as packages from  
 
 + at the same time.

I would have "strictly speaking not belonging to...". I cannot recollect
seeing "spoken" used in this context.

-- 
Brian.

Status and open questions for debian-installer with backports support

[Cyril Brulebois]

Hi,

It's been a while since my first proof of concept (demonstrated at the
2014 mini-DebConf in Paris), but I think I've managed to reach a point
where I'm rather content and ready to get bits and pieces merged where
they belong. That doesn't mean I have everything figured out, that's
why I'm reaching out to both the installer & images team!


The primary question we need to discuss is what we are aiming for. I'll
start with a (not so) little flashback to explain what I've worked on,
why, and what is likely (not) going to be our limited target.

This is a long read… I've highlighted “to do”-like items with an arrow
(=>).


debian-installer


First things first, we needed a debian-installer build that knew about a
backported linux kernel, so I hacked my way in debian-installer.git; it
wasn't too hard since we can count on apt to resolve dependencies, and
after all, we only needed the kernel-image udeb and its modules.

The latest branch is stretch-backports-v2, which combines both a number
of commits that are aimed at the master branch, and a couple others that
want to only be used in a stretch-backports branch:

  
https://salsa.debian.org/installer-team/debian-installer/commits/stretch-backports-v2


net-retriever
-

As usual, I've tested the resulting installer with the netboot(-gtk)
image and of course it failed to load additional udebs. These netboot*
images are aimed at booting from the network, and they also need to
fetch additional udebs from a mirror. Since net-retriever only knows
about a single source of udebs, it needed to be told about multiple
sources (stretch and stretch-backports) and also how to merge entries.
I've detailed my choices in this commit in particular:

  
https://salsa.debian.org/installer-team/net-retriever/commit/09535b0613a85e02d511b92b60683b20405b6d42

For more details, see the whole stretch-backports-v2 branch for
net-retriever:

  
https://salsa.debian.org/installer-team/net-retriever/commits/stretch-backports-v2

Now, it doesn't matter too much, since the stretch-backports repository
will evolve over time, and udebs for the specific kernel used during the
d-i build will disappear. I think this is too much of a volatile (no
pun intended) target to support. It's still a very nice way to test d-i
without having to build an ISO with debian-cd, so I'd like to merge
these changes in net-retriever anyway.


base-installer
--

Second, it makes quite some sense to not only run d-i with a newer
kernel, but to also install it, so that users can boot from their brand
new hardware that wasn't supported by d-i with stable components only.

The kernel selection and installation is implemented in base-installer
(see library.sh), and that happens to run before apt-setup. Since I
didn't want to butcher sources.list manually to install the kernel
directly at this stage, I've decided to implement installing the latest
kernel from backports in a finish-install script (also shipped in the
base-installer package, for consistency), running at the very end of the
installation process.

This only happens when backports support was enabled (this is detected
through the presence of /etc/udebs-backports-source).

At first, using the linux-image-$arch metapackage looked easy enough but
of course that works for amd64, but not for i386 (one would need to pick
686 or 686-pae). I've still pushed a branch with this implementation as
it can be useful as is:

  
https://salsa.debian.org/installer-team/base-installer/commits/stretch-backports-v0

We could probably modify library.sh to reuse it, but I'd like to have
minimal changes (for reasons explained in the very last section). We
could probably just iterate over all installed linux-image-'*' packages,
pick the one from the src:linux package, and upgrade it from the
backports repository.

=> I'll look into that later on.



apt-setup
-

Also only when /etc/udebs-backports-source is present, the backports
service gets automatically enabled, which makes the later installation
of linux-image packages possible.

Single commit for this:

  
https://salsa.debian.org/installer-team/apt-setup/commit/6133bdcd5a7903105ad967ab087f2f12f9d1c59d



debian-cd
=

As mentioned above, tricks were needed in net-retriever for the netboot*
images, to make it possible to load linux kernel modules udebs. Those
tricks aren't needed when generating an ISO image. As a reminder, on the
d-i side, a cdrom_isolinux image is generated, and the debian-cd tool
needs to be configured to use that image instead of the official image
available on the configured mirror.

I didn't make this dynamic yet, but I've modified my local configuration
to set BACKPORTS=backports-list, to include a number of packages from
the stretch-backports suite. This file was generating by listing all
udebs produced by the linux source package (as done in the d-i build
system):

USE_UDEBS_BACKPORTS_FROM=stretch-backports
...
source=linux
...
  

Re: Q: What's the relationship between Secure Boot and debootstrap?

[Helen Koike]

On 08/01/2018 06:37 AM, Hideki Yamane wrote:
> On Tue, 31 Jul 2018 17:11:14 +0100
> Steve McIntyre  wrote:
>> That kind of thing, yes. Should have been clearer. Debootstrap itself
>> doesn't install a kernel or bootloader, which were the packages I was
>> thinking about.
> 
>  Then, we don't need to modify debootstrap package for SB at all, right?
>  If so, please update your slide before upload.
> 

Yes, that was my fault, sorry about that, I meant we needed to check and
update the tools that generate images.

Helen

Re: Apologies for failing to communicate

[Thomas Goirand]

On 07/31/2018 03:16 PM, Vagrant Cascadian wrote:
> I'm finding the need to apologize for neglecting to communicate to the
> debian-installer development community over some BoF sessions at the
> last two DebConfs regarding alternatives to and possible replacements
> for debian-installer.
> 
> In retrospect, it was a terribly obvious oversight in communication, and
> doubly so that it happened two years in a row. I can even see that the
> language used in the talk descriptions could be interpreted poorly. All
> I can really do at this point is apologize and promise to do better in
> the future, for whatever that is worth.
> 
> I hate the thought that I've contributed to anyone's demotivation. Truly
> sorry.
> 
> I admire and benefit from the work of the debian-installer
> developers. I've used it regularly for many years, recommend it to
> others. Despite seeing some issues with it and dreaming of alternatives,
> I'll continue to contribute to d-i where and when I can, and intend to
> continue to do so for the forseeable future.
> 
> 
> live well,
>   vagrant
> 
> P.S. Please CC me on replies, as I'm not subscribed to debian-boot, or
> feel free to reply privately if you prefer.

Hi,

I also would like to add that some of us want to at least investigate
ways to have d-i running over on top of libc6 first, which means more
help for the d-i maintainers.

Cheers,

Thomas Goirand (zigo)

Processed: Re: Bug#759428: [installation-guide] non-US is no longer existing, so there is also no "export-restricted" software

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + pending
Bug #759428 [installation-guide] d-i manual: non-US is no longer existing, so 
there is also no "export-restricted" software
Added tag(s) pending.

-- 
759428: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759428
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#759428: [installation-guide] non-US is no longer existing, so there is also no "export-restricted" software

[Holger Wansing]

Control: tags -1 + pending


Ben Hutchings  wrote:
> On Tue, 2018-07-31 at 11:00 +0200, Holger Wansing wrote:
> > 
> > diff --git a/en/post-install/orientation.xml 
> > b/en/post-install/orientation.xml
> > index 0ec05037f..f3eb00bee 100644
> > --- a/en/post-install/orientation.xml
> > +++ b/en/post-install/orientation.xml
> > @@ -59,10 +59,13 @@ around this by putting packages on hold 
> > in
> >  
> >  
> >  One of the best installation methods is apt. You can use the command
> > -line version of apt or full-screen text version
> > -aptitude.  Note apt will also let you merge
> > -main, contrib, and non-free so you can have export-restricted packages
> > -as well as standard versions.
> > +line version of apt as well as tools like
> > +aptitude or synaptic
> > +(which are just graphical frontends for apt).
> > +Note that apt will also let you merge
> > +main, contrib, and non-free so you can have restricted packages
> > +(strictly spoken not belonging to ) as well as packages from
> > + at the same time.
> >  
> >  
> >
> 
> Looks good to me.

Just committed. Tagging this bug as pending


-- 

Created with Sylpheed 3.5.1 under 
D E B I A N   L I N U X   9   " S T R E T C H " .

Registered Linux User #311290 - https://linuxcounter.net/