Debian Bookworm Gcc

[Manases Blakemore]

Iunderstand that this package is no longer supported on the Debian 12 bookworm. Is there an alternative way to enable mail rate limiting? Is there a new implementation coming/considered? What would be the timeline? Thanks! I appreciate your support here.

I did so, too, and had to jump through a lot of burning rings to keep CRE working. There are several perl incompatibilities, so now I have these obsolete packages lingering around (which could theoretically also be installed on a fresh bookworm installation if you download them from packages.debian.org or add the buster distro to your sources.list):

I've noticed that the Label, Origin and Description of the cloud-sdk-bookworm Debian repo have changed to "cloud-sdk-bullseye". Can be viewed here: -sdk-bookworm/Release. They seem to be correct for packages.cloud.google.com/apt/dists/cloud-sdk-bullseye/Release. I only noticed it because an automated build which uses the cloud-sdk:466.0.0-slim Docker image has started failing on "apt update" with:

E: Repository ' cloud-sdk-bookworm InRelease' changed its 'Origin' value from 'cloud-sdk-bookworm' to 'cloud-sdk-bullseye'

E: Repository ' cloud-sdk-bookworm InRelease' changed its 'Label' value from 'cloud-sdk-bookworm' to 'cloud-sdk-bullseye'

N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.

As for the info for others how I temporary "fixed it" - not without consequences. We are using docket image google/cloud-sdk from docket hub. I am renaming the entry in the /etc/apt/sources.list.d/google-cloud-sdk.list file entries cloud-sdk-bookworm to cloud-sdk-bullseye as follows:

This issue was known previously and was supposed to be fixed. It seems the problem has resurfaced, potentially due to the new 467.0.0 update, although I have yet to confirm this with the engineering team.

Just checked with 468.0.0 and the apt-get update no longer fails so it seems the issue has been fixed. However, the labels in this file packages.cloud.google.com/apt/dists/cloud-sdk-bookworm/Release still look wrong. That's a really minor thing though so probably not worth fixing.

This actually is still an issue for anyone using unattended-upgrades to update from google-cloud-sdk. I have had to go and manually edit the 50unattended-upgrades file on several Debian 12 systems and replace "origin=cloud-sdk,codename=cloud-sdk,label=cloud-sdk"; with "origin=cloud-sdk-bullseye,codename=cloud-sdk-bookworm,label=cloud-sdk-bullseye";. Undoubtedly, I will forget to check this when it is fixed and will start wondering why my automatic updates are broken. Please can we have the page that dkanov referenced above fixed?

This actually is an issue for anyone using unattended-upgrades to update from google-cloud-sdk. I have had to go and manually edit the 50unattended-upgrades file on several Debian 12 systems and replace "origin=cloud-sdk,codename=cloud-sdk,label=cloud-sdk"; with "origin=cloud-sdk-bullseye,codename=cloud-sdk-bookworm,label=cloud-sdk-bullseye";. Undoubtedly, I will forget to check this when it is fixed and will start wondering why my automatic updates are broken. Please can we have the page that dkanov referenced above fixed?

E: The repository ' bookworm Release' no longer has a Release file.

N: Updating from such a repository can't be done securely, and is therefore disabled by default.

N: See apt-secure(8) manpage for repository creation and user configuration details.

I have spoken with the team who works with linux releases, and they believe they have addressed the root cause of the repository failure. Everything should be working now. If you are still experiencing any issues with the repositories, please let us know and I will pass on that information.

Hm... To be honest I have no idea how this can happen - absolutely new installed OS and Dropbox package from 'zero'?! I just took a look in the install script and there is no something similar. The only things that gets installed, as a repository source there, is the working one. You can take a look in your repositories sources using following command:

Take in mind that the used paths are the default; if you have changed them, correct the command accordingly. All places/files where Dropbox repositories are listed on/in will come up. Usually there should be a single file /etc/apt/sources.list.d/dropbox.list. If other file(s) bring up, find a way to clear Dropbox related lines there. In the file, just mentioned, should be a single line pointing to the working repository. If there is something different, you can override the content using something like following:

The above will set the file content as has to be done by package install script. There all path gets retrieved and used to format similar/equivalent command; here I used the default values. Again, If you have changed something in system configuration, change accordingly the command too. You can do a backup copy in advance, if you want, using following:

Hello!

Last week I had to update my Debian from the current version 11 (Bullseye) to the upcoming release 12 (Bookworm) due to new hardware.

Though this is currently in testing the freeze-period is beginning in a few days and no new packages will be added than. So I was surprised to see that KeePass 2 was removed during the upgrade. The update-history shows very little activity for the package, in fact the last version there was 2.47 and it was removed due to an unresolved bug on 2022-01-06. The package is seemingly abandoned.

I know this is only partly a topic for KeePass (mostly for Debian), but I think it would be a pitty if a major distribution like Debian released without KeepAss, so I am posting here.

Thanks!

Regarding the "testing"-status:

Given that there has not been any recent activity of the package maintainer ( ) and the fact that the staged freeze prepariing the release in summer 2023 will beginn on 2023-01-12 I fear that KeepAss won't be part of the next debian release (at least not in the official repositories).

I have not tried to use the version provided in the ppa you provided above. But this ppa has no connection with Debians official repositories and sources which receive their security support. And for these I have little hope for Bookworm.

I wouldn't mind if future proffed me wrong, though! ;-)

In this case while the warning is scary it has no impact on you, you are not missing out on anything.

Our general hope is that eventually the unpatched official debian can work again.

See below what we actually customised:

On my client it boots into the selection menu.

When I choose the Debian installation it does start the debian installer.

It asks me 3 questions (language, country and keymap) which I answer with the defaults.

Then, after a short screen where it detects installation media, it waits a few seconds on a blue streen, and a notification appears:

So, it looks like the installer cannot find the debian media.

I tried a lot of different arguments in the imgargs using google.

However, it seems I can't find the same system setup for the iPXE environment I have.Most examples all use the netboot.tar.gz, or are examples with older Debian versions.I'm not sure, but I think the examples I can find don't apply on the setup I have, because it is already booting from TFTP. Am I right about that?

I do like to install it from local media, because this network is intended to be disconnected from the internet. However, if it is too difficult, I will also be able to use remote media, as long as I can integrate it with the current (working) solution for the ubuntu installer.

Got it to work, thanks to the pointers of Martin.

Its now a non-local solution (so you'll need an internet connection at the client to dowload the installation media), still working on local installation media and preseeding. I will update this post if I got that to work.

As in my original post, I set up an iPXE environment following this guide. If you don't need Ubuntu, skip the last steps where you download the iso, copy it to the /os-images folder and add it to the menu in the boot.ipxe file.

At this point, I started testing (boot.ipxe menu item will follow underneath) and found out that my client PC needed some additional drivers for the NIC. What I did is add all drivers from the tarball firmware.cpio.gz, but I think you can probably also add only specific ones. The complete set makes the startup pretty slow, because the client has to download them all.

In short: you have to add the drivers to initrd.gz

This is how I did that:

Now my client boots nicely into a working debian installer.As mentioned before, now I will find out how to add the preseed, and maybe using local installation media after that.If someone knows already how to do that: plz let me know!

Update:Managed to get the preseed working too. Had a lot of trouble retrieving that from tftp but it seems like the network interface is not up when it tries to retrieve the preseed file.My debian menu item in poot.ipxe is now as follows:

Not every iso is bootable over network, using NFS to mount the root file system - the issue here is not the pxe environment, it is the debian-installer. I tested the iso above in my environment and ran into the same issue like you did.

With a shell, I found out that the installation system did not even have a network card driver loaded at that moment, so that made it quite obvious why the rootfs could not be mounted - the installer lacked the kernel modules required to access the network - which is probably the reason why all the documentation refers to using netboot.tar.gz when it comes to a network install.

The vanilla answer (such as for VirtualBox) is much simpler than @Vinnie230979's answer. All you need to do is extract the files from -amd64/current/images/netboot/netboot.tar.gz and put it into a directory you use for booting images.

running a BCM module (beagle bone black) with debian 10, I am looking for an up-to-date debian image.

Am I right to look into Index of /rootfs/debian-armhf-iot (rcn-ee.net) for this? Is it worth waiting for debian 12 to appear in there or will this never happen for some incompatibility reason?

3a8082e126