Re: 10.6 planning

2020-09-09 Thread Andy Simpkins
I can do either and have no preferance.
/Andy



On 9 September 2020 19:24:06 BST, "Adam D. Barratt"  
wrote:
>Hi all,
>
>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
>
>Thanks,
>
>Adam

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

2020-07-18 Thread Andy Simpkins


On 18 July 2020 22:39:05 BST, Steve McIntyre  wrote:
>On Sat, Jul 18, 2020 at 10:12:41PM +0100, Adam Barratt wrote:
>>On Sun, 2020-07-12 at 15:35 +0100, Adam D. Barratt wrote:
>>> Hi Steve,
>>> 
>>> On Sun, 2020-07-12 at 12:46 +0100, Steve McIntyre wrote:
>>> > Argh, massive apologies...
>>> > 
>>> > On Thu, Jun 25, 2020 at 10:38:14AM +0200, Laura Arjona Reina
>wrote:
>>> > > El 15/6/20 a las 18:44, Adam D. Barratt escribió:
>>> > > > - July 18/19
>>> > 
>>> > Massive apologies for dropping a spanner in the works, but
>>> > something major has come up. I won't be able to do *all* of that
>>> > weekend after all. As Stretch EOL is already a thing, can I
>suggest
>>> > that we keep that to plan and push back the Buster 10.5 release a
>>> > little?
>>> > 
>>> > Sorry. :-/
>>> 
>>> Thanks for letting us know. :-(
>>> 
>>> I'll drop a note to the lists, and we can look at getting a new date
>>> organised.
>>
>>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
>
>Either is possible for me, with a preference for the first. Let's not
>delay too long if possible.
>
>Cheers,
>
>Steve
>
>-- 
>Steve McIntyre, Cambridge, UK.   
>st...@einval.com
>  Armed with "Valor": "Centurion" represents quality of Discipline,
>  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
>  concord the digital world while feeling safe and proud.

-- 
I am good for either weekend.
Given a preferance i would prefer the 1st.  

Cheers
/Andy
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

2020-06-15 Thread Andy Simpkins
On 15/06/20 19:05, Cyril Brulebois wrote:
> Hi,
> 
> Adam D. Barratt  (2020-06-15):
>> To get the ball rolling, please could you confirm your availability
>> for:
>>
>> - July 11/12
>> - July 18/19
> 
> 
> Anyway, I should be available, whatever date(s) get picked.
> 
Preferance would be the weekend of the 18/19 for Isy and me (we have
plans for the weekend before).

/Andy




signature.asc
Description: OpenPGP digital signature


Re: Debian 10.3 XFCE from torrent failed verification (FALSE ALARM)

2020-05-09 Thread Andy Simpkins
Hi Jason


You might want to wait a few hours. we are in the middle of 10.4 release right 
now.  So expext 10.4 XFCE. To be availabe today (overnight?)

Cheers

On 9 May 2020 13:38:06 BST, Jason Quinn  wrote:
>Thanks Steve for the quick reply.
>
>You are correct. My report appears to be a false alarm due to an
>incomplete
>download.
>
>Apologies for the inconvenience but thanks to the whole Debian Team for
>all
>you do!
>
>Cheers,
>Jason
>
>On Sat, May 9, 2020 at 6:22 PM Steve McIntyre  wrote:
>
>> I've just tested now:
>>
>> $ btdownloadcurses.bittorrent
>>
>https://cdimage.debian.org/debian-cd/current-live/amd64/bt-hybrid/debian-live-10.3.0-amd64-xfce.iso.torrent
>> 
>> $ sha256sum debian-live-10.3.0-amd64-xfce.iso
>> 898fa914f4615dcb8fb4da9e351fa370d7f142bceaee76fa44e11e440dda44a6
>> debian-live-10.3.0-amd64-xfce.iso
>>
>> and that checksum matches the one in
>>
>>
>>
>https://cdimage.debian.org/debian-cd/current-live/amd64/bt-hybrid/SHA256SUMS
>>
>> This sounds like you have a problem locally, to be honest. Did your
>> torrent client show any errors at all?
>>
>> --
>> Steve McIntyre, Cambridge, UK.
>> st...@einval.com
>> "I've only once written 'SQL is my bitch' in a comment. But that code
>>  is in use on a military site..." -- Simon Booth
>>
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Default security sources are slow very much.

2020-02-06 Thread Andy Simpkins
I stand corrected.
I learned somthing new today
Thanks

On 6 February 2020 12:54:03 GMT, Ian Campbell  wrote:
>On Thu, 2020-02-06 at 07:41 +0000, Andy Simpkins wrote:
>> It isn't safe to mirror security patches because we can not assure
>> the integrity of the updates on a mirror server.
>
>The security mirrors are secured by by apt using the same cryptographic
>signatures as the other suites, so that's not true, they can be
>mirrored just fine (at least in principal, I don't know how much of the
>mirror network actually carries them).
>
>I think the real reason the default security sources are the
>main/central one is to reduce the latency in getting critical/urgent
>fixes out (i.e. no need to wait for a mirror pulse), but if that
>doesn't work for a given setup there's no reason not to change to use a
>mirror, it looks like deb.debian.org supports security so presumably
>that's a good bet.
>
>Ian.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Default security sources are slow very much.

2020-02-05 Thread Andy Simpkins
Sorry.  No.
It isn't safe to mirror security patches because we can not assure the 
integrity of the updates on a mirror server.

We are aware that bandwidth is limited either for financial or geographic 
reasons.This is why you can install from local media without network 
access.  

However any updates AFTER that image has been created will need to be 
downloaded from somewhere.

All i can suggest is that you install images of the latest release (there is a 
point release this comming weekend) as this will include all the fixes 
currently available...

On 5 February 2020 01:34:59 GMT, ykla  wrote:
>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.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Debootstrap Aarch64 base system.not include package haveged

2020-02-05 Thread Andy Simpkins
What are the many errors you are seeing?


From what I recall things take a while (in the case of some platforms without a 
HRND enabled that can be several hours) to buuld up enough entropy before some 
services (such as sshd) can successfully start.  

I agree that havegd will help here.  But is this really the fault of 
Debootstrap?

Just because your debootstrap is slow to start because it is entropy starved 
isn't a bug in itself. Perhaps the correct thing to do would be add an entropy 
gathering package to offer to enable differant HRNGs it can autodetect and then 
offer a MetaRNG (such as havegd).  

Of cause should this be a recommended package or default?
Should it be linked/installed  by system and environment packages that provide 
random services or by consumers of random such as sshd?

On 5 February 2020 01:26:58 GMT, ykla  wrote:
>Debootstrap aarch64 base system not includes haveged, It makes many
>errors
>for ssh. SSH only open after local user login.Please add haveged
>default.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Set root password will not install sudo

2020-02-05 Thread Andy Simpkins
You also have a user account as well.
So you can, and should, log in using that.



On 5 February 2020 01:22:56 GMT, ykla  wrote:
>If you set root password when you installs debian, then system will not
>install package sudo. But debian ban root login default. So install CD
>should install sudo whether user sets root password.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Planning 10.3 and 9.12

2020-01-07 Thread Andy Simpkins
I can do any of these.  Probably best avoid FOSDEM though.

/Andy

On 6 January 2020 21:42:29 GMT, "Adam D. Barratt"  
wrote:
>Hi,
>
>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
>
>Thanks,
>
>Adam

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#941333: Wifi network detection during installation. Suggested improvement.

2019-09-28 Thread Andy Simpkins
Right now you would get a "no network device found" / "no netwirk found" / 
"unable obtain an IP address" message.

Is this not sufficiant?

You are given the option to go back and try again.  Please remember that it is 
also possible that no wifi device wiuld have been detected either.

Lets face it if you do happen to have a wifi adapter that has been detected (or 
you have loaded non free firmware for) and it does not detect the network AND 
offer you any other wifi ssid to pick from, then you are already going to 
notice that somthing isn't right.

/Andy


On 28 September 2019 23:38:48 BST, Clinton H <49studeba...@gmail.com> wrote:
>Package: cdrom
>
>If no wifi networks are detected, could you display a "If using a
>laptop, check that the manual wifi switch is set to ON." warning
>message and then retry detecting wifi networks. If the manual wifi
>switch is set to OFF, then wifi networks will not be detected.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Missing Firmware

2019-08-20 Thread Andy Simpkins
On 19/08/19 17:00, slow_sp...@att.net wrote:
> You may be interested to know that the iso's listed at
> https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/10.0.0-live+nonfree/amd64/iso-hybrid/
> 
> are missing some firmware information.
> 
> I selected the debian-live-10.0.0-amd64-xfce+nonfree.iso for my Dell
> Studio XPS notebook computer.  It always had complained that it needed
> the B43 Broadcom firmware files of b43/ucode16_mimo.fw and
> b43-open/ucode16_mimo.fw.
> 
> Whenever I would install Debian Buster it would look for those.  It
> never made any difference if I added the missing files to another flash
> drive in another USB port or swapped into the same port, they were never
> found by the install process.
> 
> With the new iso, it did exactly the same thing.  Evidently the non-free
> version does not contain the missing firmware anyway.
> 
> Please advise as to how to get the install to look for the *.deb or
> other files containing the necessary firmware.
> 
> Thank you.
> 
> 
> 
Hi there,

A quick note to acknowledge your post.

The B43 firmware resides in the following packages in the non-free
section of the repository:
  b43-fwcutter_019-4_amd64.deb
  firmware-b43-installer_019-4_all.deb
  firmware-b43legacy-installer_019-4_all.deb


*IF*

You are wanting to install onto your laptop, the firmware *IS* part of
the manifest for the non-free installation image
i.e.https://cdimage.debian.org/images/unofficial/non-free/cd-including-firmware/10.0.0+nonfree/amd64/iso-cd/

*BUT IF*

You just want to run a live image at this point in time I agree with you
that this appears to be missing.
Looking at the manifest of the 'live' images I do not see mention of the
B43 drivers...

<< Highvoltage >>  Can you confirm this please?


BR
/Andy








Re: Scheduling 10.1 and maybe 9.10

2019-07-29 Thread Andy Simpkins
Ok I'll mark it on family calendar 

On 29 July 2019 10:47:09 GMT-03:00, Jonathan Wiltshire  wrote:
>Ok, we have a winner. Let's make them both 7th September so press
>aren't
>under too much pressure.
>
>-- 
>Jonathan Wiltshire  j...@debian.org
>Debian Developer http://people.debian.org/~jmw
>
>4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Scheduling 10.1 and maybe 9.10

2019-07-20 Thread Andy Simpkins
Either wfm thanks

On 21 July 2019 00:36:30 BST, Jonathan Wiltshire  wrote:
>On Sun, Jul 14, 2019 at 07:35:01PM +0100, Jonathan Wiltshire wrote:
>>  - August 24th
>
>I have no idea how I missed the event that weekend...
>
>>  - Auguest 31st
>>  - September 7th
>
>These look like the two options so far. Any other takers?
>
>> We also have a point release of 9.10 to fit in some time - would the
>same
>> day or adjacent weekends be preferable?
>
>Consensus seems to be to do them together.
>
>
>
>-- 
>Jonathan Wiltshire  j...@debian.org
>Debian Developer http://people.debian.org/~jmw
>
>4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Dropping older, less-secure checksums files

2019-07-16 Thread Andy Simpkins
I wouldn't object to dropping the older hashes completely



On 16 July 2019 16:04:28 BST, Holger Levsen  wrote:
>On Tue, Jul 16, 2019 at 03:58:13PM +0100, Steve McIntyre wrote:
>> ...I'm looking
>> into dropping generation of the older, less secure MD5 and SHA1
>> checksums. I'm planning on leaving these alone for existing releases,
>> including for future stretch and buster point release builds. But for
>> regular daily/weekly builds of testing/bullseye images, I'm going to
>> drop the MD5SUMS and SHA1SUMS files.
>
>no problem, just great, thank you!

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Testing release images - Call for help

2019-06-30 Thread Andy Simpkins
Hi there,

We have the release of Buster scheduled to happen next Saturday.  As
always on a release day new iso images are generated and *before* they
get signed we try and smoke test them to make sure that the builds went
ok and nothing critical is missing from the manifests.  We do the same
for live images as well.

If you can spare the time your help would be greatly appreciated in
testing some of these images on the day. If you have time to test before
then too, that would be even more helpful!

Along with the usual amd64/i386/arm64 installer builds we'll be
explicitly testing, we need specific help for testing LIVE images
(including 2 different install methods) on BARE METAL PCs (i.e. NOT a
VM).  We are looking for tests to be carried out on machines running
BIOS as well as UEFI. Buster will also be our first Debian release to
include support for UEFI Secure Boot, and more test coverage there would
be lovely.

Additionally we are also looking for people who can test the following:
 * debian-mac.10.0.0-amd64-netinst.iso
 * debian-mac.10.0.0-i386-netinst.iso
 * debian-10.0.0-mips-*.iso (Multiple images)
 * debian-10.0.0-mipsel-*.iso   (Multiple images)
 * debian-10.0.0-mips64el-*.iso (Multiple images)
 * debian-10.0.0-ppc64el-*.iso  (Multiple images)
 * debian-10.0.0-s390x-*.iso(Multiple images)

On release day (Saturday 6th July), we are expecting installer images to
become available from around 1300 UTC, with live images between 1.5 and
2 hours later.

To get a reasonable coverage of DI there is a wiki matrix [0] of the
install tests that we will perform (although feel free to try 'your'
specific install options.

Wiki is not the *best* solution for a matrix that will change quite a
bit during the test process, it is far to easy to have edit clashes.  To
reduce this we try and coordinate our action in on #debian-cd or
irc.debian.org

Please check in on irc *before* starting a test to reduce duplicate
tests being carried out.

Finally if you want to get in some early testing of DI over the next few
days please do.  if you find a critical problem there may just be enough
time to fix it

Let's make buster the smoothest release yet :-)

/Andy


[0]  https://wiki.debian.org/Teams/DebianCD/ReleaseTesting/Buster_r0






Re: Same hashfiles for files that should be different from each other?

2019-03-30 Thread Andy Simpkins



On 30/03/2019 10:16, Andy Simpkins wrote:


On 30/03/2019 09:56, Thomas Schmitt wrote:

Hi,

i wrote:

The same checksum duplicity can be seen with
   5849124a0e25d1318a880e98b9a8123f 
debian-live-9.8.0-amd64-cinnamon.contents
   5849124a0e25d1318a880e98b9a8123f 
debian-live-9.8.0-amd64-gnome.contents

Andy Simpkins  wrote:

That is exactly what Kuijpers has just pointed out.

Evert Kuijpers pointed to "lxde" and "mate" on "i386" and "amd64".
My run of program "sort" reveiled that "cinnamon" and "gnome" form a 
pair,

too (at least on "amd64").



the issue could be in one of several places. [...]
(2) we are building the content of the ISOs
correctly, but incorrectly reporting the manifest

This can be ruled out.
I downloaded debian-live-9.8.0-amd64-lxde.iso and
debian-live-9.8.0-amd64-mate.iso. Mounted them at /mnt/iso and compared
the outputs of
   find /mnt/iso | sed -e 's/^\/mnt\/iso//' | sort

They are identical.

The results of "find" differ from the identical .content files only by
the paths "/isolinux/boot.cat", for which there is a plausible 
explanation

in the ISO production process.



(3) we are reporting the
manifest correctly and we are reporting incorrect checksums

This can be ruled out.
"md5sum" confirms the MD5s. "diff" confirms that the .content files have
identical content.


Have a nice day :)

Thomas



---
This email has been checked for viruses by AVG.
https://www.avg.com



Hi Thomas

Ack.


So it looks like the contents are identical.  This isn't entirely 
surprising - the packages are after all should be the same.  I am 
guessing at this point (and still looking) but there manifests between 
the different desktop environments (after the desktop environment 
itself) will be very similar, and only differ from one another because 
of the size of the desktop environment itself (i.e. a smaller 
environment takes up less space so there is more room for additional 
packages, a larger desktop has less space available so the manifest of 
packages is therefore smaller).


Sledge would be able to confirm this with authority, but I believe he 
is away at the moment.  I will continue digging to try and confirm 
this hypothesis



/Andy


OK so whilst the .contents files are the same for 
debian-live-9.8.0-amd64-cinnamon.contents and 
debian-live-9.8.0-amd64-gnome.contents  their corresponding .packages 
files are not the same, thus indicating (to me - perhaps mistakenly) 
that there is a problem and that this is NOT correct behaviour.



still digging


/Andy



Re: Same hashfiles for files that should be different from each other?

2019-03-30 Thread Andy Simpkins



On 30/03/2019 09:56, Thomas Schmitt wrote:

Hi,

i wrote:

The same checksum duplicity can be seen with
   5849124a0e25d1318a880e98b9a8123f debian-live-9.8.0-amd64-cinnamon.contents
   5849124a0e25d1318a880e98b9a8123f debian-live-9.8.0-amd64-gnome.contents

Andy Simpkins  wrote:

That is exactly what Kuijpers has just pointed out.

Evert Kuijpers pointed to "lxde" and "mate" on "i386" and "amd64".
My run of program "sort" reveiled that "cinnamon" and "gnome" form a pair,
too (at least on "amd64").



the issue could be in one of several places. [...]
(2) we are building the content of the ISOs
correctly, but incorrectly reporting the manifest

This can be ruled out.
I downloaded debian-live-9.8.0-amd64-lxde.iso and
debian-live-9.8.0-amd64-mate.iso. Mounted them at /mnt/iso and compared
the outputs of
   find /mnt/iso | sed -e 's/^\/mnt\/iso//' | sort

They are identical.

The results of "find" differ from the identical .content files only by
the paths "/isolinux/boot.cat", for which there is a plausible explanation
in the ISO production process.



(3) we are reporting the
manifest correctly and we are reporting incorrect checksums

This can be ruled out.
"md5sum" confirms the MD5s. "diff" confirms that the .content files have
identical content.


Have a nice day :)

Thomas



---
This email has been checked for viruses by AVG.
https://www.avg.com



Hi Thomas

Ack.


So it looks like the contents are identical.  This isn't entirely 
surprising - the packages are after all should be the same.  I am 
guessing at this point (and still looking) but there manifests between 
the different desktop environments (after the desktop environment 
itself) will be very similar, and only differ from one another because 
of the size of the desktop environment itself (i.e. a smaller 
environment takes up less space so there is more room for additional 
packages, a larger desktop has less space available so the manifest of 
packages is therefore smaller).


Sledge would be able to confirm this with authority, but I believe he is 
away at the moment.  I will continue digging to try and confirm this 
hypothesis



/Andy





Re: Same hashfiles for files that should be different from each other?

2019-03-30 Thread Andy Simpkins



On 30/03/2019 08:49, Thomas Schmitt wrote:

Hi,

(Cc-ing debian-l...@lists.debian.org)

Evert Kuijpers  wrote to debian-cd:

Both debian-live-9.8.0-i386-lxde.contents and
debian-live-9.8.0-i386-mate.contents have all the same hashes.
Both debian-live-9.8.0-amd64-lxde.contents and
debian-live-9.8.0-amd64-mate.contents have all the same hashes.
It is quite possible that two of these four files should have different
contents.

See https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/
and https://cdimage.debian.org/debian-cd/current-live/i386/iso-hybrid/

Greetings from Evert Kuijpers, Tilburg in The Netherlands, hyss...@gmail.com

That's because they have identical file content, because the trees of the
ISOs bear identical file paths which nearly match the .content paths list.
(The file paths "/isolinux/boot.cat" are not in .content, because these
  file paths got created by option -c of xorrisofs when the ISO was produced.)

So the question is whether it is normal that both ISOs have absolutely
identical file paths in their trees.

The same checksum duplicity can be seen with
   5849124a0e25d1318a880e98b9a8123f  debian-live-9.8.0-amd64-cinnamon.contents
   5849124a0e25d1318a880e98b9a8123f  debian-live-9.8.0-amd64-gnome.contents


That is exactly what Kuijpers has just pointed out.

Clearly something has gone wrong with the automated build somewhere - 
different desktop environments should have a different manifest from 
each other...


Thank you for pointing out there is an issue.

I have not looked yet - but the issue could be in one of several 
places.  (1) The manifest is incorrect and we are building identical 
ISOs and just giving different names to them  (2) we are building the 
content of the ISOs correctly, but incorrectly reporting the manifest 
(3) we are reporting the manifest correctly and we are reporting 
incorrect checksums


I'll take a closer look now

/Andy



Re: Scheduling 9.9

2019-02-21 Thread Andy Simpkins
On 20/02/19 18:28, Jonathan Wiltshire wrote:
> Hi,
> 
> Please indicate your availablility out of:
> 
>  - April 13   
>  - April 20 (Easter weekend)
Sorry I am away for the above two weekends

>  - April 27
Can do
> 

/Andy