(f5)

[__- -__]

Hi,

legend; software tc(traffic control), x(interactions, iterator)

Teclas função(f1-f12) and media keys together are good to make tc(x) real
motivatings

a) mouse_move_event(s) Update continue ballast  (mice)
b) mouse_click_event(s)   Dispatch IRQ and wait iterator response

f5 update restful workspace. I would like to see websuite(framework web and
suite office)

Any other idea?

Thx

Luiz Franco

Bug#991417: simple-cdd generated iso: No kernel modules were found

[Cyril Brulebois]

Hi Mike,

Mike Depot  (2021-07-22):
> Package: installation-reports
> 
> Boot method: "simple-cdd --qemu-only"
> Image version: 5.10.0-7-amd64
> Date: 2021-07-22

This might be best filed against simple-cdd but anyway…

> I've been using simple-cdd running on my bullseye host to generate a
> custom iso (also bullseye).  My simple-cdd config had been working
> fine until a couple days ago.  Now I am getting an error early in
> debian-installer when I boot from the generated ISO:
> 
> "No kernel modules were found. This probably is due to a mismatch between the 
> kernel used by this version of the installer and the kernel version available 
> in the archive."

Yes, the ABI of the linux kernel was bumped.

I would hope it should be possible to point simple-cdd (and debian-cd)
at the daily builds (which have the required change), but a quick grep
around in the simple-cdd code source and Git repository didn't help me
get the “how” part.

Alternatively, wait for the RC3, which should happen in the next few
days (maybe one week or two, depending on what happens within Debian).


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


signature.asc
Description: PGP signature

Re: Closing the window for the l10n updates

[Cyril Brulebois]

Holger Wansing  (2021-07-23):
> When does that britney run happen?

It happened at 4:00 (and does happen every 6 hours).

We've just gotten lt & ro from 2 M to 5 F.

> There is a bunch of uploads pending, but for holiday and family
> purposes I did not manage to upload them in the last days.

I will certainly not be the one to upload those packages (already busy
with other topics that MUST be ready ASAP), but if someone manages to
get stuff uploaded “shortly”, I can perform another round of l10n hints.

From a quick look around, based on [1], it seems arcboot-installer has a
non-l10n change but that seems harmless (Uploaders update); I'd rather
see partman-auto's recipe change *not* be included as I have no idea
about the scope of this change. Branching bullseye at the last tag,
cherry-picking l10n updates on top of it, and releasing from that branch
would have my preference. If that's the only thing that seems fishy, I
can take care of that particular upload if you'd like.

 1. https://d-i.debian.org/translations.txt

And all that would get us better coverage for fi mainly (at 2 M for
now), kn is also at 2 M but there's only one change, not sure it's going
to make much of a difference (currently 959/1051); and hr is at 5 F
already.


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


signature.asc
Description: PGP signature

Re: Closing the window for the l10n updates

[Holger Wansing]

Hi,

Am 22. Juli 2021 22:39:41 MESZ schrieb Cyril Brulebois :
>Hi Holger,
>
>Thanks again for all your efforts coordinating l10n, including uploads.
>I've just put a bunch of hints in place to let uploads from 2 weeks ago
>reach testing.
>
>After the next britney run, we'll try and avoid touching any more
>packages for l10n purposes. Even if a

When does that britney run happen?

There is a bunch of uploads pending, but for
holiday and family purposes I did not manage
to upload Thema in the last days.

Holger

 language is affected by a very bad
>bug (like crashing due to this particular Unicode codepoint), I think we
>should defer fixing such things until the first point release, so that
>we concentrate on walking the last mile to reach 11.0 in the next 3
>weeks.
>
>That's my general feeling, but I'm happy to discuss specific issues.
>
>
>Cheers,

-- 
Sent from /e/ OS on Fairphone3

Bug#991417: simple-cdd generated iso: No kernel modules were found

[Mike Depot]

Package: installation-reports

Boot method: "simple-cdd --qemu-only"
Image version: 5.10.0-7-amd64
Date: 2021-07-22

Machine: qemu kvm, on top of bullseye amd64
Processor: QEMU Virtual CPU version 2.5+ (over i7-6920HQ physical)
Memory: 4G in QEMU (64G physical)

I've been using simple-cdd running on my bullseye host to generate a custom iso 
(also bullseye).  My simple-cdd config had been working fine until a couple 
days ago.  Now I am getting an error early in debian-installer when I boot from 
the generated ISO:

"No kernel modules were found. This probably is due to a mismatch between the 
kernel used by this version of the installer and the kernel version available 
in the archive."

I find that simple-cdd is generating the iso with the following kernel:
Linux ... 5.10.0-7-amd64 #1 SMP Debian 5.10.40.1 (2021-05-28) x86_64 GNU Linux

However the host system (recently apt upgraded) has the following kernel:
Linux ... 5.10.0-8-amd64 #1 SMP Debian 5.10.46.2 (2021-07-20) x86_64 GNU Linux
(note the date on the kernel is only 2 days prior from when I ran into this 
issue)

I am not specifying mirror/codename nor mirror/suite in the preseed that 
simple-cdd is using.  My understanding is this allows debian-installer to 
install whatever version ends up in the generated iso's initrd.  I also tried 
again with these values enabled and set to "bullseye" however the problem 
remained.

Searching for this error I find that other people that have had the same issue 
in the past.  In past bug reports this seems to have been fixed somewhere in 
the distro, so I'm reporting it here.

Since this problem seems to come back every now and again, I'd also like to 
know if there is a workaround that people can put into their simple-cdd config 
to allow things to keep working when the kernels occasionally get out of sync 
like this.  If that's possible, it might be good to mention that workaround 
here, for future searchers.

Thanks!

Re: NOUVEAU GNU (cqc)

[__- -__]

Not like a BOSS (DataBase sysadmin)

xD

Att,

Luiz Franco

On Thu, Jul 22, 2021 at 9:58 PM __- -__  wrote:

> Hi,
>
> NVIDIA, what you problem?
>
> Community is getting high work on supporting into proprietary disaster
> driver vbios and fullstack.
>
> Please integrate tty(n) with excel(calc, no_visual_grade) model via
> bootstrap|ajax and some another webframework that deals with.
>
> Stop killing us, WAKEUP!
>
> Campaign, NOMORE_XORG_WAYLAND
>
>
>

NOUVEAU GNU (cqc)

[__- -__]

Hi,

NVIDIA, what you problem?

Community is getting high work on supporting into proprietary disaster
driver vbios and fullstack.

Please integrate tty(n) with excel(calc, no_visual_grade) model via
bootstrap|ajax and some another webframework that deals with.

Stop killing us, WAKEUP!

Campaign, NOMORE_XORG_WAYLAND

Closing the window for the l10n updates

[Cyril Brulebois]

Hi Holger,

Thanks again for all your efforts coordinating l10n, including uploads.
I've just put a bunch of hints in place to let uploads from 2 weeks ago
reach testing.

After the next britney run, we'll try and avoid touching any more
packages for l10n purposes. Even if a language is affected by a very bad
bug (like crashing due to this particular Unicode codepoint), I think we
should defer fixing such things until the first point release, so that
we concentrate on walking the last mile to reach 11.0 in the next 3
weeks.

That's my general feeling, but I'm happy to discuss specific issues.


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


signature.asc
Description: PGP signature

Re: Releasing bullseye on 14 August 2021 [Was Re: Finding a tentative bullseye release date]

[Laura Arjona Reina]

 Hi all
I'm also available, adding myself below:

El 22 de julio de 2021 21:18:43 CEST, Paul Gevers  escribió:
>Hi all,
>
>Thanks to the reply from Ansgar, we now have a release date for
>bullseye: 14 August. For the avoidance of doubt, this is *not* a
>tentative date anymore. I'll do a proper announcement later today or
>tomorrow evening.
>
>14 August (day before DebCamp)
>   RT: Adam
>   Image: Steve, Andy
Press: Donald, Laura
>   FTP: Ansgar
>
>Paul
>
Thanks everybody!
Kind regards
-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona
Sent with K-9 mail

Releasing bullseye on 14 August 2021 [Was Re: Finding a tentative bullseye release date]

[Paul Gevers]

Hi all,

Thanks to the reply from Ansgar, we now have a release date for
bullseye: 14 August. For the avoidance of doubt, this is *not* a
tentative date anymore. I'll do a proper announcement later today or
tomorrow evening.

14 August (day before DebCamp)
RT: Adam
Image: Steve, Andy
Press: Donald
FTP: Ansgar

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Re: Bug#991372: unblock: glibc/2.31-13

[Cyril Brulebois]

Hi,

Aurelien Jarno  (2021-07-21):
> d-i team is Cc:ed.
> 
> unblock glibc/2.31-13

Looks good to me, thanks.


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


signature.asc
Description: PGP signature

Bug#991403: mtools: mcopy fails on arm*, breaks d-i builds

[Cyril Brulebois]

Package: mtools
Version: 4.0.33-1
Severity: serious
Tags: d-i
Justification: breaks d-i
X-Debbugs-Cc: debian-boot@lists.debian.org

Hi,

The latest upload of mtools to unstable breaks d-i builds on arm* (at
least arm64 and armhf), hindering our ability to publish newer releases
of the installer for bullseye:

Example on arm64:

efi-image -o ./tmp/cdrom_grub/grub_efi -g arm64-efi \
-e aa64 -n debian-installer/arm64 \
-s y -d ./tmp/cdrom_grub/lib
util/efi-image: Using pre-signed grub-efi and shim binaries for aa64
util/efi-image: Running first pass of mkfs.msdos with size 25426 blocks
mkfs.fat 4.2 (2021-01-31)
./tmp/cdrom_grub/grub_efi/efi.img has 4 heads and 32 sectors per track,
hidden sectors 0x;
logical sector size is 512,
using 0xf8 media descriptor, with 50848 sectors;
drive number 0x80;
filesystem has 2 16-bit FATs and 4 sectors per cluster.
FAT size is 52 sectors, and provides 12677 clusters.
There are 4 reserved sectors.
Root directory contains 512 slots and uses 32 sectors.
Volume ID is deb1, no volume label.
mcopy: No directory slots
mcopy: No directory slots
mcopy: No directory slots
mcopy: No directory slots
mcopy: No directory slots
[ repeats a lot ]

Build failures with daily builds:
  https://d-i.debian.org/daily-images/arm64/20210722-02:15/build_cdrom_grub.log
  https://d-i.debian.org/daily-images/armhf/20210722-00:14/build_cdrom_grub.log

This can be reproduced with the debian-installer source package in
unstable, after a single change in build/config/common to catch up
with recent ABI change:

-LINUX_KERNEL_ABI ?= 5.10.0-7
+LINUX_KERNEL_ABI ?= 5.10.0-8

This is clearly a regression from the previous version (4.0.32-1),
which seemed plausible given the timing of daily build failure
regression (between Jul 21 and Jul 22); but that's also been confirmed
by reproducing the issue in an arm64 sid schroot on amdahl, then by
reverting to the previous version, unpacked in ~/mtools, and PATH
overridden with ~/mtools:$PATH → the issue goes away.


On a side note, I must say I'm quite confused seeing all those new
upstream releases going to unstable instead of experimental during a
freeze:
  https://tracker.debian.org/pkg/mtools


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