@quba42 ,
Thnx, I will give it a try and keep you informed about the result.
@quba42 ,
As the available repo only contains the “main” component I only configured this one in the repo.
But it still fails with the same warning/error:
“value too long for type character varying(255)”
In that case it is probably still trying to save the full list from the upstream release file to some length limited field somewhere. In that case there is no workaround, other than to wait for a fix. 
No problem, anyway thanks for having a look at it.
Will follow up the issue you have created.
Hope I would be able to apply the fix in the code of our current version of Foreman/Katello/Pulp, as we, due to upcoming new systems to be provisioned, don’t have the time to upgrade to the latest version.
@quba42 ,
Just checked the Release file, and only the 3the line (list of all components) contains more than 255 characters, more specific 273.
What version of Katello are you on? Backporting the fix may well be problematic/impossible, since it will involve a DB migration.
I was already afraid that this would be the case. 
Anyway, this not a blocking issue for the upcoming new systems to be provisioned.
Normally we provision our systems with Centos/Rocky.
But for some specific cases another OS as Ubuntu is necessary.
So it would be fixed as soon we have the time to upgrade our system with the latest version.
I now have a PR that I believe will fix this issue: https://github.com/pulp/pulp_deb/pull/364
However, I have no way of testing it since I don’t have a repo that reproduces the issue.
Given the error message, I am pretty confident in the fix.
Due to the required DB migration, patching the fix into a non development environment is difficult/dangerous to anyone without relevant DB-migration experience. I am leaning towards merging this blind…
Perhaps baculasystems support will let me do a test sync if I email them…
@quba42 ,
Thanks for the fast feedback/fix, but …
Hmm, I’m not sure if they would allow it, unless they provide a link for a trial-version.
I just checked the content of the Release file for the community-repo, but this would not help as the file contains only the component “main” which is indeed the only one available in the repo.
And I can’t say that the repo of the trial-version would also contain all those unnecessary components as we have in our enterprise-repo.
From our side we will also open a ticket at bacula to inform them that the list of components contains to much possibles as are made available in the repo.
Hope they will apply a changes for us, even better in their build process of the repos.
They probably won’t change this, since it is perfectly legal for APT repos to contain an arbitrary number of components. It is simply a bad assumption on the pulp_deb side, that “256 characters is enough for all repos”…
Yeah, right. But is does not make any sense to configure all these unnecessary components if they are not provided at all in the repo.
It should not be that difficult for them to create the file in a correct way with only the components they provide.
Same applies for the checksum-data.
Anyway, we will see how they will reply.
Worse case for us is that we probably have to wait until we can upgrade to the latest version of Foreman/Katello/Pulp.
Update: It looks like we will need to add a fix on the Katello side as well, I opened the following issue to track this: Bug #33804: In rare cases upstream APT (deb content) repos can exceed size limited DB fields - Katello - Foreman
@quba42 ,
We are currently testing the upgrade-actions on an old foreman-server:
- Foreman 2.3.x/Katello 3.18.x → Foreman 2.4.x / Katello 4.0.x
- Foreman 2.4.x/Katello 4.0.x → Foreman 2.5.x / Katello 4.1.x
- Foreman 2.5.x / Katello 4.1.x → Foreman 3.0.x / Katello 4.2.x
Are the fixes available for this version?
Thnx for your feedback.
Unfortunately not, since the full fix requires a DB migration in both Katello and pulp_deb, it will not be fixed before Katello 4.4 and is unlikely to be backported from there. 
@quba42 ,
Thanks for the feedback, however, this is really a blocking issue for us.
Is there no way we could apply these fixes (code and DB) manually?
If not, when can we expect this new version of Katello 4.4?
Thnx in advance
@Justin_Sherrill Perhaps you can weigh in: My understanding is that since the pulp_deb fix (released in a version of pulp_deb compatible against pulpcore>=3.15 contains a DB migration that cannot be backported without changing the order of migrations, we can’t get the fix into a Katello version not yet using pulpcore>=3.15?
It is of course possible to backport the fix while manually changing the order of the migration, but then one can never re-converge on the upstream order and is committed to maintaining ones own migrations for ever? Including adjusting the order of all further migrations coming in from all future pulp_deb releases?
@quba42 ,
Thnx for asking.
Additional info regarding the pulpcore version we currently have running in Forman 3.01 / Katello 4.2.1:
rpm -qa | grep pulpcore
tfm-rubygem-pulpcore_client-3.14.1-1.el7.noarch
python3-pulpcore-3.14.9-1.el7.noarch
We hope there is a possibility for us to apply these changes manually.
Regards.
In theory it might also be possible to build a temporary workaround fix that does not need the migration, (and will work so long as the user selects a subset of the upstream repo’s components that does not exceed the 255 characters available in the DB). However, I don’t think I can justify the time to work on that since it just isn’t a pressing issue for us right now…
@quba42 ,
Configuring the specific component(s) was one of the actions we tested out when I discovered this issue.
In our case “main” was the only one we needed.
So, when you might find the time for this possible fix that would be great and I’m looking forward for your feedback and instructions what I need to change and where. Even when this is a temporary fix until Katello 4.4 becomes available.
Thanks in advance.
Regards.