Re: Re-planning for 12.6

[Andy Simpkins]

On 21/04/2024 01:57, Steve McIntyre wrote:

On Sat, Apr 20, 2024 at 05:41:13PM +0100, Jonathan Wiltshire wrote:

On Thu, Apr 18, 2024 at 10:58:41PM +0100, Steve McIntyre wrote:

Hiya!

Not wanting to pester *too* much, but where are we up to?


Right now I can still have 27th April on the cards but we're missing FTP and
press. It's next week, we'd have to know this weekend and get frozen.
Mark indicated "maybe" and no answer from press.

If that date works please reply urgently otherwise we're looking into May
and possibly just skipping to line up with the final bullseye anyway.

It works for me, I guess. Dunno about other folks.



I can still do 27th but as I have already stated Isy is now unavailable 
until July due to exams.


Please can we make a decision by Tuesday otherwise I'll end up doing 
something else



/Andy

Re: Re-planning for 12.6

[Andy Simpkins]

On 01/04/2024 13:07, Adam D. Barratt wrote:

Hi,

As we had to postpone 12.6, let's look at alternative dates.

April 13th
- Not great for me for personal reasons, mhy previously said no. I
could probably do if need be

April 20th
- Doesn't work for me; I'm away from the Tuesday before until late on
the Friday

April 27th
- Doesn't work for me; I have a pre-existing appointment which means
I'll be AFK much of the day

May 4th
- Apparently doesn't work for me; long weekend in the UK

May 11th
- Should work for me

Regards,

Adam



Hi all,

May the 11th is fine for me.  Sorry we will not get an Isy as she will 
be deep into her exams by then. But we'll be ok, given this is just 12.6 
(and not a double release)



/Andy

Re: Upcoming stable point release (12.6)

[Andy Simpkins]

On 29/03/2024 22:34, Steve McIntyre wrote:

On Fri, Mar 29, 2024 at 10:24:09PM +, Adam Barratt wrote:

On Fri, 2024-02-16 at 17:35 +, Jonathan Wiltshire wrote:

The next point release for "bookworm" (12.6) is scheduled for
Saturday, April 6th. Processing of new uploads into bookworm-
proposed-updates will be frozen during the preceeding weekend.

Due to recent events, the point release has been postponed. A new date
will be announced when possible.

ACK, thanks for the update


Ack understood

Re: Planning for 12.3

[Andy Simpkins]

On 9 November 2023 18:15:43 GMT, "Adam D. Barratt"  
wrote:
>On Thu, 2023-11-09 at 14:55 +, Steve McIntyre wrote:
>> On Fri, Oct 27, 2023 at 11:28:21AM +0100, Steve McIntyre wrote:
>> > Argh, forgot to respond to this. :-(
>> > 
>> > On Sat, Oct 07, 2023 at 06:59:03PM +0100, Jonathan Wiltshire wrote:
>> > > Hi,
>> > > 
>> > > The next point release for bookworm should be around the end of
>> > > November
>> > > 2023. We're about a week behind cadence anyway, but I already
>> > > know the 28th
>> > > November will be unsuitable (Cambridge mini-debconf) and the
>> > > weekend
>> > > following is probably recovery time for a lot of people.
>> > > 
>> > > Much after that we get into holidays and well off cadence.
>> > > 
>> > > How about:
>> > >  4th December (better for cadence)
>> > > 11th December (more likely suitable in practice)
>> > 
>> > Both of those currently look feasible for me.
>> 
>> Do we have a decision being made yet please?
>
>Assuming everyone's still OK with their previous responses, it looks
>like we're going for December 9th. (Not the 11th, as Jonathan
>apparently fails at using a calendar.)
>
>If anyone's not happy with that, please yell *soon*.
>
>Regards,
>
>Adam
>
>

Adam,

All good for me.  But as previously mentioned Isy will pass due to sitting mock 
exams both sides

/Andy

Re: i386 in Debian 13 Trixie

[Andy Simpkins]

On 7 August 2023 18:22:09 BST, M Goppold  wrote:

Greetings People!!

Seems in the testing cd-s, I dont see i386 at all anymore.
https://cdimage.debian.org/cdimage/weekly-builds/

I tried web searches to find out the status of debian and i386.  But I couldnt 
find any information.  Maybe its due to the deterioration of some search 
engines.

Is there a removal going on that I havent heard about?  Is it related to 
Intel's x86S spec?

Sincerely,
Mike Goppold
mgoppo...@yahoo.com




Hi there Mike

Thanks for reaching out.

Yes we have stopped producing installation media images for i386.

As a project Debian still supports i386, and will continue to provide 
updates via the usual apt repositories.  This will continue throughout 
the Trixie life-cycle.


There is a rapidly vanishingly small number of people who actually need 
a new installation on the i386 platform.
Most users should find that the AMD64 version works just fine for them, 
after all new 32 bit Intel compatible processors that are not also 
natively AMD64 systems haven't been manufactured for many years.


In the cases where you need to keep an existing machine going then you 
can still upgrade from a previous bookworm installation, security 
updates and the i368 repositories are not going anywhere.


And for those people who want to keep using old software at a given 
version, for example retro-gaming, or big company account packages, then 
running a newer version of Debian may introduce more problems because 
the vintage software may be dependent upon features of the operating 
system that have been deprecated, replaced, or removed altogether.


So no, you correct, there are no new images being generated for testing 
Trixie installations on i386 platforms.  In most cases you probably 
should be using the AMD64 images, and probably could have been for a 
decade or more



I hope this answers your question,

Best wishes
/Andy

Re: 11.8/12.2 planning

[Andy Simpkins]

On 28 June 2023 09:09:42 BST, Cyril Brulebois  wrote:
>Jonathan Wiltshire  (2023-06-28):
>> The proper cadence for 11.8 and 12.2 is the weekend of 30th September
>> 2023. Please indicate your availability for:
>> 
>> 23 Sep
>> 30 Sep (preferred)
>> 7 Oct
>
>I should be able to make any of those work for the installer team, and
>optionally for the images team.
>
>
>Cheers,

I can do any of those dates

Re: 11.4 planning

[Andy Simpkins]

On 17 June 2022 21:04:02 BST, "Andrew M.A. Cater"  wrote:
>On Fri, Jun 17, 2022 at 08:31:23PM +0100, Adam D. Barratt wrote:
>> Hi,
>> 
>> We're (again) running behind in getting the next point release for
>> bullseye sorted, and I know we're about to run into the Deb{Camp,Conf}
>> period. I think the possible dates that make sense are:
>> 
>> - July 2nd (means freezing next weekend, but so be it)
>> - July 9th
>> 
>
>Hi Adam
>
>I'll tag along with whatever the rest of the images team want to do :)
>Always fond of doing this.
>
>With every good wish,
>
>Andy Cater
>> 
>> Thanks,
>> 
>> Adam
>> 
>
>

Hi there.
I am afraid we can't help either weekend.  Isy has her school prom and a 
shooting eventone each weekend meaning she can't be there, and I have 
already committed as taxi...

If release were to go ahead either weekend I could drop in, but wouldn't be 
able to stay the distance.  Sorry

Andy

Bug#1011343: WISHLIST: Offical ALL-IN-ONE images?

[Andy Simpkins]

On 20 May 2022 15:11:09 BST, Zhang Boyang  wrote:
>Package: debian-cd
>
>Hello,
>
>I suggest debian release a new variant of ISO images, the all-in-one images. 
>These all-in-one image contains ALL debian packages in a single ISO image 
>(possibly all source packages in another all-in-one ISO image). Of course 
>there is no such optical media can hold such a big image, but it is useful for 
>virtual-machines, remotely managed servers, and archival purposes. The 
>theoretical size limit of an ISO9660 filesystem is about 8TB, which is 
>sufficient for including all debian packages.
>
>For the name of this variant, I suggest 'everything', 'allinone', 'world', 
>'virt'.
>
>p.s. This is my personal interest, and I would appreciate if you can kindly 
>consider my suggestion.
>
>
>Best Regards,
>Zhang Boyang
>
>

Sorry to put a dampener on your suggestion but why would you need that?

Why not just mirror the archive to a local disk instead?

Then you have your copy of everything and can just point a netinst at your 
local mirror so you can install from there.

I think that would deliver on every use case that you would be able to use your 
big ISO image and more

Re: 11.3 and 10.12 planning

[Andy Simpkins]

On 07/03/2022 23:38, Steve McIntyre wrote:

On Sun, Mar 06, 2022 at 09:51:57PM +, Adam Barratt wrote:

Hi,

As you may have noticed, we're a bit overdue now for both 11.3 and the
penultimate buster point release, 10.12.

Some potential dates:

- March 19th (means freezing next weekend, so not ideal)
- March 26th
- April 2nd
- April 9th


The 19th is awkward for me (and Andy S!) - prior commitments. The
others look OK for me.



Hi Everyone,

I can do the 26th March or the 9th of April.
Sorry the 2nd April is not available for me either

BR

/Andy

Re: 11.2 planning

[Andy Simpkins]

On 23/11/2021 20:18, Steve McIntyre wrote:

Hey Adam!

On Tue, Nov 23, 2021 at 08:12:11PM +, Adam Barratt wrote:


It's (a little past) time that we organised the next point release. As
an "every other" release, this time will only be for stable.

Any of the first three weekends of December would work for me, although
the 4th is my least preferred as it means freezing over the coming
weekend and I'm not sure if I'll have time to do a fair job of dealing
with things before that.

tl;dr, suggested dates:

December 4th [least preferable for me]
December 11th
December 18th


4th December is a no-go for me, but the 11th and 18th look OK.



Likewise 11th & 18th December are good for us (can't do 4th either)

/Andy & Isy

Re: 11.1 and 10.11 planning

[Andy Simpkins]

On 14/09/2021 20:14, Steve McIntyre wrote:

On Tue, Sep 14, 2021 at 07:04:11PM +0100, Adam Barratt wrote:

Hi,

Thanks for the responses everyone. Mark indicated on IRC that he'd be
happy to be ftpmaster-du-jour on any of the dates.

On Mon, 2021-09-06 at 12:51 +0100, Adam D. Barratt wrote:

We've ended up being late with planning 10.11 due to the timing of
the bullseye release, and also need to look at getting 11.1 sorted.

[...]

September 18th - not great; means freezing this coming weekend
September 25th - not great; I'm away during most of the week
beforehand, so will be unlikely to be able to deal with any issues,
make sure everything's ready, etc.
October 2nd - OK for me


The conclusion seems to be that if we want to have all of the Images
Team available then we're looking at:


October 9th - OK for me
October 16th - OK for me


Images Team, what was the conclusion in terms of timing for the two
point releases? Are you happy for the archive side for both to happen
on the same day, with image testing for buster possibly being delayed,
or would you prefer to try and separate the whole process? (In which
case we would need all teams available for multiple dates.)


I'm happy either way, I think Andy was less sure in the case that we
got him to do both? :-)



given that Steve will be around I am happy for both in one day :-)

/Andy

Re: 11.1 and 10.11 planning

[Andy Simpkins]

On 06/09/2021 12:58, Cyril Brulebois wrote:

Hi Adam,

Adam D. Barratt  (2021-09-06):

We've ended up being late with planning 10.11 due to the timing of the
bullseye release, and also need to look at getting 11.1 sorted.

Traditionally, we've combined stable and oldstable point releases (at
2- and 4-month cadences) while both are supported. That would still be
my preference, but I understand that not everyone on the Images side
is so keen on the idea. Open questions in addition to dates are
therefore whether we should do 10.11 and 11.1 on the same day and, if
not, how close together they should be.

A few suggested dates to get things going:

September 18th - not great; means freezing this coming weekend
September 25th - not great; I'm away during most of the week
beforehand, so will be unlikely to be able to deal with any issues,
make sure everything's ready, etc.
October 2nd - OK for me
October 9th - OK for me
October 16th - OK for me


Regarding d-i preps, I should be able to accomodate anything that gets
picked up.


Cheers,




I can do all of the above dates except the 2nd October (wedding anniversary)

Whilst it is normal to run a point release on old stable at the same 
time as stable it does mean that we don't give the images in the old 
stable point release as much testing as perhaps they should because we 
are all 'too tired' by the time that we get round to them.  that said 
that is what the Sunday is for...


/Andy

Re: Finding a tentative bullseye release date

[Andy Simpkins]

On 18/07/2021 00:24, Donald Norwood wrote:

Hi!

On 7/17/21 4:58 PM, Steve McIntyre wrote:

On Sat, Jul 17, 2021 at 10:25:17PM +0200, Paul Gevers wrote:

Hi all,

On 11-07-2021 21:11, Paul Gevers wrote:

With less than three weeks to go until the tentative release date, I
would love to confirm the date by now, but there is a serious issue with
crucial infrastructure (cdbuilder.d.o). Apart from this issue (and what
it means for solving the debian-installer blocking issues in time), I'm
not aware of other blocking issues, so let's hope the teams involved can
recover in time.

Albeit there is some progress, we think it better for the people
involved to now say that we will *not* release on July 31.

Unfortunately, that means that we have to start looking for a new date
again. Assuming what we'll learn in the upcoming week or two is good, I
propose to already start the list below with two weeks after the
previous date. Upcoming time is around DebConf, I can imagine it could
even be an advantage, especially as that's on-line, let's see.

14 August (day before DebCamp)

Doable.

Works for me

Works for me for images team


21 August (last day of DebCamp)
RT: elbrus

Awkward - wife has plans for us that evening.

Half of the press team is available this day so it is not ideal.

Sorry - away

28 August (DebConf)
RT: elbrus

Debian UK BBQ, argh

away at ^^



4 September
RT: elbrus

Labor day weekend in the U.S. Not a good weekend.

Works fine for me

doable - Isy and I will be unavailable before 1300hrs UTC

11 September:
RT: elbrus

That's the week of my wedding anniversary, I'll be on VAC.

Happy Anniversary!

Works for me


Could we put forth September 18th? We are good for that day without any
issues.

Works for me

Re: Finding a tentative bullseye release date

[Andy Simpkins]

On 08/06/2021 19:50, Paul Gevers wrote:

Hi all again,

On 07-06-2021 23:08, Adam D. Barratt wrote:

On Mon, 2021-06-07 at 20:38 +0200, Paul Gevers wrote:

Nevermind 10 July. Steve, you can stop contemplating about it. We'll
go for 24 July as the *tentative* release date.

Unfortunately I've just discovered that I was given the wrong date for
a family event, so I'm actually going to be AFK for most of the 24th.
:-(

Apologies for sticking a slight spanner in the works at this stage.

Those things happen. It's the price we pay for our bus factors (which we
should fix/are fixing).

So, if I did all the booking right (including updates from IRC) we now have:

26 June
   [Ansgar (ftp), Sebastian (release), Adam (release)]
3 July
   [Ansgar (ftp), Paul (release), Adam (release)]
10 July
   [Steve + Andy (CD), Paul (release), Adam (release), Graham (release)]
17 July
   [Steve (CD), press, Ansgar (ftp), Paul (release)]
24 July
   [Steve (CD), press, Ansgar (ftp), Sebastian (release),
Graham (release)]
31 July
   [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release)]
7 August
   [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release)]
14 August
   [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release)]

The first available date is 31 July, so let's shift all my dates another
week.
17 July: Hard Freeze & confirmation of the release date
31 July: ** tentative ** release date

Paul



Ack.  31st July in calendar

/Andy

Re: Finding a tentative bullseye release date

[Andy Simpkins]

On 07/06/2021 22:08, Adam D. Barratt wrote:

On Mon, 2021-06-07 at 20:38 +0200, Paul Gevers wrote:

Hi all,

On 06-06-2021 20:03, Paul Gevers wrote:

With the availability of Adam now known (and some off-list info),
we have:


[...]

So, what to pick? We still believe that shorter freezes are better
for
the Debian community as a whole, so Steve can you look at turning
your
maybe on 10 July into a "lets go for this"? If the answer is no,
than
lets pick 24 July as the *tentative* release date.

Nevermind 10 July. Steve, you can stop contemplating about it. We'll
go for 24 July as the *tentative* release date.

Unfortunately I've just discovered that I was given the wrong date for
a family event, so I'm actually going to be AFK for most of the 24th.
:-(

Apologies for sticking a slight spanner in the works at this stage.

Adam




Hi Guys

Just spotted this.

If we need to change away from the 24th July I am sorry but I shall no 
longer be available on the 10th (Isy has admissions planning visit for 
6th form collage)



Sorry if this breaks things (again)

/Andy

Re: Finding a tentative bullseye release date

[Andy Simpkins]

On 07/06/21 19:38, Paul Gevers wrote:
> Hi all,
> 
> On 06-06-2021 20:03, Paul Gevers wrote:
>> With the availability of Adam now known (and some off-list info), we have:
>>
>> 26 June
>>   [Ansgar (ftp), Sebastian (release), Adam (release)]
>> 3 July
>>   [Ansgar (ftp), Paul (release), Adam (release)]
>> 10 July
>>   [Steve (CD) MAYBE , Ansgar (ftp), Paul (release), Adam (release),
>>Graham (release)]
>> 17 July
>>   [Steve (CD), press, Ansgar (ftp), Paul (release)]
>> 24 July
>>   [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release),
>>Graham (release)]
>> 31 July
>>   [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release)]
>> 7 August
>>   [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release)]
>> 14 August
>>   [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release)]
>>
>> So, what to pick? We still believe that shorter freezes are better for
>> the Debian community as a whole, so Steve can you look at turning your
>> maybe on 10 July into a "lets go for this"? If the answer is no, than
>> lets pick 24 July as the *tentative* release date.
> 
> Nevermind 10 July. Steve, you can stop contemplating about it. We'll go
> for 24 July as the *tentative* release date.
> 
>> Regardless of which of the two we pick, I propose we decide two weeks
>> before if it's going to be final.
> 
> So, we'll decide around 10 July.
> 
>> And, relevant for every maintainer of non-key packages without passing
>> autopkgtests, the full freeze will start two weeks before the
>> *tentative* release. The means that, with traditionally the last week
>> being totally frozen, the last week that packages can migrate *all*
>> packages need manual unblocks by the release team.
> 
> And the Full Freeze will start on 10 July too.
> 
> Paul
> 

26 June sorry No.
I can do any of the other dates.
I am not able to complete the images (I don't have, nor feel ready for
access to, the signing key just yet) but can start the process and keep
things going with smoke testing if Steve would be available in the
evening...

/Andy



signature.asc
Description: OpenPGP digital signature

Re: 10.10 planning

[Andy Simpkins]

Isy and I can do 12th or 19th.   

We have a prior commitment on the 26th...  Sorry

/Andy (rattusrattus)

On 30 May 2021 17:41:54 BST, "Adam D. Barratt"  wrote:
>Hi,
>
>We're now a little overdue for 10.10, but it looks like we're ready in
>terms of shim etc. changes, so we should look at dates.
>
>Please could you indicate your availability for (and any preferences
>amongst) the following:
>
>Saturday June 12th
>Saturday June 19th
>Saturday June 26th
>
>The 12th is doable, but means we have to freeze next weekend; on that
>basis I have a personal preference for the 19th, although I realise
>that it's further out of cadence.
>
>Thanks,
>
>Adam

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

Re: 10.9 planning

[Andy Simpkins]

Preferance would be 27th
But can do the others if need be.

/Andy (& Isy)

On 15 March 2021 20:54:45 GMT, Laura Arjona Reina  wrote:
>Hi!
>
>El 15 de marzo de 2021 13:33:15 CET, "Adam D. Barratt"
> escribió:
>>Hi,
>>
>>It's that time again, when we should look at organising the next point
>>release.
>>
>>Please could you confirm your availability, and any preferences, for
>>the following:
>>
>>- March 27th
>>- April 3rd
>>- April 10th
>>
>
>All those dates work for publicity team.
>
>Kind regards,
>
>>I'd prefer to avoid April 10th if possible, for slightly selfish
>>reasons. :-)
>>
>>Regards,
>>
>>Adam
>>
>
>-- 
>Laura Arjona Reina
>https://wiki.debian.org/LauraArjona
>Sent with K-9 mail

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

Re: login and password for Debian Live DVD

[Andy Simpkins]

Hi Terry

That is strange,  the Live images should work just fine without needing 
to enter any password to login.


I have tested most of the images myself, they start with the desktop 
associated with the image that you chose and do not require that you 
enter a username or password.


Should you need to escalate to root privileges then sudo -i will be 
suficiant (again without needing to enter a password)


Which image did you download, and where did you download it from?


Best regards

RattusRatus

On 28/02/2021 16:41, Terry L. Ridder wrote:

Hello

I have downloaded the Debian Live DVD images
I have burnt them to DVD-RW and The boot fine.
I cannot use them because they want a login and password

I find nothing in the files or on Debian web site about logins and 
password.


So what are the logins and passwords?

Re: Please lets generate 100 GB images for DB-XL

[Andy Simpkins]

Or if you really need the binaries for each and every package in your chosen 
architecture you could run your own mirror.
Because lets face it if you need every package you are running multiple 
machines because many packages can not coexist with others...


On 5 February 2021 09:14:45 GMT, Alexey Eromenko  wrote:
>one single disc can fir entire Debian in it. Or one flash disk of 128
>gig
>capacity.
>-- 
>-Alexey Eromenko "Technologov"

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

Re: 10.8 planning

[Andy Simpkins]

I can do either, it's not like I can go anywhere either weekend :-)

Isy is available to help as well.

/Andy

On 16 January 2021 21:54:25 GMT, Cyril Brulebois  wrote:
>Adam D. Barratt  (2021-01-16):
>> Please could you confirm your availability, and any preferences, for
>> the following:
>> 
>> - January 30th (would mean we would have to freeze next weekend, so
>>   a bit tight)
>> - February 6th
>> 
>> My personal preference would be the 6th.
>
>Me too. But I can do both if needs be.
>
>
>Cheers,
>-- 
>Cyril Brulebois (k...@debian.org)
>D-I release manager -- Release team member -- Freelance Consultant

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

Bug#973683: some images blacklisted by Google Chrome safe browsing

[Andy Simpkins]

Of cause firefox claims that the browser is working as intended and this is 
correct behavior (relying on the Google safe browsing API)
Google on the other hand don't provide a working, reliable method to resolve 
their proprietary API database issues.  
Perhaps it is time to push for the feture to be removed from firefox or carry a 
local patch because I struggle to see how we are going to get a usable solution 
other than replacing mirrors with our own dedicated CDN.



On 3 November 2020 11:02:59 GMT, Thomas Schmitt  wrote:
>Hi,
>
>> For all they will know, Debian has been pwned :-/
>
>Yeah. I tried hard to keep my previous mail in a civilized tone towards
>the intellectual entities who decided to deduce the purity of Debian
>ISOs
>from .exe files on the same server.
>(Quotation marks in the air are a warning sign towards myself that i am
>about to start a rant.)
>
>The only mitigation i can imagine is to put warning signs on pages like
>  https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/
>which say something like:
>
>- The browser warnings are known to be bogus. They appear because
>Google
>  mistrusts especially our swedish mirrors.
>
>- Please fulfill the (standard) request not to download by a web
>browser.
>  See first paragraphs of https://www.debian.org/CD/http-ftp/ .
>
>- If you have to use a web browser, you might be able to avoid the
>classification as malware by using a mirror server from the lower three
>  quarters of
>https://www.debian.org/CD/http-ftp/
>
>
>Have a nice day :)
>
>Thomas

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

Re: Upcoming stable point release (10.7)

[Andy Simpkins]

Thanks.   
Will keep that weekend free

On 2 November 2020 21:07:27 GMT, "Adam D. Barratt"  
wrote:
>Hi,
>
>The next point release for "buster" (10.7) is scheduled for Saturday
>December 5th. Processing of new uploads into buster-proposed-updates
>will be frozen during the preceding weekend.
>
>Regards,
>
>Adam

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

Re: 10.7 planning

[Andy Simpkins]

Isy and I can do any of these dates.  
We'll keep the dates clear until you announce the point release.

Cheers

On 30 October 2020 19:10:20 GMT, "Adam D. Barratt"  
wrote:
>Hi,
>
>In an attempt to be slightly more efficient than usual at planning a
>point release... it's about a month since 10.6, so let's start looking
>at dates for 10.7.
>
>Please could you confirm your availability, and any preferences, for
>the following:
>
>- November 21st
>- November 28th
>- December 5th
>
>Thanks,
>
>Adam

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

Re: 10.6 planning

[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

[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

[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)

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

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

[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

[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

[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

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

[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

[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

[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

[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

[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

[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?

[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?

[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?

[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

[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