Re: Planning for 12.6/11.10

2024-05-28 Thread Adam D. Barratt
On Mon, 2024-05-27 at 13:07 +0100, Jonathan Wiltshire wrote:
> The final bullseye point release 11.10 (and therefore also 12.6 for
> versioning) should be soon after 10th June, when security team
> support
> will end.
> 
> Please indicate availability for:
> 
>   Saturday 15th June
>   Saturday 22nd June
>   Saturday 29th June

Any of these should work for me currently, but I would prefer either
the 22nd or 29th.

Regards,

Adam



Re: Planning for 12.6/11.10

2024-05-27 Thread Emyr Williams

I can do all bar the 22nd of June, plan to be home in Wales for that one.


Emyr

On 27/05/2024 13:07, Jonathan Wiltshire wrote:

Hi,

The final bullseye point release 11.10 (and therefore also 12.6 for
versioning) should be soon after 10th June, when security team support
will end.

Please indicate availability for:

   Saturday 15th June
   Saturday 22nd June
   Saturday 29th June

Thanks,





Re: Planning for 12.6/11.10

2024-05-27 Thread Cyril Brulebois
Steve McIntyre  (2024-05-27):
> On Mon, May 27, 2024 at 01:07:17PM +0100, Jonathan Wiltshire wrote:
> > Please indicate availability for:
> >
> >   Saturday 15th June
> >   Saturday 22nd June
> >   Saturday 29th June
> 
> Any of those are feasible for me.

Ditto.


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


signature.asc
Description: PGP signature


Re: Planning for 12.6/11.10

2024-05-27 Thread Andrew M.A. Cater
On Mon, May 27, 2024 at 01:07:17PM +0100, Jonathan Wiltshire wrote:
> Hi,
> 
> The final bullseye point release 11.10 (and therefore also 12.6 for
> versioning) should be soon after 10th June, when security team support
> will end.
> 
> Please indicate availability for:
> 
>   Saturday 15th June
>   Saturday 22nd June
>   Saturday 29th June
> 

I should be able to do any of these three at the moment.

Andy Cater
[amaca...@debian.org]

> Thanks,
> 
> -- 
> Jonathan Wiltshire  j...@debian.org
> Debian Developer http://people.debian.org/~jmw
> 
> 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
> ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
> 



Re: Planning for 12.6/11.10

2024-05-27 Thread Steve McIntyre
On Mon, May 27, 2024 at 01:07:17PM +0100, Jonathan Wiltshire wrote:
>Hi,
>
>The final bullseye point release 11.10 (and therefore also 12.6 for
>versioning) should be soon after 10th June, when security team support
>will end.
>
>Please indicate availability for:
>
>  Saturday 15th June
>  Saturday 22nd June
>  Saturday 29th June

Any of those are feasible for me.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Every time you use Tcl, God kills a kitten." -- Malcolm Ray



Re: Planning for 12.6/11.10

2024-05-27 Thread Luna Jernberg
15th and 22th June works for me
10th June collides with WWDC 2024 for me (Online or the Stockholm
event have not decided yet) and 29th June i am at the openSUSE
Conference 2024 in Nuremberg, Germany and helping out in person

Den mån 27 maj 2024 kl 13:07 skrev Jonathan Wiltshire :
>
> Hi,
>
> The final bullseye point release 11.10 (and therefore also 12.6 for
> versioning) should be soon after 10th June, when security team support
> will end.
>
> Please indicate availability for:
>
>   Saturday 15th June
>   Saturday 22nd June
>   Saturday 29th June
>
> Thanks,
>
> --
> Jonathan Wiltshire  j...@debian.org
> Debian Developer http://people.debian.org/~jmw
>
> 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
> ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
>



Planning for 12.6/11.10

2024-05-27 Thread Jonathan Wiltshire
Hi,

The final bullseye point release 11.10 (and therefore also 12.6 for
versioning) should be soon after 10th June, when security team support
will end.

Please indicate availability for:

  Saturday 15th June
  Saturday 22nd June
  Saturday 29th June

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1



Contacting Debian CD team

2024-05-24 Thread Andreas Tille
Hi,

I'd like to officially contact all our teams to learn about potential
issues that might affect your work.  I would love to learn how you
organise / share your workload.  If you do some regular meetings - be it
on IRC, video conference or whatever I'm interested in joining one of
your next meetings.

Like previous DPLs, I'm open to any inquiries or requests for
assistance. I personally prefer public discussion whenever possible, as
they can benefit a wider audience. You can find a list of contact
options at the bottom of my page on people.d.o[1].

I prefer being offline when I'm away from my keyboard, so I don't carry
a phone. In urgent situations, I can provide the number of my dumb
phone, though it may not always be within reach. Feel free to ping me
via email if I don't respond promptly to ensure I address your concerns.

Please let me know whether I can do something for you.  I'm fine joining
your IRC channel if needed but please invite me in case I should be
informed about some urgent discussion there since I normally do not lurk
on this channel.

I'd also like to inform you that I've registered a BoF for DebConf24 in
Busan with the following description:

  This BoF is an attempt to gather as much as possible teams inside
  Debian to exchange experiences, discuss workflows inside teams, share
  their ways to attract newcomers etc.

  Each participant team should prepare a short description of their work
  and what team roles (“openings”) they have for new contributors. Even
  for delegated teams (membership is less fluid), it would be good to
  present the team, explain what it takes to be a team member, and what
  steps people usually go to end up being invited to participate. Some
  other teams can easily absorb contributions from salsa MRs, and at some
  point people get commit access. Anyway, the point is that we work on the
  idea that the pathway to become a team member becomes more clear from an
  outsider point-of-view.

I'm sure not everybody will be able to travel this distance but it would
be great if you would at least consider joining that BoF remotely.  I'll
care for a somehow TimeZone aware scheduling - if needed we'll organise
two BoFs to match all time zones.  I'm also aware that we have pretty
different teams and it might make sense to do some infrastructure
related BoF with your team and other teams that are caring for Debian
infrastructure.

I have some specific questions to the Debian CD team.

  - Do you feel good when doing your work in Debian CD team?
  - Do you consider the workload of your team equally shared amongst its
members?
  - Do you have some strategy to gather new contributors for your team?
  - Can you give some individual estimation how many hours per week you
are working on your tasks in youre team?  Does this fit the amount of
time you can really afford for this task?
  - My very personal (not DPL related) hope is that we will see some
installer featuring Debian Pure Blends.  What chances do you see
to get this happen?
  - Can I do anything for you?


Kind regards and thanks a lot for your work
   Andreas.


[1] https://people.debian.org/~tille/

-- 
https://fam-tille.de


signature.asc
Description: PGP signature


Re: Re-planning for 12.6

2024-05-22 Thread Cyril Brulebois
Hi,

Jonathan Wiltshire  (2024-04-21):
> Too late now in any case. SRMs will regroup and decide whether we push
> for one in May or just wait for June anyway.

June is 10 days away. Do we have any kind of tentative schedule?


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


signature.asc
Description: PGP signature


Re: How to create a custom Debian ISO

2024-05-16 Thread Aditya Garg
Well it's indeed not as easy as I thought as far as Debian ISOs are concerned.

I'll try to be more precise. I am a maintainer for Ubuntu on Linux on T2 Macs 
project: https://t2linux.org/.

We work to modify ISOs of commonly used distros by adding a custom kernel with 
drivers for T2 Macs and provide to the users. There has been a demand for 
Debian for a long time and I wish to provide the ISOs for the same. I would 
prefer making the ISO as similar to the official Debian ISO and just replace 
the Debian kernel with the customised kernel.

I've already set up an apt repo which hosts the kernels over here: 
https://github.com/AdityaGarg8/t2-ubuntu-repo

I'll be thankful if I get the best possible option.

On 11 May 2024, at 8:33 PM, Thomas Schmitt  wrote:

Hi,

Aditya Garg wrote to debian-devel:
I wanted to create a custom ISO of Debian, with the following customisations:
1. I want to add a custom kernel that supports my Hardware.
2. I want to add my own Apt repo which hosts various software packages to
support my hardware.
I am not able to get any good documentation for the same. Please help.

Marvin Renich wrote:
The package live-build from the Debian Live project might help you do
what you want.

Indeed the live-build package seems to be in use outside Debian's own
ISO production. Mailing list is
 debian-l...@lists.debian.org
There exists a manual
 https://live-team.pages.debian.net/live-manual/html/live-manual/index.en.html

Installation ISOs are made by package debian-cd, of which i am not aware
that it would have have users outside the official ISO production.i
Mailing list is
 debian-cd@lists.debian.org
Your impression about lack of documentation is not wrong as far as this
project is concerned. :))


Nevertheless the production step of packing up the ISO from a prepared
file tree is documented together with methods to use a Debian installation
ISO as base for the preparation:
 https://wiki.debian.org/RepackBootableISO

Packages may probably be added at the appropriate place in the directory
tree under /pool. (Managing a Debian repo is not my turf. Sorry for
being vague here.)

Changing the content of a Debian ISO might need some follow-up work in
administrative files of the ISO.
When merging Debian ISOs, my script
 
https://dev.lovelyhq.com/libburnia/libisoburn/raw/branch/master/test/merge_debian_isos
manipulates:
 /README.txt
 /dists/*/Release
and merges the files listed in /dists/*/Release.
You would have to explore whether these files are affected by your
changes.


Have a nice day :)

Thomas



Ideas

2024-05-13 Thread Martin McCarthy

Good morning all, I hope you're doing well today.

I am writing to you today to discuss a few ideas, proposals and concerns 
that I have about my experience in the Debian community over the past 6 
months or so:




Script for Point Release ISO Testing Session



I have been a Debian fan for the longest time and I wanted to get 
involved in the project somehow, so I joined the point release ISO 
testing team last year and it was an amazing experience. I had a great 
time, I learned a lot and I met some great people. I did notice the 
testing procedures that were used were a little ad-hoc and manual in 
nature and I saw a potential opportunity to enhance the testing process. 
I had some ideas for improvements that I feel could benefit the project 
from an accountability standpoint, time to release standpoint and 
enhanced efficiency and efficacy of user testing. Here are my ideas:


-- Development of a custom script that would work very much in a 
wizard-like fashion that testers would run on their machines when 
conducting their tests. The script would gather pertinent information 
such as the time data related to the test, the specific ISO that was 
tested and by whom, the hardware that was tested on, who their tester 
manager was, etc, etc. The script would produce some kind of data or 
report that could be filed away with the point release artefacts or they 
could be published to increase trust from customers. I was considering 
Bash or Perl for that piece as there would be no problem running either 
script on Linux. I have a rough outline of the script that I personally 
developed for my last testing run but I could have the piece in a 
production ready state if you like the idea. If the script were to enter 
some kind of development, I would appreciate the assistance from former 
DPL sledge as he deals a lot with the ISO work.


-- Having formal testing criteria. When I arrived last year, there were 
no formal testing requirements given to me so I was slightly confused as 
to what to test honestly. One thing that bothers me a bit about the lack 
of formal testing criteria is that it lower our chances of catching bugs 
across the various architectures. Given the lack of testing criteria, we 
could potentially okay an ISO and then it breaks in the customer’s 
production environment that may cause issues. A couple of ideas that I 
had to enhance the testing effort are:


oCompose a formal testing document that can be issued to the testing 
team on the day of testing and can be signed off by the tester.


oIncluding the test run within the proposed script idea above. The 
script above was more about information gathering and stats about the 
test but I see no reason why the test criteria itself could not be 
included within the script after the entire info gathering is done.


-This will increase the integrity of the ISO testing process, enhance 
customer trust within the ISOs and allow the team a wider scope for 
catching bugs prior to release and shipping. I feel the more rigorous 
our testing is, the greater the trust we can gain from customers.


I would love to hear your take on those ideas and if you think they 
would benefit the project. I’m happy to discuss further and provide 
demos of the script or the document, just let me know if this is 
something that you think would benefit Debian.




Formal Recognition of Point Release ISO Testers



When I took part in the testing run last year, I noticed that there was 
no formal recognition of the testers. I know that might sound like a 
small thing but personally, I think it is an important thing. I and 
other volunteers in the testing team gave up our own time in support of 
the project that we love and the leaders present were very thankful for 
our contributions but I think some formal recognition would go a long 
way. A couple of ideas that I had surrounding this point:


-   - Congratulatory email from the DPL to the testers involved or 
at least to the tester distribution list.


-- Acknowledgement of testers in release notes.

-- Certificates of participation for the testers.

They may seem small but I think they would have a big impact on the 
testing team personally and given how small they are, I would say it 
would be beneficial to include something like that. The certificate 
could be generated quite easily and I am happy to provide templates for 
that. Of course, names and handles of testers will only be included in 
such acknowledgements only when they opt-in to them as to not cause any 
issues for individuals.




Point Release Testing Register



I am not sure if there is an official register but I had an idea of 
having a register just so Sledge and the team can plan the event a 
little ahead 

Re: Package "usr-is-merged" is reported as missing in Debian Live ISO 12.5 (debian-live-12.5.0-amd64-lxqt.iso) during installation with live-installer/enable=false

2024-05-03 Thread Computer Enthusiastic

Hello,

On 02/05/2024 08:07, Roland Clobus wrote:

Hello,

On 01/05/2024 23:43, Cyril Brulebois wrote:
Thanks Cyril for passing along the mail to the debian-live mailing list.


Computer Enthusiastic  (2024-05-01):

The "Normal" [0] Debian Installer included in Debian Live ISO 12.5
(debian-live-12.5.0-amd64-lxqt.iso) fails the installation of the base
system  when started with the following preseed parameters:

live-installer/enable=false firmware=never

The Debian installer stops deboostrap with the following error

Could not find these debs: usr-is-merged

The installation of the base system is not completed even if the
base-install step is repeated.


You have provided 2 kernel options, both of which are not regularly 
tested. Effectively, you are running a live image with the netinst 
installer settings. The debootstrap phase only uses the packages from 
the image, even though the network has already been detected.


I'll mark this on the todo page. For the short term, you can use the 
netinst image instead.


With kind regards,
Roland Clobus


Thank you.



Re: Package "usr-is-merged" is reported as missing in Debian Live ISO 12.5 (debian-live-12.5.0-amd64-lxqt.iso) during installation with live-installer/enable=false

2024-05-02 Thread Roland Clobus

Hello,

On 01/05/2024 23:43, Cyril Brulebois wrote:
Thanks Cyril for passing along the mail to the debian-live mailing list.


Computer Enthusiastic  (2024-05-01):

The "Normal" [0] Debian Installer included in Debian Live ISO 12.5
(debian-live-12.5.0-amd64-lxqt.iso) fails the installation of the base
system  when started with the following preseed parameters:

live-installer/enable=false firmware=never

The Debian installer stops deboostrap with the following error

Could not find these debs: usr-is-merged

The installation of the base system is not completed even if the
base-install step is repeated.


You have provided 2 kernel options, both of which are not regularly 
tested. Effectively, you are running a live image with the netinst 
installer settings. The debootstrap phase only uses the packages from 
the image, even though the network has already been detected.


I'll mark this on the todo page. For the short term, you can use the 
netinst image instead.


With kind regards,
Roland Clobus


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: Package "usr-is-merged" is reported as missing in Debian Live ISO 12.5 (debian-live-12.5.0-amd64-lxqt.iso) during installation with live-installer/enable=false

2024-05-01 Thread Cyril Brulebois
Hello,

And thanks for the report.

Cc += debian-live@

Computer Enthusiastic  (2024-05-01):
> The "Normal" [0] Debian Installer included in Debian Live ISO 12.5
> (debian-live-12.5.0-amd64-lxqt.iso) fails the installation of the base
> system  when started with the following preseed parameters:
> 
>   live-installer/enable=false firmware=never
> 
> The Debian installer stops deboostrap with the following error
> 
>   Could not find these debs: usr-is-merged
> 
> The installation of the base system is not completed even if the
> base-install step is repeated.
> 
> The syslog contains:
> 
> [..]
> May  1 17:17:12 main-menu[440]: INFO: Menu item 'bootstrap-base' selected
> May  1 17:17:13 debootstrap: /usr/sbin/debootstrap --components=main
> --debian-installer --resolve-deps --no-check-gpg bookworm /target
> file:///cdrom/
> May  1 17:18:26 base-installer: error: exiting on error
> base-installer/debootstrap-failed
> May  1 17:19:22 main-menu[440]: WARNING **: Configuring 'bootstrap-base'
> failed with error code 1
> May  1 17:19:22 main-menu[440]: WARNING **: Menu item 'bootstrap-base'
> failed.
> [..]
> 
> The package "usr-is-merged"
> (https://packages.debian.org/bookworm/usr-is-merged) is missing in
> /cdrom/pool/main/u :
> 
> ls -l /cdrom/pool/main/u/
> dr-xr-xr-x1 root root  2048 Feb 10 11:07 ucf
> dr-xr-xr-x1 root root  2048 Feb 10 11:07 usrmerge
> 
> Which package should I report to the bug tracking system ?
> 
> Let me know if I can help.
> 
> Thanks.
> 
> --
> [0] 
> https://live-team.pages.debian.net/live-manual/html/live-manual/customizing-installer.en.html
> 

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


signature.asc
Description: PGP signature


Package "usr-is-merged" is reported as missing in Debian Live ISO 12.5 (debian-live-12.5.0-amd64-lxqt.iso) during installation with live-installer/enable=false

2024-05-01 Thread Computer Enthusiastic

Hello,

The "Normal" [0] Debian Installer included in Debian Live ISO 12.5 
(debian-live-12.5.0-amd64-lxqt.iso) fails the installation of the base 
system  when started with the following preseed parameters:


live-installer/enable=false firmware=never

The Debian installer stops deboostrap with the following error

Could not find these debs: usr-is-merged

The installation of the base system is not completed even if the 
base-install step is repeated.


The syslog contains:

[..]
May  1 17:17:12 main-menu[440]: INFO: Menu item 'bootstrap-base' selected
May  1 17:17:13 debootstrap: /usr/sbin/debootstrap --components=main 
--debian-installer --resolve-deps --no-check-gpg bookworm /target 
file:///cdrom/
May  1 17:18:26 base-installer: error: exiting on error 
base-installer/debootstrap-failed
May  1 17:19:22 main-menu[440]: WARNING **: Configuring 'bootstrap-base' 
failed with error code 1
May  1 17:19:22 main-menu[440]: WARNING **: Menu item 'bootstrap-base' 
failed.

[..]

The package "usr-is-merged" 
(https://packages.debian.org/bookworm/usr-is-merged) is missing in 
/cdrom/pool/main/u :


ls -l /cdrom/pool/main/u/
dr-xr-xr-x1 root root  2048 Feb 10 11:07 ucf
dr-xr-xr-x1 root root  2048 Feb 10 11:07 usrmerge

Which package should I report to the bug tracking system ?

Let me know if I can help.

Thanks.

--
[0] 
https://live-team.pages.debian.net/live-manual/html/live-manual/customizing-installer.en.html




Debian DVD Installer bug/issue that has arisen with Bookworm

2024-05-01 Thread Reid
I'm a 10+ year Debian user and Free Software supporter.
The release notes for Bookworm are currently telling users 
that they can use "firmware=never" to continue installing Debian 
without non-free-firmware, as was possible with Bullseye and earlier
releases. And when installing from non-live DVD images, those 
"firmware=never" instructions do successfully block 
non-free-firmware. 

However, that method also blocks the usual FREE firmware 
that would have been installed with Bullseye and previous releases. 
Therefore, when using this method on Bookworm, my Wifi adapter 
didn't work after installation, whereas it always worked after 
installing Bullseye and earlier releases. 

This has essentially made Bookworm much less friendly for 
Free Software supporters than Bullseye and earlier releases.

Suggestions: 

1) Best: 
The best solution IMO would be to add a step to all CD/DVD 
installers to opt-in or opt-out of non-free-firmware. 

2) Second best: 
There could be something like a "nonfreefirmware=never" 
option added. However, that method alone would be less user 
friendly than having something integrated into the 
graphical installer. 

3) Third best/bad: 
Re-word the Debian.org web pages that promote Debian as 
Free Software ("Why Debian", "Our Philosophy", and "Who We Are") 
so as to not mislead users about what they're getting with certain 
installers. I'd be disappointed with this option, but at 
least it would inform rather than mislead users about 
what they'll get with certain installers. 

Worst option: 
The worst option IMO would be to not make any change, as the 
way things currently are is very misleading as to what's being 
installed. These "bugs" (issues that have arisen with Bookworm) 
really either need to be fixed (#1 or #2), or the truth about what 
certain installers are doing needs to be disclosed on those Debian 
promo pages and download pages (suggestion #3).

Debian 12.5



4/29 weekly ISO

2024-04-30 Thread Rick Stanley
Hello!

I downloaded the weekly Trixie/Testing Netinstall & DVD1 iso's, but
both failed multiple times.  It didn't matter if I downloaded with
Firefox, or by curl.  All attempts failed installing the Base packages.
It hung, and would not recover.

Please regenerate before next week.

Thank you!

Rick Stanley

-- 
Rick Stanley
(917) 822-7771
www.rsiny.com
IT  Consulting
Linux & Open Source Specialist



Bug#1070067: debian-cd: daily arm64 netinst image: GRUB menu is complex

2024-04-29 Thread Roland Clobus

Package: debian-cd
Version: 3.2.1
Severity: minor
User: debian...@lists.debian.org
Usertags: openqa

Hello maintainers of the arm64 netinst image,

The issue:
Recently I've updated the openQA boot walk test [1] to match the actual 
GRUB boot menu for the arm64 netinst image (taken from the daily builds 
[2]). It has a very complex structure (up to 5 levels deep) and offers 
many similar options in the sub menus.

Is this intentional?

Expected:
The GRUB menu for arm64 is identical to or only slightly different from 
the amd64 netinst image.


With kind regards,
Roland Clobus

[1] https://openqa.debian.net/tests/255725


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1070006: debian-cd: daily arm64 netinst image: GRUB not started in graphical mode

2024-04-28 Thread Roland Clobus

Package: debian-cd
Version: 3.2.1
Severity: minor
User: debian...@lists.debian.org
Usertags: openqa

Hello maintainers of the netinst image,

The issue:
As seen on openQA [1], the GRUB menu for the arm64 netinst image (taken 
from the daily builds [2]) does not use the graphical mode, but text 
mode instead.


Some sub-menus assume that the graphical mode is active, but issue an 
error message: 'error: no video mode activated.' (e.g. 'Accessible dark 
contrast installer menu...')


Expected:
GRUB uses the graphical version of the boot menu.


During the miniDebCamp 2024 in Hamburg, ema showed that (at least for 
the live-build images) GRUB is able to use the graphical mode correctly.
As a side note, the graphical installer also shows properly, so there 
appears to be no problem in using the graphical mode.


With kind regards,
Roland Clobus

---
[1] https://openqa.debian.net/tests/25
[2] 
https://get.debian.org/images/daily-builds/daily/arch-latest/arm64/iso-cd/debian-testing-arm64-netinst.iso


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1069682: debian-cd DVD source run failing

2024-04-22 Thread Steve McIntyre
Package: cdimage.debian.org

As a reminder for me: the latest weekly build failed, looks like
source packages no longer fit???

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"C++ ate my sanity" -- Jon Rabone



Re: Re-planning for 12.6

2024-04-21 Thread Jonathan Wiltshire
On Sun, Apr 21, 2024 at 05:44:48PM +0100, Andy Simpkins wrote:
> 
> 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

Too late now in any case. SRMs will regroup and decide whether we push for
one in May or just wait for June anyway.


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1



Re: Re-planning for 12.6

2024-04-21 Thread 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

2024-04-21 Thread Emyr Williams

I'm free, happy to travel to Cambridge or do it from home.

Emyr

On 21/04/2024 07:43, Luna Jernberg wrote:

as i indicated on IRC 27th April works for me
May does not really work for me however

Den sön 21 apr. 2024 kl 02:58 skrev Steve McIntyre :

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.

--
Steve McIntyre, Cambridge, UK.st...@einval.com
“Changing random stuff until your program works is bad coding
  practice, but if you do it fast enough it’s Machine Learning.”
-- https://twitter.com/manisha72617183





Re: Re-planning for 12.6

2024-04-21 Thread Luna Jernberg
as i indicated on IRC 27th April works for me
May does not really work for me however

Den sön 21 apr. 2024 kl 02:58 skrev Steve McIntyre :
>
> 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.
>
> --
> Steve McIntyre, Cambridge, UK.st...@einval.com
> “Changing random stuff until your program works is bad coding
>  practice, but if you do it fast enough it’s Machine Learning.”
>-- https://twitter.com/manisha72617183
>



Re: Re-planning for 12.6

2024-04-20 Thread Andrew M.A. Cater
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.
> 

Works for me: it's possible I won't get across to Cambridge but help with image 
release here 

Andy

amaca...@debian.org
> 
> -- 
> Jonathan Wiltshire  j...@debian.org
> Debian Developer http://people.debian.org/~jmw
> 
> 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
> ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
> 



Re: Re-planning for 12.6

2024-04-20 Thread Steve McIntyre
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.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
“Changing random stuff until your program works is bad coding
 practice, but if you do it fast enough it’s Machine Learning.”
   -- https://twitter.com/manisha72617183



Re: Re-planning for 12.6

2024-04-20 Thread Jonathan Wiltshire
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.


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1



Re: Re-planning for 12.6

2024-04-18 Thread Steve McIntyre
Hiya!

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

On Tue, Apr 02, 2024 at 10:53:49PM +0100, Steve McIntyre wrote:
>On Mon, Apr 01, 2024 at 01:07:27PM +0100, Adam 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
>
>Works for me.
>
>>April 20th
>>- Doesn't work for me; I'm away from the Tuesday before until late on
>>the Friday
>
>Works for me.
>
>>April 27th
>>- Doesn't work for me; I have a pre-existing appointment which means
>>I'll be AFK much of the day
>
>Works for me.
>
>>May 4th
>>- Apparently doesn't work for me; long weekend in the UK
>>
>
>Works for me.
>
>>May 11th
>>- Should work for me
>
>Nope, already booked for that Saturday.
>
>-- 
>Steve McIntyre, Cambridge, UK.st...@einval.com
>"...In the UNIX world, people tend to interpret `non-technical user'
> as meaning someone who's only ever written one device driver." -- Daniel Pead
-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
The two hard things in computing:
 * naming things
 * cache invalidation
 * off-by-one errors  -- Stig Sandbeck Mathisen



Re: Progress on t64 transition -> building the installer in sid

2024-04-15 Thread Philip Hands
Cyril Brulebois  writes:

> Philip Hands  (2024-04-15):
>> On the other hand, it's taken over a month so far. Rather than living in
>> hope for another month, I thought it might be worth removing this as a
>> blocker (I've had to tell a couple of people that they'll need to wait
>> before they can do their salsa-CI tests :-/ )
>
> I'm not suggesting living in hope, I'm suggesting to get the ball rolling.
>
> The commit lists #1066070, which was a duplicate (because -ECOFFEE) of
> #1066069, which got fixed rather quickly. So what we would need are
> rebuilds of the reverse dependencies (which I haven't checked right now
> would be sufficient to get them fixed), which one could request on the
> release team side.

Oh, I seem to have managed to overlook the bit with you closing it.
Sorry about that. Anyway, that's encouraging.

If I can work out what needs prodding, and where to prod, I'll give it a
go.

> Regarding #1066071, that needs a fix in the package first. Looking at
> tracker, it's not migrating any time soon as far as I can see (due to
> regressions on 32-bit arms), and I'm not sure how fixing the udeb would
> interfere there. So one could start with an upload.

I had looked at fixing that, but didn't immediately know in which
direction the mismatch should be resolved which convinced me that I
probably don't know enough about the background to be doing NMUs.

Which is what lead me to try working around it instead.

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature


Re: Progress on t64 transition -> building the installer in sid

2024-04-15 Thread Cyril Brulebois
Philip Hands  (2024-04-15):
> On the other hand, it's taken over a month so far. Rather than living in
> hope for another month, I thought it might be worth removing this as a
> blocker (I've had to tell a couple of people that they'll need to wait
> before they can do their salsa-CI tests :-/ )

I'm not suggesting living in hope, I'm suggesting to get the ball rolling.

The commit lists #1066070, which was a duplicate (because -ECOFFEE) of
#1066069, which got fixed rather quickly. So what we would need are
rebuilds of the reverse dependencies (which I haven't checked right now
would be sufficient to get them fixed), which one could request on the
release team side.

Regarding #1066071, that needs a fix in the package first. Looking at
tracker, it's not migrating any time soon as far as I can see (due to
regressions on 32-bit arms), and I'm not sure how fixing the udeb would
interfere there. So one could start with an upload.


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


signature.asc
Description: PGP signature


Re: Progress on t64 transition -> building the installer in sid

2024-04-15 Thread Philip Hands
Cyril Brulebois  writes:

> Philip Hands  (2024-04-14):
>> I realised that there might be a way to kludge around the current D-I
>> build failures, so I gave it a try and it seems to work:
>> 
>>   
>> https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/45
>> 
>> That creates dummy udebs with the missing names, where each depends upon
>> the matching udeb that actually exists. Dropping them into localudebs.
>> 
>> That's enough to get D-I to build in salsa pipelines, such that one gets
>> a mini-ISO to test.
>> 
>> It may be enough to get D-I and debian-cd back to the point where we can
>> produce daily images etc. but I'm not completely sure about that bit
>> (perhaps the use of localudebs is enough to make debian-cd grumpy?)
>> 
>> Anyway, it's currently broken anyway, so perhaps it's worth giving it a
>> go, and then reverting the commit once the proper fixes become
>> available.
>> 
>> What do you think?
>
> I'd rather see actual progress in getting packages fixed. So far I haven't
> been chasing because I thought people would be busy rebuilding the world, in
> the right order, and patching things along, but I had hoped to get *some*
> kind of feedback after filing those bug reports and putting people driving
> changes in the loop.

I too had rather hoped that it would already have been fixed by now.

On the other hand, it's taken over a month so far. Rather than living in
hope for another month, I thought it might be worth removing this as a
blocker (I've had to tell a couple of people that they'll need to wait
before they can do their salsa-CI tests :-/ )

I can just tell branch2repo to use the 'philh' D-I repo in the mean
time, and that'll fix the salsa-CI side of things, but that doesn't help
debian-cd or people's ability to build D-I locally.

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature


Re: Progress on t64 transition -> building the installer in sid

2024-04-14 Thread Cyril Brulebois
Philip Hands  (2024-04-14):
> I realised that there might be a way to kludge around the current D-I
> build failures, so I gave it a try and it seems to work:
> 
>   https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/45
> 
> That creates dummy udebs with the missing names, where each depends upon
> the matching udeb that actually exists. Dropping them into localudebs.
> 
> That's enough to get D-I to build in salsa pipelines, such that one gets
> a mini-ISO to test.
> 
> It may be enough to get D-I and debian-cd back to the point where we can
> produce daily images etc. but I'm not completely sure about that bit
> (perhaps the use of localudebs is enough to make debian-cd grumpy?)
> 
> Anyway, it's currently broken anyway, so perhaps it's worth giving it a
> go, and then reverting the commit once the proper fixes become
> available.
> 
> What do you think?

I'd rather see actual progress in getting packages fixed. So far I haven't
been chasing because I thought people would be busy rebuilding the world, in
the right order, and patching things along, but I had hoped to get *some*
kind of feedback after filing those bug reports and putting people driving
changes in the loop.


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


signature.asc
Description: PGP signature


Re: Progress on t64 transition -> building the installer in sid

2024-04-14 Thread Philip Hands
Hi,

I realised that there might be a way to kludge around the current D-I
build failures, so I gave it a try and it seems to work:

  https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/45

That creates dummy udebs with the missing names, where each depends upon
the matching udeb that actually exists. Dropping them into localudebs.

That's enough to get D-I to build in salsa pipelines, such that one gets
a mini-ISO to test.

It may be enough to get D-I and debian-cd back to the point where we can
produce daily images etc. but I'm not completely sure about that bit
(perhaps the use of localudebs is enough to make debian-cd grumpy?)

Anyway, it's currently broken anyway, so perhaps it's worth giving it a
go, and then reverting the commit once the proper fixes become
available.

What do you think?

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature


ISO images with malicious code

2024-04-08 Thread zyli

Hello and welcome.
https://cdimage.debian.org/cdimage/weekly-builds/amd64/
As you can see, as of 2024-03-07 it is not possible to build the current 
amd64 (weekly-builds) Debian testing image.
However, the available ISO image (according to: 
https://cdimage.debian.org/cdimage/weekly-builds/amd64/list-dvd/debian-testing-amd64-DVD-1.list.gz) 
contains the files:

xz-utils_5.6.0-0.2_amd64.deb
liblzma5_5.6.0-0.2_amd64.deb
liblzma5-udeb_5.6.0-0.2_amd64.udeb
liblzma-dev_5.6.0-0.2_amd64.deb
These files are vulnerable and inject malicious code at compile time 
(CVE-2024-3094).


Therefore, shouldn't these images be removed?

P.S.
I know there is a 'Valid-Until:' in '/dists/trixie/Release' in the ISO 
image, but changing this is no problem.




Re: Re-planning for 12.6

2024-04-04 Thread Luna Jernberg
13th April = does not work for me, going to my brother in Borås to
later go to foss-north 2024 in Gothenburg
20th and 27th April works for me
4th of May does not work for me will be at Curl-up Curl developer
conference here in Stockholm
11th of May might maybe work for me, but might also want to watch the
stream if X worlds biggest Commodore 64 demoparty or Outline Atari
demoparty in the Netherlands have a stream this year (not sure if they
are streaming or not yet)

Den mån 1 apr. 2024 kl 14:07 skrev Adam D. Barratt :
>
> 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
>



Re: Re-planning for 12.6

2024-04-03 Thread Andrew M.A. Cater
On Mon, Apr 01, 2024 at 01:07:27PM +0100, Adam D. Barratt wrote:
> Hi,
> 
> As we had to postpone 12.6, let's look at alternative dates.
> 

Can do all, I think,

Andy
(amaca...@debian.org)
> 
> Adam
> 



Re: Re-planning for 12.6

2024-04-02 Thread Mike Hosken
Just one thing could you please pull all world wide repos so the repos that are 
new are there and defunct repositories don’t appear. My repositories have been 
registered repositories for years and newer been in one release 
Mike Hosken 
Sent via my iPhone 

> On 3 Apr 2024, at 08:40, Jonathan Wiltshire  wrote:
> 
> On Mon, Apr 01, 2024 at 01:07:27PM +0100, Adam D. Barratt wrote:
>> April 13th
>> April 20th
>> April 27th
> 
> At current progress I expect to be available for the SRM side 13th or 27th.
> We're in a good position to freeze this weekend to make the 13th, if others
> are available then.
> 
> The 20th is a no for me.
> 
>> May 4th
>> May 11th
> 
> Currently OK for me.
> 
> Though as soon as we're heading into the middle of May we might as well
> wait for the next cadence in June.
> 
> --
> Jonathan Wiltshire  j...@debian.org
> Debian Developer http://people.debian.org/~jmw
> 
> 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
> ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
> 



Re: Re-planning for 12.6

2024-04-02 Thread Steve McIntyre
On Mon, Apr 01, 2024 at 01:07:27PM +0100, Adam 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

Works for me.

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

Works for me.

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

Works for me.

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

Works for me.

>May 11th
>- Should work for me

Nope, already booked for that Saturday.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"...In the UNIX world, people tend to interpret `non-technical user'
 as meaning someone who's only ever written one device driver." -- Daniel Pead



Re: Re-planning for 12.6

2024-04-02 Thread Jonathan Wiltshire
On Mon, Apr 01, 2024 at 01:07:27PM +0100, Adam D. Barratt wrote:
> April 13th
> April 20th
> April 27th

At current progress I expect to be available for the SRM side 13th or 27th.
We're in a good position to freeze this weekend to make the 13th, if others
are available then.

The 20th is a no for me.

> May 4th
> May 11th

Currently OK for me.

Though as soon as we're heading into the middle of May we might as well
wait for the next cadence in June. 

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1



Re: Re-planning for 12.6

2024-04-02 Thread Mark Hymers
Hi,

On Mon, 01, Apr, 2024 at 01:07:27PM +0100, Adam D. Barratt spoke thus..
> April 13th
> - Not great for me for personal reasons, mhy previously said no. I
> could probably do if need be

13th is completely out for me.

> May 11th
> - Should work for me

Looks like it'll work at present.

Thanks,

Mark

-- 
Mark Hymers 


signature.asc
Description: PGP signature


Re: Re-planning for 12.6

2024-04-01 Thread Cyril Brulebois
Hi,

Adam D. Barratt  (2024-04-01):
> As we had to postpone 12.6, let's look at alternative dates.

I should be able to make anything work.
 

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


signature.asc
Description: PGP signature


Re: Re-planning for 12.6

2024-04-01 Thread 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-planning for 12.6

2024-04-01 Thread Adam D. Barratt
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



Re: Upcoming stable point release (12.6)

2024-03-31 Thread 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: Upcoming stable point release (12.6)

2024-03-29 Thread Steve McIntyre
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

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Google-bait:   https://www.debian.org/CD/free-linux-cd
  Debian does NOT ship free CDs. Please do NOT contact the mailing
  lists asking us to send them to you.



Re: Upcoming stable point release (12.6)

2024-03-29 Thread Adam D. Barratt
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.

Regards,

Adam



Re: Where to download cd iso?

2024-03-27 Thread Steve McIntyre
On Wed, Mar 27, 2024 at 02:24:10PM +0100, Thomas Schmitt wrote:
>Hi,
>
>Tatsu Takamaro wrote:
>> I've received my own message to you. But I don't see your answer...
>
>Well, i have't seen that message and the mailing list archive doesn't
>show it either:
>  https://lists.debian.org/debian-cd/2024/03/threads.html
>(The one i reply to is your follow-up:
>  https://lists.debian.org/debian-cd/2024/03/msg00022.html

I didn't see it either.

>> > I don't see the cd iso on the iso-cd page.
>> > I mean a usual one, not a netinst.
>
>I guess they have been discontinued because of the insane number of ISO
>images with 650 MB which would emerge. (I estimate ~ 130 pieces.)

Exactly. Single CDs are just too small to be useful for most things
now. We only just manage to fit the "netinst" into a single CD these
days.

>The smallest granularity seems to be the ~4.5 GB sized DVD images which
>are available via Jigdo download:
>  https://cdimage.debian.org/debian-cd/current/amd64/jigdo-dvd/
>21 pieces.

Yup.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
 whether they're being malicious or incompetent. Capital letters are forecast."
 Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html



Re: Where to download cd iso?

2024-03-27 Thread Thomas Schmitt
Hi,

Tatsu Takamaro wrote:
> I've received my own message to you. But I don't see your answer...

Well, i have't seen that message and the mailing list archive doesn't
show it either:
  https://lists.debian.org/debian-cd/2024/03/threads.html
(The one i reply to is your follow-up:
  https://lists.debian.org/debian-cd/2024/03/msg00022.html
)


> > I don't see the cd iso on the iso-cd page.
> > I mean a usual one, not a netinst.

I guess they have been discontinued because of the insane number of ISO
images with 650 MB which would emerge. (I estimate ~ 130 pieces.)

The smallest granularity seems to be the ~4.5 GB sized DVD images which
are available via Jigdo download:
  https://cdimage.debian.org/debian-cd/current/amd64/jigdo-dvd/
21 pieces.


Have a nice day :)

Thomas



Re: Where to download cd iso?

2024-03-27 Thread Tatsu Takamaro

I've received my own message to you. But I don't see your answer...



вт, 26.03.2024 20:25, Tatsu Takamaro пишет:

I don't see the cd iso on the iso-cd page.
I mean a usual one, not a netinst.


Bug#1067649: Verification page is not accessible from the homepage

2024-03-24 Thread Tassia Camoes Araujo
Package: www.debian.org
Severity: important
X-Debbugs-CC: debian-cd@lists.debian.org

Dear www and CD teams,

When the Download link in our homepage was changed to start the iso
download right away, the old download page [1] became inaccessible (at
least not easily-accessible), making it very hard to find the
verification page [2]. I could only find it clicking on "other
downloads", then "Download mirrors", and scrolling up until the top of
the page, where a menu appears on the right, containing the link to the
verify page (I guess many of our users would totally miss it!).

My suggestion would be to replace the line "other downloads" with 2
separate links side-by-side: 

"verify authenticity" | "check all download options"

And incorporate the content of the old download page into those 2
targets, the verify and "Getting Debian" page [3] (current target of
other downloads).

[1] https://www.debian.org/download
[2] https://www.debian.org/CD/verify
[3] https://www.debian.org/distrib/

Cheers,

Tassia.



Re: Bug#902668: Draft for rewrite of https://www.debian.org/CD/verify

2024-03-24 Thread Cyril Brulebois
Hi,

Tassia Camoes Araujo  (2024-03-25):
> I've reviewed the proposed patch, and I think it should be applied as
> soon as possible.
> 
> It seems Laura was waiting for a final review before applying this patch
> (long overdue!), which IMHO would bring much more clarity to the image
> verification process (usually, a big struggle to new users).
> 
> We should make a decision about the long key IDs request (points 1 and 2
> from #851541), and once those changes go online, I think both bugs could
> be closed (#902668 and #851541).
> 
> Thanks for all who have invested energy to clarify this process, and I
> hope we can benefit from your work very soon!
> 
> Cheers,
> 
> Tassia. 

Cc += debian-cd@ for information.


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


signature.asc
Description: PGP signature


Re: problems with amd64 testing images

2024-03-24 Thread Cyril Brulebois
Hi,

Jogi Hofmüller  (2024-03-24):
> I just failed to install debian testing using the latest
> debian-testing-amd64-netinst.iso. for amd64 this has two problems:
> 
> 1) it misses at least libaio.so so pvcreate does not run and I cannot set up
> the disk as planned
> 2) it is more than 2 weeks old (2024-03-09) and there are no newer images
> for amd64

Some pointers:
 - https://lists.debian.org/debian-devel-announce/2024/02/msg5.html
 - https://lists.debian.org/debian-cd/2024/03/msg00013.html

> Please CC when replying since I am not on the list

Done.


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


signature.asc
Description: PGP signature


problems with amd64 testing images

2024-03-24 Thread Jogi Hofmüller

Dear all,

I just failed to install debian testing using the latest 
debian-testing-amd64-netinst.iso. for amd64 this has two problems:


1) it misses at least libaio.so so pvcreate does not run and I cannot 
set up the disk as planned
2) it is more than 2 weeks old (2024-03-09) and there are no newer 
images for amd64


Please CC when replying since I am not on the list
--
j.hofmüller

   Optimism doesn't alter the laws of physics.
   - Subcommander T'Pol



回复: Request for keeping generating non-installable i386 DVDs/BDs

2024-03-23 Thread defrag ment
Keeping only .jigdo files for i386 DVDs/BDs is enough, and a real DVD-1 or a 
BD-1 iso is not needed to be stored on the server.

Then someone can sell or distribute a set of 'official' amd64 DVDs/BDs with 
companion non-installable i386 DVDs/BDs which can be used without Internet.


发件人: acmilan defrag 
发送时间: 2024年3月22日 12:27
收件人: debian-cd@lists.debian.org 
主题: Request for keeping generating non-installable i386 DVDs/BDs

Dropping i386 DVDs/BDs is making amd64 DVDs/BDs not complete, because offline 
users cannot use multiarch any more, especially wine - amd64 DVDs/BDs only 
contains wine64, not wine32. There are also some legacy i386 softwares not 
upgraded to amd64 in the i386 DVDs/BDs.

Offline users are not so common in common cases in developed countries 
nowadays, but still common in some developing countries and some uncommon cases 
in developed countries. Forcing these offline users connecting to the Internet 
is not friendly, and keeping these DVDs/BDs is not a waste of disk space, but 
instead keep Debian being offline user-friendly.

I think Debian should keep generating a set of non-installable i386 DVDs/BDs in 
trixie at most for offline users. i386 netinst CDs are purely for installation, 
and because i386 is not installable now in trixie, and thus can be removed.

Trixie is planned to be released in 2025, and its LLTS is upto 2035, so its 
safe to release i386 DVDs/BDs in trixie. In forky which are planned to be 
released in 2027, wine should be pure 64-bit without any compatiblity or 
performance problems, and maybe it would be time to drop i386 totally in Debian.


Re: lvm2 udebs vs. libaio1-udeb (was: Progress on t64 transition -> building the installer in sid)

2024-03-22 Thread Guillem Jover
Hi!

On Thu, 2024-03-21 at 23:13:31 +0100, Cyril Brulebois wrote:
> Cyril Brulebois  (2024-03-21):
> > I'm a bit conflicted about what to do here. At the moment, libaio1-udeb
> > is the only udeb with t64 (at least according to the output of
> > `apt-file search -Iudeb t64`); but a rebuild of the reverse dependencies
> > would be sufficient (and might happen at some point anyway).
> > 
> > For the sake of consistency, I think I'm tempted to suggest a revert of
> > the udeb part (it wasn't renamed so there's a contents vs. package name
> > mismatch anyway).
> 
> Checking libaio's changelog (last mail got sent a little too fast,
> sorry) is enlightening: this library required special attention and
> wasn't just about getting rebuilt with a different package name.
> 
>   
> https://tracker.debian.org/news/1509816/accepted-libaio-03113-6-source-into-unstable/
> 
> Guillem is absolutely right regarding avoiding the roundtrip to NEW and
> d-i's not caring, but some kind of heads-up to debian-boot@ (now cc'd)
> would have been welcome.

Ah, sorry, the heads-up part didn't cross my mind, as I guess I
assumed transitory breakage was expected as part of that transition,
and that it would auto-heal after the release-team would trigger the
necessary binNMUs. Will try to have that in mind in the future. (I'll
do so as well once/if I revert the libaio SONAME bump, even though there
I'd be planning to add backwards compatibility symlinks if the ABI does
not change from what upstream accepts.)

Thanks,
Guillem



Request for keeping generating non-installable i386 DVDs/BDs

2024-03-22 Thread acmilan defrag
Dropping i386 DVDs/BDs is making amd64 DVDs/BDs not complete, because offline 
users cannot use multiarch any more, especially wine - amd64 DVDs/BDs only 
contains wine64, not wine32. There are also some legacy i386 softwares not 
upgraded to amd64 in the i386 DVDs/BDs.

Offline users is not so common in common cases in developed contries nowadays, 
but still common in some developing contries and some uncommon cases in 
developed contries. Forcing these offline users connecting to the Internet is 
not friendly, and keeping these DVDs/BDs is not a waste of disk space, but 
instead keep Debian being offline user-friendly.

I think Debian should keep generating a set of non-installable i386 DVDs/BDs in 
trixie at most for offline users. i386 netinst CDs are purely for installation, 
and because i386 is not installable now in trixie, and thus can be removed.

Trixie is planned to be released in 2025, and its LLTS is upto 2035, so its 
safe to release i386 DVDs/BDs in trixie. In forky which are planned to be 
released in 2027, wine should be pure 64-bit without any compatiblity or 
performance problems, and maybe it would be time to drop i386 totally in Debian.


New `debian-cd` mirror application

2024-03-21 Thread Tran Trong Nghia FX05823
Hi, I'd like to apply for a new Debian CD mirror, based in Vietnam
Here's the link to the mirror: http://mirror.kirbee.tech/debiancd/
Server bandwidth: 200Mbit/s

Thanks and regards.


lvm2 udebs vs. libaio1-udeb (was: Progress on t64 transition -> building the installer in sid)

2024-03-21 Thread Cyril Brulebois
Hi,

Cyril Brulebois  (2024-03-21):
> I'm a bit conflicted about what to do here. At the moment, libaio1-udeb
> is the only udeb with t64 (at least according to the output of
> `apt-file search -Iudeb t64`); but a rebuild of the reverse dependencies
> would be sufficient (and might happen at some point anyway).
> 
> For the sake of consistency, I think I'm tempted to suggest a revert of
> the udeb part (it wasn't renamed so there's a contents vs. package name
> mismatch anyway).

Checking libaio's changelog (last mail got sent a little too fast,
sorry) is enlightening: this library required special attention and
wasn't just about getting rebuilt with a different package name.

  
https://tracker.debian.org/news/1509816/accepted-libaio-03113-6-source-into-unstable/

Guillem is absolutely right regarding avoiding the roundtrip to NEW and
d-i's not caring, but some kind of heads-up to debian-boot@ (now cc'd)
would have been welcome.

It'd be nice if the Debian LVM Team (hello waldi) could pick it up from
here and see whether requesting a binNMU is what makes most sense here,
or if there other plans on the t64 front. A local, cowbuilder-powered
rebuild of unstable's lvm2 results in udebs referencing libaio.so.1t64
as expected (i.e. libaio1t64's shlibs).


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


signature.asc
Description: PGP signature


Re: Progress on t64 transition -> building the installer in sid

2024-03-21 Thread Cyril Brulebois
Hi,

Roland Clobus  (2024-03-21):
> On 21/03/2024 15:58, Cyril Brulebois wrote:

[…]

> The diagram shows nicely that the t64-transition is affecting the
> installer, with currently 1 major bottleneck, libpng16-16t64-udeb:
> https://d-i.debian.org/dose/graph-unstable-amd64.png

Glad you like it, those have been quite useful a very long while back;
it's been a while since the last time we had such a huge archive-wide
transition…

> > Do you have more details? That thing doesn't exist, but libaio.so.1
> > does (different suffix order).
> 
> My bad, I reversed the order when typing.

No worries, thanks for confirming.

> I've done some basic triaging in the openQA comment:
> https://openqa.debian.net/tests/244163#comments
> 
> The installer fails here:
> https://openqa.debian.net/tests/244163#step/grub/3
> 
> Some details are here (/var/log/syslog):
> https://openqa.debian.net/tests/244163#step/grub/35

Thanks, that's pvs from lvm2-udeb; for some reason libaio1-udeb got
t64-transitioned, and without an lvm2 rebuild, its tools will want the
non-t64 version.

I'm a bit conflicted about what to do here. At the moment, libaio1-udeb
is the only udeb with t64 (at least according to the output of
`apt-file search -Iudeb t64`); but a rebuild of the reverse dependencies
would be sufficient (and might happen at some point anyway).

For the sake of consistency, I think I'm tempted to suggest a revert of
the udeb part (it wasn't renamed so there's a contents vs. package name
mismatch anyway).

> > In any case, there are no reasons to complicate the t64 transition with
> > transitioning udebs, so I wouldn't be surprised if “images” (whatever
> > they are) built against old udebs would break if newer udebs are pulled
> > from the network.
> 
> The images I've spoken of are the daily-built Debian live ISO-images based
> on sid. They are built by Jenkins https://jenkins.debian.net/view/live/

OK, but what I meant to say is that the failure mode I was alluding to
isn't specific to d-i daily builds, or debian-cd builds, or live builds;
that's something that can happen, and might do until things stabilize.


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


signature.asc
Description: PGP signature


Re: Progress on t64 transition -> building the installer in sid

2024-03-21 Thread Roland Clobus

Hello Cyril, list,

On 21/03/2024 15:58, Cyril Brulebois wrote:

https://lists.debian.org/debian-boot/2024/03/msg00102.html


The diagram shows nicely that the t64-transition is affecting the 
installer, with currently 1 major bottleneck, libpng16-16t64-udeb:

https://d-i.debian.org/dose/graph-unstable-amd64.png


On openQA I've additionally seen that for Debian Edu, the installer fails
with the message that libaio.1.so is missing, so some udeb is probably also
requiring an update.


Do you have more details? That thing doesn't exist, but libaio.so.1
does (different suffix order).


My bad, I reversed the order when typing.

I've done some basic triaging in the openQA comment:
https://openqa.debian.net/tests/244163#comments

The installer fails here:
https://openqa.debian.net/tests/244163#step/grub/3

Some details are here (/var/log/syslog):
https://openqa.debian.net/tests/244163#step/grub/35


In any case, there are no reasons to complicate the t64 transition with
transitioning udebs, so I wouldn't be surprised if “images” (whatever
they are) built against old udebs would break if newer udebs are pulled
from the network.


The images I've spoken of are the daily-built Debian live ISO-images 
based on sid. They are built by Jenkins 
https://jenkins.debian.net/view/live/
Seeing the breakage on sid before the weekly-build installer breaks on 
trixie would be nice :-)


With kind regards,
Roland


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1067442: marked as done (contains files for different architecture)

2024-03-21 Thread Debian Bug Tracking System
Your message dated Thu, 21 Mar 2024 17:25:35 +0100
with message-id <20240321162535.eo3ebgnohaq5o...@mraw.org>
and subject line Re: Bug#1067442: contains files for different architecture
has caused the Debian Bug report #1067442,
regarding contains files for different architecture
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1067442: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067442
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: syslinux-efi
Version: 3:6.04~git20190206.bf6db5b4+dfsg1-3
Severity: grave
X-Debbugs-Cc: dbarysh...@gmail.com

The ARM64 syslinux-efi package binaries for x86 instead instead of ARM
binaries:

$ uname -m
aarch64

$ file /usr/lib/SYSLINUX.EFI/efi*/syslinux.efi
/usr/lib/SYSLINUX.EFI/efi32/syslinux.efi: PE32 executable (EFI application) 
Intel 80386 (stripped to external PDB), for MS Windows
/usr/lib/SYSLINUX.EFI/efi64/syslinux.efi: PE32+ executable (EFI application) 
x86-64 (stripped to external PDB), for MS Windows

As such these binaries are unusable on ARM64 hosts.

-- System Information:
Debian Release: 12.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 6.6.9-qcomlt-arm64-00188-g31f49428dc7d (SMP w/4 CPU threads; 
PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

syslinux-efi depends on no packages.

Versions of packages syslinux-efi recommends:
ii  syslinux-common  3:6.04~git20190206.bf6db5b4+dfsg1-3

Versions of packages syslinux-efi suggests:
ii  dosfstools  4.2-1

-- no debconf information
--- End Message ---
--- Begin Message ---
Hi,

Dmitry Baryshkov  (2024-03-21):
> Package: syslinux-efi
> Version: 3:6.04~git20190206.bf6db5b4+dfsg1-3
> Severity: grave
> X-Debbugs-Cc: dbarysh...@gmail.com
> 
> The ARM64 syslinux-efi package binaries for x86 instead instead of ARM
> binaries:
> 
> $ uname -m
> aarch64
> 
> $ file /usr/lib/SYSLINUX.EFI/efi*/syslinux.efi
> /usr/lib/SYSLINUX.EFI/efi32/syslinux.efi: PE32 executable (EFI application) 
> Intel 80386 (stripped to external PDB), for MS Windows
> /usr/lib/SYSLINUX.EFI/efi64/syslinux.efi: PE32+ executable (EFI application) 
> x86-64 (stripped to external PDB), for MS Windows
> 
> As such these binaries are unusable on ARM64 hosts.

There's a single `Architecture: all` package, there are no
architecture-specific builds for this package…

https://repo.or.cz/syslinux.git/tree/HEAD:/efi knows about efi32 and
efi64, not about ARM.

And I can't find any information about ARM anywhere anyway…

 extlinux arch=amd64,i386,x32
 isolinux arch=all
 pxelinux arch=all
 syslinux arch=amd64,i386,x32
 syslinux-common arch=all
 syslinux-efi arch=all
 syslinux-utils arch=amd64,i386,x32

Sounds like not a bug, instead of a grave bug…


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


signature.asc
Description: PGP signature
--- End Message ---


Bug#1067442: contains files for different architecture

2024-03-21 Thread Dmitry Baryshkov
Package: syslinux-efi
Version: 3:6.04~git20190206.bf6db5b4+dfsg1-3
Severity: grave
X-Debbugs-Cc: dbarysh...@gmail.com

The ARM64 syslinux-efi package binaries for x86 instead instead of ARM
binaries:

$ uname -m
aarch64

$ file /usr/lib/SYSLINUX.EFI/efi*/syslinux.efi
/usr/lib/SYSLINUX.EFI/efi32/syslinux.efi: PE32 executable (EFI application) 
Intel 80386 (stripped to external PDB), for MS Windows
/usr/lib/SYSLINUX.EFI/efi64/syslinux.efi: PE32+ executable (EFI application) 
x86-64 (stripped to external PDB), for MS Windows

As such these binaries are unusable on ARM64 hosts.

-- System Information:
Debian Release: 12.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 6.6.9-qcomlt-arm64-00188-g31f49428dc7d (SMP w/4 CPU threads; 
PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

syslinux-efi depends on no packages.

Versions of packages syslinux-efi recommends:
ii  syslinux-common  3:6.04~git20190206.bf6db5b4+dfsg1-3

Versions of packages syslinux-efi suggests:
ii  dosfstools  4.2-1

-- no debconf information



Re: Progress on t64 transition -> building the installer in sid

2024-03-21 Thread Cyril Brulebois
Roland Clobus  (2024-03-19):
> For the other images, the installer is currently failing to build from
> source, as some dependencies (in the udebs) are still missing (due to
> the t64-transition).
> 
> The latest message (from my local build_cdrom_gtk.log) is:
> 
> The following packages have unmet dependencies:
>  libcairo2-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not
> installable
>  libfreetype6-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not
> installable
>  libgdk-pixbuf-2.0-0-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it
> is not installable
>  libinput10-udeb : Depends: libmtdev1t64 but it is not installable

https://lists.debian.org/debian-boot/2024/03/msg00102.html

> On openQA I've additionally seen that for Debian Edu, the installer fails
> with the message that libaio.1.so is missing, so some udeb is probably also
> requiring an update.

Do you have more details? That thing doesn't exist, but libaio.so.1
does (different suffix order).

In any case, there are no reasons to complicate the t64 transition with
transitioning udebs, so I wouldn't be surprised if “images” (whatever
they are) built against old udebs would break if newer udebs are pulled
from the network.


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


signature.asc
Description: PGP signature


Progress on t64 transition -> building the installer in sid

2024-03-19 Thread Roland Clobus

Hello list,

Since two days the live images based on sid can be generated again 
(hurray!), now that debootstrap is able to generate a bootstrap again.
The smallest image is generated properly now, because it does not have 
an installer.


For the other images, the installer is currently failing to build from 
source, as some dependencies (in the udebs) are still missing (due to 
the t64-transition).


The latest message (from my local build_cdrom_gtk.log) is:

The following packages have unmet dependencies:
 libcairo2-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not 
installable
 libfreetype6-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is 
not installable
 libgdk-pixbuf-2.0-0-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but 
it is not installable

 libinput10-udeb : Depends: libmtdev1t64 but it is not installable

On openQA I've additionally seen that for Debian Edu, the installer 
fails with the message that libaio.1.so is missing, so some udeb is 
probably also requiring an update.


With kind regards,
Roland Clobus


OpenPGP_signature.asc
Description: OpenPGP digital signature


Minor suggested change to https://www.debian.org/CD/live/#choose_live

2024-03-18 Thread Dennis Hoelgaard Bal
Hello Debian CD team

I am not sure if this is the correct channel for such a request, but if not, I 
am hoping you can point me in the right direction.

I am writing about the page "https://www.debian.org/CD/live/#choose_live;. I 
just want to say that I found it less-than-obvious how to start the Calamares 
Installer. This is despite having watched a Youtube video beforehand going 
through the normal installer, and being very clear that I did not want to do 
that, as I read the linked page and went though the installation process. The 
issue was that at no point did I see that Calamares is an executable program, 
launched from the live session. I tried the normal "install from a USB media" 
approach, which put me through the normal installer. I expected to be presented 
with an option to chose installer in the start of the process, but when it was 
clear this was not going to happen, I had come far enough to just push through.

I also think the fix is rather simple. On the linked page, I would change the 
following statement:
Installer: The live images contain the end-user-friendly Calamares 
Installer, a distribution-independent installer 
framework, as alternative to our well known 
Debian-Installer.

To this:
Installer: The live images contains the Calamares 
Installer as an alternative to our well known 
Debian-Installer. Calamares is 
an end-user friendly and distribution-independent installer framework, 
available as an executable program in the live-session.

Regards,
Dennis Hoelgaard Bal


Weekly builds missing logfiles

2024-03-18 Thread Daniel Lewart
Debian weekly installation images builders,

Weekly build for amd64:
https://cdimage.debian.org/cdimage/weekly-builds/amd64/
These failed Mar 11 and 18.

This page has links to eight logfiles for Mar 11 and eight for Mar 18.
Clicking on all of them results in "Not Found".

Weekly build for arm64:
https://cdimage.debian.org/cdimage/weekly-builds/arm64/
This succeeded Mar 18.

It says "Logs are in the log/success directory."
That directory exists, but it is empty.

I understand that builds are failing, probably because of complex transitions.
My concern is that there are no log files.

Thank you!
Daniel Lewart
Urbana, Illinois



"USB" ISO sets / apt-cdrom USB counterpart?

2024-03-17 Thread john faulk
Good evening/morning everyone,

I find myself in a thought: as USB media becomes cheaper and cheaper,
more so than even Blu-Ray discs or especially DVDs, why not a full USB
set, for 16 or 32GB flash drives? Or at the very least, more automated
support for people who need to use flash drives with apt-cdrom, rather
than having to constantly go back-and-forth between consoles to mount
and unmount them manually.

My thought is hypothetically, some udev rule or other such config
could be use to auto-detect such a thing on a USB and auto-mount it to
something like /media/usb (instead of cdrom).

T'was just a passing thought.

-John



Processed: retitle 1065435 to aptitude: FTBFS on armhf and armel: deduced conflicting types for parameter ‘const T’ (‘long int’ and ‘__suseconds64_t’ {aka ‘long long int’}) ...

2024-03-05 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> retitle 1065435 aptitude: FTBFS on armhf and armel: deduced conflicting types 
> for parameter ‘const T’ (‘long int’ and ‘__suseconds64_t’ {aka ‘long long 
> int’})
Bug #1065435 [src:aptitude] aptitude: FTBFS on armhf and armel (probably 
-Werror=implicit-function-declaration related)
Changed Bug title to 'aptitude: FTBFS on armhf and armel: deduced conflicting 
types for parameter ‘const T’ (‘long int’ and ‘__suseconds64_t’ {aka ‘long long 
int’})' from 'aptitude: FTBFS on armhf and armel (probably 
-Werror=implicit-function-declaration related)'.
> reassign 1065407 cdimage.debian.org
Bug #1065407 [debian-dvd-1] debian-dvd-1: To enable Japanese input using anthy 
and uim, uim-anthy package is neccessary for Debian-DVD-1 installation media
Warning: Unknown package 'debian-dvd-1'
Bug reassigned from package 'debian-dvd-1' to 'cdimage.debian.org'.
No longer marked as found in versions 12.5.0.
Ignoring request to alter fixed versions of bug #1065407 to the same values 
previously set
> reassign 1062802 src:pam 1.5.3-2
Bug #1062802 {Done: Sam Hartman } [libpam0t64] libpam0t64: 
file loss during upgrade due to /usr-move DEP17
Warning: Unknown package 'libpam0t64'
Bug reassigned from package 'libpam0t64' to 'src:pam'.
No longer marked as found in versions pam/1.5.3-2.
No longer marked as fixed in versions pam/1.5.3-4 and pam/1.5.3-3.
Bug #1062802 {Done: Sam Hartman } [src:pam] libpam0t64: 
file loss during upgrade due to /usr-move DEP17
Marked as found in versions pam/1.5.3-2.
> fixed 1062802 1.5.3-4
Bug #1062802 {Done: Sam Hartman } [src:pam] libpam0t64: 
file loss during upgrade due to /usr-move DEP17
Marked as fixed in versions pam/1.5.3-4.
> fixed 1062802 1.5.3-3
Bug #1062802 {Done: Sam Hartman } [src:pam] libpam0t64: 
file loss during upgrade due to /usr-move DEP17
Marked as fixed in versions pam/1.5.3-3.
> thanks
Stopping processing here.

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



Re: Jigdo files wrong?

2024-03-04 Thread Steve McIntyre
Hi Marcelo,

On Mon, Mar 04, 2024 at 12:25:49PM -0300, Marcelo B. wrote:
>Hi guys, there seem to be a problem with AMD64's jigdo files of the weekly
>builds: they're all the same at 120 bytes in size.

ACK, thanks for reporting. I'll take a look.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
“Why do people find DNS so difficult? It’s just cache invalidation and
 naming things.”
   -– Jeff Waugh (https://twitter.com/jdub)



Jigdo files wrong?

2024-03-04 Thread Marcelo B.
Hi guys, there seem to be a problem with AMD64's jigdo files of the weekly
builds: they're all the same at 120 bytes in size.
Regards.


Bug#1036828: marked as done (debian-cd: wrong firmware archives built and published for D-I releases?)

2024-02-24 Thread Debian Bug Tracking System
Your message dated Sat, 24 Feb 2024 14:46:14 +
with message-id <20240224144614.ga3076...@tack.einval.com>
and subject line Re: Bug#1036828: debian-cd: wrong firmware archives built and 
published for D-I releases?
has caused the Debian Bug report #1036828,
regarding debian-cd: wrong firmware archives built and published for D-I 
releases?
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1036828: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036828
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: debian-cd
Severity: serious

Hi,

During a previous release, I spotted we had two firmware builds, but let
the topic go once I was reassured that was to be expected. For RC 4:

1/43: Starting firmware_bookworm build at 2023-05-27:09:03:53
[…]
9/43: Starting firmware_sid build at 2023-05-27:09:04:01
[…]
  firmware_bookworm finished successfully (started at 2023-05-27:09:03:53, 
ended at 2023-05-27:09:06:31, took 0h02m38s)
[…]
  firmware_sid finished successfully (started at 2023-05-27:09:04:01, ended 
at 2023-05-27:09:07:07, took 0h03m06s)

Now, waiting to see if someone would join the testing efforts, I diffed
firmware lists between rc3 and rc4, and spotted those differences:

-./firmware-sof-signed_2.2.4-1_all.deb
-./intel-microcode_3.20230214.1_amd64.deb
-./intel-microcode_3.20230214.1_i386.deb
+./firmware-sof-signed_2.2.5-1_all.deb
+./intel-microcode_3.20230512.1_amd64.deb
+./intel-microcode_3.20230512.1_i386.deb

The intel-microcode bits are OK:

intel-microcode | 3.20230512.1  | testing/non-free-firmware  | source, 
amd64, i386
intel-microcode | 3.20230512.1  | unstable/non-free-firmware | source, 
amd64, i386

The firmware-sof-signed, not so much:

firmware-sof-signed | 2.2.4-1   | testing/non-free-firmware  | all
firmware-sof-signed | 2.2.5-1   | unstable/non-free-firmware | all

It's a relatively new upload, and it's of course blocked at the moment:

[2023-05-15] Accepted firmware-sof 2.2.5-1 (all source) into unstable (Mark 
Pearson) (signed by: Vincent Bernat)

For the record, those archives end up being published in locations like
the following, and I definitely expected those to match the firmware
packages getting shipped into the images, not be some kind of snapshot of
what's in unstable at the time the release is built!

https://cdimage.debian.org/cdimage/firmware/bookworm/bookworm_di_rc3/

We should definitely clarify the situation, and get to the bottom of that
double firmware build.

From the log lines quoted above, if both bookworm and sid builds end up
shipping files in the same destination directory, the last build wins and
overrides the first one entirely?


See also the “rsync noise” that seemed somewhat OK to ignore. Not sure
whether that's directly related though… ISTR it was probably about some
timestamp discrepancy due to the underlying filesystem. For RC 4:

file has vanished: 
"/home/debian-cd/publish/.bookworm_di_rc4/firmware/firmware.zip"
rsync: stat 
"/dsa/cdimage/.incoming/.bookworm_di_rc4/firmware/.firmware.tar.gz.VQGfUC" 
failed: No such file or directory (2)
rsync: rename 
"/dsa/cdimage/.incoming/.bookworm_di_rc4/firmware/.firmware.tar.gz.VQGfUC" -> 
"firmware.tar.gz": No such file or directory (2)


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

On Sat, Feb 24, 2024 at 11:09:27AM +, James Addison wrote:
>Followup-For: Bug #1036828
>X-Debbugs-Cc: k...@debian.org
>
>On Sat, 24 Feb 2024 11:01:31 +, I wrote:
>> Should this bug be closed?  (the logic to skip the experimental/sid firmware
>> image build during non-testing builds is in place for both bookworm and 
>> trixie)
>
>Nope, it looks like I've misunderstood here.  This change is ready, but pending
>upload (as indicated by the bug tags).
>
>(may be worth double-checking that the bugnumber is referenced-as-closed in the
>changelog, though?)

Thanks for checking on this. In fact, it is closed (so closing with
this mail). The issue was in the debian-cd setup repo, which is Debian
images build-time config and not in the debian-cd package itself.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Welcome my son, welcome to the machine.--- End Message ---


Bug#1036828: debian-cd: wrong firmware archives built and published for D-I releases?

2024-02-24 Thread James Addison
Followup-For: Bug #1036828
X-Debbugs-Cc: k...@debian.org

On Sat, 24 Feb 2024 11:01:31 +, I wrote:
> Should this bug be closed?  (the logic to skip the experimental/sid firmware
> image build during non-testing builds is in place for both bookworm and 
> trixie)

Nope, it looks like I've misunderstood here.  This change is ready, but pending
upload (as indicated by the bug tags).

(may be worth double-checking that the bugnumber is referenced-as-closed in the
changelog, though?)



Bug#1036828: debian-cd: wrong firmware archives built and published for D-I releases?

2024-02-24 Thread James Addison
Followup-For: Bug #1036828
X-Debbugs-Cc: k...@debian.org

Hi Cyril,

Should this bug be closed?  (the logic to skip the experimental/sid firmware
image build during non-testing builds is in place for both bookworm and trixie)

Regards,
James



CD-Mirror

2024-02-21 Thread Arne Ruhnau
Hi, we want to add our CD-Mirror : https://mirror.fra.macarne.com/debian-cd/ 
please let me know if you need anything else from us. Location is in our POP 
Frankfurt am Main,  Sponsor Macarne LLC, contact n...@macarne.com 
 Thanks and greetings, Arne



smime.p7s
Description: S/MIME cryptographic signature


Upcoming stable point release (12.6)

2024-02-16 Thread Jonathan Wiltshire
Hi,

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.

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1



signature.asc
Description: PGP signature


Re: Planning for 12.6

2024-02-15 Thread Mark Hymers
On Mon, 12, Feb, 2024 at 06:04:17PM +, Jonathan Wiltshire spoke thus..
> Hi,
> 
> 12.6 should be around 10th April, so please indicate availability for:
> 
> 7  April
> 13 April
> 20 April

7th or 20th should be ok, but 13th is out for me.

Mark


-- 
Mark Hymers 


signature.asc
Description: PGP signature


Processed: Re: Bug#1063858: Acknowledgement (False disk set size in README.(html|txt), and a few minor corrections)

2024-02-13 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> found 1063858 3.2.1
Bug #1063858 [debian-cd] False disk set size in README.(html|txt), and a few 
minor corrections
Marked as found in versions debian-cd/3.2.1.
> severity 1063858 minor
Bug #1063858 [debian-cd] False disk set size in README.(html|txt), and a few 
minor corrections
Severity set to 'minor' from 'normal'
> thanks
Stopping processing here.

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



Re: Planning for 12.6

2024-02-13 Thread Donald Norwood
Hi,

On 2/12/24 17:28, Steve McIntyre wrote:
> On Mon, Feb 12, 2024 at 06:04:17PM +, Jonathan Wiltshire wrote:
>> Hi,
>>
>> 12.6 should be around 10th April, so please indicate availability for:
>>
>> 7  April
>> 13 April
>> 20 April
> 
> Any of those should work for me, assuming (re Adam) that you mean 6
> April and not 7 April.
> 

Same for Publicity, all dates are good to go.

-- 



Be well,

-Donald

-- 
-
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Donald Norwood
⢿⡄⠘⠷⠚⠋⠀ B7A1 5F45 5B28 7F38 4174
⠈⠳⣄ D5E9 E5EC 4AC9 BD62 7B05


OpenPGP_0xE5EC4AC9BD627B05.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1063858: False disk set size in README.(html|txt), and a few minor corrections

2024-02-13 Thread Kevin Price
Package: debian-cd
X-Debbugs-Cc: J.A. Bezemer , Steve
McIntyre 
Version: 3.2.1
Severity: minor

Dear maintainers, dear Steve[1]:

In the official current stable (12.5) images, the /README.(html|txt)
files (see att.) seem to miscount the total number of disks in each set.
For instance, in debian-12.5.0-amd64-DLBD-2.iso, section "About This
Disc" says: "[...]this disc is number 2 of a set of 1 discs"

1. This is obviously false, not only in the DLBD images.

While we're at it, could we tidy up the generating script in a few more
minor details, without separate bug reports maybe?

2. Aforementioned sentence's full stop is awkwardly misplaced in the
html (line-break in-between), and it's missing in the txt.

3. I was not quite certain about the version number to file this bug
against, so I took a look at the XHTML header for sth. like 'meta
name="generator"'. Wouldn't that be helpful to include?

4. The html claims to be "XHTML 1.0 Strict", but fails to validate
against https://validator.w3.org/ . AFAICT, that's only due to errors in
the section "Last-Minute Notes":

4.a. The "" beginning with "This is an official release" lacks a
closing "".

4.b. Where it says "https://bugs.debian.org/;>bugs.debian.org" it should
respectively say "a", "href", and "/a" instead.

5. The html header defines the language to be "English". Maybe "en"
would be more preferable?

Please let me know how I could be of any further assistance in resolving
these issues.

[1] FWIW, See also
https://lists.debian.org/debian-user/2024/01/msg00796.html , and please
accept my apology for being slow to file this bug.

-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debian-cd depends on:
ii  apt2.6.1
ii  bc 1.07.1-3+b1
ii  bzip2  1.0.8-5+b1
ii  cpp4:12.2.0-3
ii  curl   7.88.1-10+deb12u5
ii  dctrl-tools [grep-dctrl]   2.24-3+b1
ii  dpkg-dev   1.21.22
ii  genisoimage9:1.1.11-3.4
pn  libcompress-zlib-perl  
pn  libdigest-md5-perl 
ii  libdpkg-perl   1.21.22
ii  libfile-slurp-perl .32-2
ii  libyaml-libyaml-perl   0.86+ds-1
ii  lynx   2.9.0dev.12-1
ii  make   4.3-4.1
ii  perl [libdigest-sha-perl]  5.36.0-7+deb12u1
ii  pigz   2.6-1
ii  tofrodos   1.7.13+ds-6
ii  uuid-runtime   2.38.1-5+b1
ii  wget   1.21.3-1+b2
ii  xorriso1.5.4-4

Versions of packages debian-cd recommends:
ii  dosfstools   4.2-1
ii  hfsutils 3.2.6-15
ii  isolinux 3:6.04~git20190206.bf6db5b4+dfsg1-3
ii  mtools   4.0.33-1+really4.0.32-1
ii  syslinux-common  3:6.04~git20190206.bf6db5b4+dfsg1-3

debian-cd suggests no packages.

-- no debconf information

HTH, cheers
-- 
Kevin Price   Debian GNU/Linux 12.5.0 "Bookworm" - Official amd64 DLBD Binary-2 with
   firmware 20240210-11:28

 (HTML version in README.html)

  Welcome to the exciting world of
  Debian GNU/Linux

   This is one disc in a set containing the Debian GNU/Linux distribution.
   Debian is a very extensive collection of software. But it is more. It
   is a complete Operating System (OS) for your computer. And it is free
   (as in "freedom").

   CONTENTS:
 * Introduction
 * About This Disc
 * Installing
 * Last-Minute Notes
 * Installing software using Apt
 * CD/DVD Manufacturers
 * More Information
 * Browse This Disc

Introduction


   An operating system is the set of basic programs and utilities that
   make your computer run. At the core of an operating system is the
   kernel. The kernel is the most fundamental program on the computer,
   which does all the basic housekeeping and lets you start other
   programs. Debian is kernel independent. It currently uses either the
   Linux or FreeBSD kernel. Most of the basic operating system tools come
   from the GNU project; hence the name GNU/Linux.

   Debian is available for various kinds of computers ("architectures").
   Check the ports page for more information.

   Read more at:

 https://www.debian.org/intro/about

About This Disc
===

   This disc is labeled

   Debian GNU/Linux 12.5.0 "Bookworm" - Official amd64 DLBD Binary-2 with
   firmware 20240210-11:28

  

Re: Planning for 12.6

2024-02-13 Thread Andy
On 13 February 2024 14:30:50 GMT, Luna Jernberg  wrote:
>7th or 20th April should work for me
>13th i need to relax a bit before heading to foss-north 2024:
>https://foss-north.se/
>
>Den tis 13 feb. 2024 kl 07:56 skrev Cyril Brulebois :
>>
>> Jonathan Wiltshire  (2024-02-12):
>> > 12.6 should be around 10th April, so please indicate availability for:
>> >
>> > 6  April
>> > 13 April
>> > 20 April
>>
>> Any of those should work.
>>
>>
>> Cheers,
>> --
>> Cyril Brulebois (k...@debian.org)
>> D-I release manager -- Release team member -- Freelance Consultant
>
>

The 6th or 13th can work for both me and Isy.  Sorry the 20th is out for Isy as 
that's the start of her final exams for the IB


If you can let me know the decision date asap I can avoid going away that 
particular Easter weekend...

Thanks in advance 
/Andy



Re: Planning for 12.6

2024-02-13 Thread Luna Jernberg
7th or 20th April should work for me
13th i need to relax a bit before heading to foss-north 2024:
https://foss-north.se/

Den tis 13 feb. 2024 kl 07:56 skrev Cyril Brulebois :
>
> Jonathan Wiltshire  (2024-02-12):
> > 12.6 should be around 10th April, so please indicate availability for:
> >
> > 6  April
> > 13 April
> > 20 April
>
> Any of those should work.
>
>
> Cheers,
> --
> Cyril Brulebois (k...@debian.org)
> D-I release manager -- Release team member -- Freelance Consultant



Re: Planning for 12.6

2024-02-12 Thread Cyril Brulebois
Jonathan Wiltshire  (2024-02-12):
> 12.6 should be around 10th April, so please indicate availability for:
> 
> 6  April
> 13 April
> 20 April

Any of those should work.


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


signature.asc
Description: PGP signature


Re: Planning for 12.6

2024-02-12 Thread Jonathan Wiltshire
On Mon, Feb 12, 2024 at 06:29:36PM +, Adam D. Barratt wrote:
> On Mon, 2024-02-12 at 18:04 +, Jonathan Wiltshire wrote:
> > 12.6 should be around 10th April, so please indicate availability
> > for:
> > 
> > 7  April
> 
> I assume you mean the 6th here. That should be doable.

I did.

> > 13 April
> 
> Could work, but I would prefer not to for personal reasons.

I suspected as much :)

> > 20 April
> 
> I'll be returning from time abroad probably late the day before, so no
> from me.

Ok.


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1



Re: Planning for 12.6

2024-02-12 Thread Steve McIntyre
On Mon, Feb 12, 2024 at 06:04:17PM +, Jonathan Wiltshire wrote:
>Hi,
>
>12.6 should be around 10th April, so please indicate availability for:
>
>7  April
>13 April
>20 April

Any of those should work for me, assuming (re Adam) that you mean 6
April and not 7 April.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Dance like no one's watching. Encrypt like everyone is.
 - @torproject



Re: Planning for 12.6

2024-02-12 Thread Andrew M.A. Cater
On Mon, Feb 12, 2024 at 06:04:17PM +, Jonathan Wiltshire wrote:
> Hi,
> 
> 12.6 should be around 10th April, so please indicate availability for:
> 
> 7  April
> 13 April
> 20 April
> 
> Thanks,
> 

Should be available for all these

Andy

> -- 
> Jonathan Wiltshire  j...@debian.org
> Debian Developer http://people.debian.org/~jmw
> 
> 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
> ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
> 




Re: Planning for 12.6

2024-02-12 Thread Emyr Williams

I'm pretty sure I'm ok for all those dates, but will confirm.


Emyr

On 12/02/2024 18:04, Jonathan Wiltshire wrote:

Hi,

12.6 should be around 10th April, so please indicate availability for:

7  April
13 April
20 April

Thanks,





Re: Planning for 12.6

2024-02-12 Thread Adam D. Barratt
On Mon, 2024-02-12 at 18:04 +, Jonathan Wiltshire wrote:
> 12.6 should be around 10th April, so please indicate availability
> for:
> 
> 7  April

I assume you mean the 6th here. That should be doable.

> 13 April

Could work, but I would prefer not to for personal reasons.

> 20 April

I'll be returning from time abroad probably late the day before, so no
from me.

Regards,

Adam



Planning for 12.6

2024-02-12 Thread Jonathan Wiltshire
Hi,

12.6 should be around 10th April, so please indicate availability for:

7  April
13 April
20 April

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1



signature.asc
Description: PGP signature


Question about https://cdimage.debian.org/mirror/CRAN/web/packages/psychrolib/readme/README.html

2024-02-09 Thread Olive Clinton
Hello


I’m Olive and I run an advanced AI service called ZeroGPT's Citation Generator 
: https://www.ZeroGPT.com/Citation-Generator


ZeroGPT's Word Counter is a Free and revolutionary tool to an innovative tool 
designed to effortlessly track and analyze word usage in your documents. With 
its user-friendly interface and advanced algorithms, ZeroGPT's Citation 
Generator streamlines the process of generating citation with all the format 
available, providing writers, editors, and students with a powerful resources 
and features.


I stumbled upon your website 
https://cdimage.debian.org/mirror/CRAN/web/packages/psychrolib/readme/README.html
 , and I just have to say: WOW!


I had a quick proposal, I was wondering, would you be interested in featuring a 
link to my website https://www.ZeroGPT.com/Citation-Generator in your piece 
regarding Citation Generator ?


I think it could be a great reference for your own article to provide your 
readers with more valuable information!


Either way, thanks for the shout out and keep up the great work!


Thanks,

Olive

ZeroGPT.com CEO

[https://www.semrush.com/link_building/tracksrv/?id=0045e1b4-38a0-4d14-96b3-51ceeb0c2b8e]


Re: Planning for 12.5/11.9

2024-02-08 Thread Luna Jernberg
you have to do the testing without me this weekend, still sick and
need to rest, rest of this week but will help out another time when i
feel better again

Den tors 8 feb. 2024 kl 07:55 skrev Luna Jernberg :
>
> Might have to back out sadly, have come up with sickness, but good
> luck in the testing, but can't promise i will help this round as i
> might need to rest sickness away
>
> Den ons 17 jan. 2024 kl 08:44 skrev Luna Jernberg :
> >
> > That should work for me
> >
> > Den ons 17 jan. 2024 kl 07:41 skrev Jonathan Wiltshire :
> > >
> > > > On Tue, 2023-12-19 at 21:25 +, Jonathan Wiltshire wrote:
> > > > > It's time to set a date for 12.5 (taking account of the emergency .4)
> > > > > and 11.9. I expect this to be the penultimate update for bullseye
> > > > > before LTS.
> > > > >
> > > > > Please indicate availability for:
> > > > >
> > > > >   Saturday  3rd February (preferred for cadence)
> > > > >   Saturday 10th February
> > > > >   Saturday 17th February
> > >
> > > Let's go for the 10th, announcements to follow.
> > >
> > > Thanks,
> > >
> > > --
> > > Jonathan Wiltshire  j...@debian.org
> > > Debian Developer http://people.debian.org/~jmw
> > >
> > > 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
> > > ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
> > >



Re: Planning for 12.5/11.9

2024-02-07 Thread Luna Jernberg
Might have to back out sadly, have come up with sickness, but good
luck in the testing, but can't promise i will help this round as i
might need to rest sickness away

Den ons 17 jan. 2024 kl 08:44 skrev Luna Jernberg :
>
> That should work for me
>
> Den ons 17 jan. 2024 kl 07:41 skrev Jonathan Wiltshire :
> >
> > > On Tue, 2023-12-19 at 21:25 +, Jonathan Wiltshire wrote:
> > > > It's time to set a date for 12.5 (taking account of the emergency .4)
> > > > and 11.9. I expect this to be the penultimate update for bullseye
> > > > before LTS.
> > > >
> > > > Please indicate availability for:
> > > >
> > > >   Saturday  3rd February (preferred for cadence)
> > > >   Saturday 10th February
> > > >   Saturday 17th February
> >
> > Let's go for the 10th, announcements to follow.
> >
> > Thanks,
> >
> > --
> > Jonathan Wiltshire  j...@debian.org
> > Debian Developer http://people.debian.org/~jmw
> >
> > 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
> > ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
> >



Bug#1062000: marked as done (debian-cd: Bookworm images are missing the contrib section)

2024-02-01 Thread Debian Bug Tracking System
Your message dated Thu, 1 Feb 2024 20:52:08 +
with message-id <20240201205208.gg2747...@tack.einval.com>
and subject line Re: Bug#1062000: debian-cd: Bookworm images are missing the 
contrib section
has caused the Debian Bug report #1062000,
regarding debian-cd: Bookworm images are missing the contrib section
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1062000: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062000
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: debian-cd
Version: 3.2.1
Severity: important
X-Debbugs-Cc: mikeonthecompu...@gmail.com

Debian 12, bookworm, images are missing the contrib section of the repositories
in their entirety.  This prevents the use of, for instance, installing ZFS on an
offline computer.

There is quite a lot of useful software in the contrib section and excluding it
from the media sets are a burden, especially for archival purposes of releases.
Using the current mirrors can be fine and all, but eventually 12 won't exist in
the current mirrors anymore, including all the software in contrib.

(Maybe there's an argument that contrib is used for many things that don't 
really
belong in it.  Hypothetically, it's software that depends on non-free, but in
practice, much of it is completely usable without non-free dependencies.)

-- System Information:
Debian Release: 12.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-17-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debian-cd depends on:
ii  apt2.6.1
ii  bc 1.07.1-3+b1
ii  bzip2  1.0.8-5+b1
ii  cpp4:12.2.0-3
ii  curl   7.88.1-10+deb12u5
ii  dctrl-tools [grep-dctrl]   2.24-3+b1
ii  dpkg-dev   1.21.22
pn  libcompress-zlib-perl  
pn  libdigest-md5-perl 
ii  libdpkg-perl   1.21.22
ii  libfile-slurp-perl .32-2
ii  libyaml-libyaml-perl   0.86+ds-1
ii  lynx   2.9.0dev.12-1
ii  make   4.3-4.1
ii  perl [libdigest-sha-perl]  5.36.0-7+deb12u1
ii  pigz   2.6-1
ii  tofrodos   1.7.13+ds-6
ii  uuid-runtime   2.38.1-5+b1
ii  wget   1.21.3-1+b2
ii  xorriso1.5.4-4

Versions of packages debian-cd recommends:
ii  dosfstools   4.2-1
ii  hfsutils 3.2.6-15
ii  isolinux 3:6.04~git20190206.bf6db5b4+dfsg1-3
ii  mtools   4.0.33-1+really4.0.32-1
ii  syslinux-common  3:6.04~git20190206.bf6db5b4+dfsg1-3

debian-cd suggests no packages.

-- no debconf information
--- End Message ---
--- Begin Message ---
On Tue, Jan 30, 2024 at 12:06:03PM -0800, Mike Swanson wrote:
>Package: debian-cd
>Version: 3.2.1
>Severity: important
>X-Debbugs-Cc: mikeonthecompu...@gmail.com
>
>Debian 12, bookworm, images are missing the contrib section of the repositories
>in their entirety.  This prevents the use of, for instance, installing ZFS on 
>an
>offline computer.

That's not exactly a priority use-case, I'll be honest.

However, we used to have contrib included on media sets before
bookworm and it looks like this changed by accident. I've just fixed
config in git now and the next builds will include contrib again.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
“Why do people find DNS so difficult? It’s just cache invalidation and
 naming things.”
   -– Jeff Waugh (https://twitter.com/jdub)--- End Message ---


Bug#1062000: debian-cd: Bookworm images are missing the contrib section

2024-01-30 Thread Mike Swanson
Package: debian-cd
Version: 3.2.1
Severity: important
X-Debbugs-Cc: mikeonthecompu...@gmail.com

Debian 12, bookworm, images are missing the contrib section of the repositories
in their entirety.  This prevents the use of, for instance, installing ZFS on an
offline computer.

There is quite a lot of useful software in the contrib section and excluding it
from the media sets are a burden, especially for archival purposes of releases.
Using the current mirrors can be fine and all, but eventually 12 won't exist in
the current mirrors anymore, including all the software in contrib.

(Maybe there's an argument that contrib is used for many things that don't 
really
belong in it.  Hypothetically, it's software that depends on non-free, but in
practice, much of it is completely usable without non-free dependencies.)

-- System Information:
Debian Release: 12.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-17-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debian-cd depends on:
ii  apt2.6.1
ii  bc 1.07.1-3+b1
ii  bzip2  1.0.8-5+b1
ii  cpp4:12.2.0-3
ii  curl   7.88.1-10+deb12u5
ii  dctrl-tools [grep-dctrl]   2.24-3+b1
ii  dpkg-dev   1.21.22
pn  libcompress-zlib-perl  
pn  libdigest-md5-perl 
ii  libdpkg-perl   1.21.22
ii  libfile-slurp-perl .32-2
ii  libyaml-libyaml-perl   0.86+ds-1
ii  lynx   2.9.0dev.12-1
ii  make   4.3-4.1
ii  perl [libdigest-sha-perl]  5.36.0-7+deb12u1
ii  pigz   2.6-1
ii  tofrodos   1.7.13+ds-6
ii  uuid-runtime   2.38.1-5+b1
ii  wget   1.21.3-1+b2
ii  xorriso1.5.4-4

Versions of packages debian-cd recommends:
ii  dosfstools   4.2-1
ii  hfsutils 3.2.6-15
ii  isolinux 3:6.04~git20190206.bf6db5b4+dfsg1-3
ii  mtools   4.0.33-1+really4.0.32-1
ii  syslinux-common  3:6.04~git20190206.bf6db5b4+dfsg1-3

debian-cd suggests no packages.

-- no debconf information



Upcoming oldstable point release (11.9)

2024-01-24 Thread Adam D. Barratt
Hi,

The next point release for "bullseye" (11.9) is scheduled for Saturday,
February 10th. Processing of new uploads into bullseye-proposed-updates
will be frozen during the preceding weekend.

Regards,

Adam



Upcoming stable point release (12.5)

2024-01-24 Thread Adam D. Barratt
Hi,

The next point release for "bookworm" (12.5) is scheduled for Saturday,
February 10th. Processing of new uploads into bookworm-proposed-updates
will be frozen during the preceding weekend.

Regards,

Adam



Re: Planning for 12.5/11.9

2024-01-16 Thread Luna Jernberg
That should work for me

Den ons 17 jan. 2024 kl 07:41 skrev Jonathan Wiltshire :
>
> > On Tue, 2023-12-19 at 21:25 +, Jonathan Wiltshire wrote:
> > > It's time to set a date for 12.5 (taking account of the emergency .4)
> > > and 11.9. I expect this to be the penultimate update for bullseye
> > > before LTS.
> > >
> > > Please indicate availability for:
> > >
> > >   Saturday  3rd February (preferred for cadence)
> > >   Saturday 10th February
> > >   Saturday 17th February
>
> Let's go for the 10th, announcements to follow.
>
> Thanks,
>
> --
> Jonathan Wiltshire  j...@debian.org
> Debian Developer http://people.debian.org/~jmw
>
> 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
> ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
>



Re: Planning for 12.5/11.9

2024-01-16 Thread Jonathan Wiltshire
> On Tue, 2023-12-19 at 21:25 +, Jonathan Wiltshire wrote:
> > It's time to set a date for 12.5 (taking account of the emergency .4)
> > and 11.9. I expect this to be the penultimate update for bullseye
> > before LTS.
> > 
> > Please indicate availability for:
> > 
> >   Saturday  3rd February (preferred for cadence)
> >   Saturday 10th February
> >   Saturday 17th February

Let's go for the 10th, announcements to follow.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1



Re: Weekly builds of installer/live images failing

2024-01-16 Thread Roland Clobus

Hello Daniel,

On 16/01/2024 09:52, Daniel Lewart wrote:

However, on Jan 8 and 15, the weekly builds of installer/live images
have been failing.
I'll guess that these are part of the fallout from "the big linux changes":
 https://lists.debian.org/debian-kernel/2023/12/msg00421.html
 https://salsa.debian.org/kernel-team/linux/-/merge_requests/851


Indeed. The kernel changes and usrmerge issue in the installer have 
caused build failures for the weekly builds.


They appear to have been resolved now, and Jenkins shows that the daily 
builds for the live images on sid are building (reproducibly) again. The 
tests in OpenQA also look good.


With kind regards,
Roland Clobus


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1060903: Debian testing/trixie ISO fail to boot on Intel Core 2 Duo (64-bit) Dell Inspiron 1545

2024-01-16 Thread Phil Wyett
Package: debian-cd
Version: 3.2.1
Severity: important

Dear Maintainer,

testing/trixie or greater ISO images will not successfully boot and enter 
installation
phase.

Bookworm ISO images have no problems and are successful.

System dmidecode data:

# dmidecode 3.4
Getting SMBIOS data from sysfs.
SMBIOS 2.4 present.
44 structures occupying 1971 bytes.
Table at 0x000F7250.

Handle 0xDA00, DMI type 218, 251 bytes
OEM-specific Type
Header and Data:
DA FB 00 DA B2 00 0D 5F 0F 37 40 7D 00 00 00 00
00 40 00 02 00 01 00 41 00 02 00 00 00 65 00 03
00 00 00 66 00 03 00 01 00 89 01 04 00 00 00 8A
01 04 00 01 00 42 00 05 00 01 00 43 00 05 00 00
00 55 00 06 00 00 00 6D 00 06 00 01 00 2D 00 07
00 02 00 6E 00 07 00 01 00 2E 00 07 00 00 00 11
01 08 00 00 00 10 01 08 00 01 00 F0 00 09 00 01
00 ED 00 09 00 00 00 41 01 0A 00 01 00 40 01 0A
00 00 00 47 01 0B 00 01 00 46 01 0B 00 00 00 4A
01 0C 00 00 00 4B 01 0C 00 01 00 52 01 0D 00 01
00 53 01 0D 00 00 00 80 01 0E 00 01 00 7F 01 0E
00 00 00 F0 F0 0F 00 01 00 F1 F0 0F 00 00 00 94
01 10 00 00 00 93 01 10 00 01 00 86 01 11 00 01
00 85 01 11 00 00 00 82 01 12 00 01 00 81 01 12
00 00 00 9B 01 13 00 00 00 9C 01 13 00 01 00 9D
01 13 00 02 00 FF FF 00 00 00 00

Handle 0xDA01, DMI type 218, 215 bytes
OEM-specific Type
Header and Data:
DA D7 01 DA B2 00 0D 5F 0F 37 40 9E 01 13 00 03
00 EA 00 14 00 00 00 EB 00 14 00 01 00 EC 00 14
00 02 00 28 00 15 00 00 00 29 00 15 00 01 00 2A
00 15 00 02 00 2B 00 16 00 00 00 2C 00 17 00 00
00 0E 01 18 00 01 00 0F 01 18 00 00 00 9B 00 19
00 01 00 9C 00 19 00 00 00 4D 01 1A 00 01 00 4C
01 1A 00 00 00 01 01 1B 00 00 00 02 01 1B 00 01
00 04 01 1B 00 02 00 35 01 1C 00 02 00 37 01 1C
00 00 00 38 01 1C 00 01 00 D9 01 1D 00 01 00 D8
01 1D 00 00 00 EA 01 1E 00 00 00 EB 01 1E 00 01
00 76 01 76 01 01 00 75 01 75 01 01 00 30 02 30
02 01 00 2F 02 2F 02 00 00 01 F0 01 F0 00 00 02
F0 02 F0 00 00 03 F0 03 F0 00 00 04 F0 04 F0 00
00 FF FF 00 00 00 00

Handle 0x, DMI type 0, 24 bytes
BIOS Information
Vendor: Dell Inc.
Version: A10
Release Date: 07/17/2009
Address: 0xF
Runtime Size: 64 kB
ROM Size: 16 MB
Characteristics:
ISA is supported
PCI is supported
PC Card (PCMCIA) is supported
PNP is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
3.5"/720 kB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
AGP is supported
Smart battery is supported
BIOS boot specification is supported
Function key-initiated network boot is supported
Targeted content distribution is supported
BIOS Revision: 1.0
Firmware Revision: 1.0

Handle 0x0100, DMI type 1, 27 bytes
System Information
Manufacturer: Dell Inc.
Product Name: Inspiron 1545   
Version: Not Specified
Serial Number: HJR6YJ1
UUID: 44454c4c-4a00-1052-8036-c8c04f594a31
Wake-up Type: Power Switch
SKU Number: Not Specified
Family:  

Handle 0x0200, DMI type 2, 9 bytes
Base Board Information
Manufacturer: Dell Inc.
Product Name: 0G848F
Version:
Serial Number: .HJR6YJ1.CN7016699Q02UO.
Asset Tag:   

Handle 0x0300, DMI type 3, 13 bytes
Chassis Information
Manufacturer: Dell Inc.
Type: Portable
Lock: Not Present
Version: Not Specified
Serial Number: HJR6YJ1
Asset Tag: Not Specified
Boot-up State: Safe
Power Supply State: Safe
Thermal State: Safe
Security Status: None

Handle 0x0400, DMI type 4, 40 bytes
Processor Information
Socket Designation: Microprocessor
Type: Central Processor
Family: Core 2 Duo
Manufacturer: Intel
ID: 7A 06 01 00 FF FB EB BF
Signature: Type 0, Family 6, Model 23, Stepping 10
Flags:
FPU (Floating-point unit on-chip)

Weekly builds of installer/live images failing

2024-01-16 Thread Daniel Lewart
Debian Images and Live Teams,

First I would like to thank Roland Clobus, et al, for your excellent achievement
of creating reproducible live images.

However, on Jan 8 and 15, the weekly builds of installer/live images
have been failing.
I'll guess that these are part of the fallout from "the big linux changes":
https://lists.debian.org/debian-kernel/2023/12/msg00421.html
https://salsa.debian.org/kernel-team/linux/-/merge_requests/851

1) Weekly builds for amd64:
https://cdimage.debian.org/cdimage/weekly-builds/amd64/

Subdirectories have not been updated since Jan 1.
None of the logfiles exist, which is more concerning.

2) Weekly builds of live images for amd64:
https://cdimage.debian.org/cdimage/weekly-live-builds/amd64/iso-hybrid/
https://cdimage.debian.org/cdimage/weekly-live-builds/source/tar/

No iso files generated in the iso-hybrid directory, probably because
of these errors:
grep: ./dest//MANIFEST.udebs: No such file or directory
cp: cannot stat
'chroot/debian-installer/build/dest/cdrom/vmlinuz': No such file or
directory

The source/tar directory is effectively empty.

Thank you!
Daniel Lewart
Urbana, IL



  1   2   3   4   5   6   7   8   9   10   >