[SOLVED] Does Community subscription come with deb-src?

[esi_y]

Do any (if only some, which ones) of the subscription tiers that include license to access the "enterprise" repository also provide deb-src, i.e. at any given point are there sources provided for every component of what is actually now running on the node?

More practically: If one has a series of bespoke patches that wants to be rolling constantly on and be on the more stable repository how to auto-validate and apply them (minimising manual work for every update on every patched file)? I understand this may deem the support part of the subscription moot, but it is perfectly legitimate use case for e.g. the Community tier.

 

[esi_y]

I'll take that (unless someone with subscription confirms otherwise) like there's no deb-src, as there's none mentioned in the docs [1].

The question however remains, where else do I get the specific version sources knowing what specific package I have installed?

[1] https://pve.proxmox.com/wiki/Package_Repositories#sysadmin_enterprise_repo

 

[LnxBil]

where else do I get the specific version sources knowing what specific package I have installed?

If I understand the question correctly, from GIT by hand. AFAIK, there are no tags, so you may want to look for changes to debian/changelog and use this commit as the reference point.

 

[esi_y]

If I understand the question correctly, from GIT by hand. AFAIK, there are no tags, so you may want to look for changes to debian/changelog and use this commit as the reference point.

I figured, there's just master and some obscure stables:
https://git.proxmox.com/?p=proxmox-ve.git;a=heads

EDIT: I can see some "bump to x.y.z", but that would correspond to releases, i suppose:
https://git.proxmox.com/?p=proxmox-ve.git;a=summary

This is not exactly what I would have expected, does no one at all build custom (patched) from sources?

 

[esi_y]

So yes, it appears that for any package version there is a commit message bump version to x.y.z

I almost wonder if the no branching no nothing in on purpose. I mean, I do not see any benefits in NOT having branches in git.

 

[BobhWasatch]

Not making branches public doesn't mean there aren't any.

 

[esi_y]

Not making branches public doesn't mean there aren't any.

That's why I asked if it's e.g. part of any subscription? It's bit ironic that unpaid access gives one basically very easy ability to build from sources, but the same is not available when running the same package as an enterprise customer? Note that the exact version of packages are not known to non-subscriber, so that's not the issue, neither is price.

I have a bit of an issue to understand that PVE is open-source, but not free - and I mean free too get sources equivalent to what one is running at the time, e.g. to be able to run modified version of it, ableit for payment.

 

[BobhWasatch]

You seem to have a lot of issues with the way Proxmox runs their company. Perhaps you should start one of your own.

 

[esi_y]

You seem to have a lot of issues with the way Proxmox runs their company. Perhaps you should start one of your own.

I said issue to understand it. Maybe a direct answer would have helped, e.g. we do not want people run any modified / patched anything, especially that they will need support from us. We do provide sources only because we have to and also, we want to cherry pick from what that AGPL yields back. But I am just saying, for example ...

 

[BobhWasatch]

Perhaps Proxmox should assign an intern to just answering your questions about how they do things.

 

[esi_y]

Perhaps Proxmox should assign an intern to just answering your questions about how they do things.

No, those things would have been best explained on their website properly since long. At first I thought no one had asked before, but there are bits and traces on the forum, of mostly closed discussions - closed for further comments. Not sure why the forum has limited capacity for that.

 

[BobhWasatch]

You seem to think you are entitled to an answer for whatever random question pops into your head don't you? Why don't they use tags, why do they use sqlite, why do they not allow certain discussion on the forum. It gets tiresome.

I took you out of the bin because you do sometimes say useful things, but I'm swinging back the other way.

 

[esi_y]

You seem to think you are entitled to an answer for whatever random question pops into your head don't you?

I never complained that I am being ignored, I do not bump my questions either, maybe after several days or long weekend or within a context of another one, but not like this. That's useless to everyone else.

This question could have been answered by anyone with subscription e.g. no there's no deb-src confirmed, no we cannot build ourselves either, it's what it is in the offering.

NB It's not any kind of weird question at all, e.g. even Red Hat after what they did (and I do NOT have an opinion on that, not that kind of activist) gives access to sources to their CUSTOMERS. I only asked how Proxmox does it.

 

[LnxBil]

I almost wonder if the no branching no nothing in on purpose. I mean, I do not see any benefits in NOT having branches in git.

Why? Not having something is always simpler than having it, especially with GIT. GIT is tool and it should be as simple as possible.
I don't use a lof of branches in situations where there are not necessary.

It's bit ironic that unpaid access gives one basically very easy ability to build from sources, but the same is not available when running the same package as an enterprise customer?

What? That's not the case. I don't get the information easier in my non-subscription repository as in the enterprise repository. Your sentence is only true for the test repository and only for the time that the packages are already available there.

e.g. we do not want people run any modified / patched anything, especially that they will need support from us

then fork it and build it from source. Those packags are native, not quilt, so you need to incorportate your changes directly and do not have patches. It's normal development, I contributed a couple of times and of course I produced changes to the GIT head version and not something else.

 

[esi_y]

Why? Not having something is always simpler than having it, especially with GIT. GIT is tool and it should be as simple as possible.
I don't use a lof of branches in situations where there are not necessary.

How do you backport fix something?

What? That's not the case. I don't get the information easier in my non-subscription repository as in the enterprise repository. Your sentence is only true for the test repository and only for the time that the packages are already available there.

Are you saying that when there's a "bump to version" commit in the master, that only goes to test at that point? This is not my observation.

then fork it and build it from source. Those packags are native, not quilt, so you need to incorportate your changes directly and do not have patches.

No no no, suppose you have patches for your deployment that you want to roll (e.g. own pmxcfs flavour). If I am "just" on the head, it does not matter to me, I am building/testing what's there, but if I e.g. pay for the enterprise repository of course I would only want to keep patching my pmxcfs (that barely changes) and keep rolling the enterprise repo. What's wrong with that?

It's normal development, I contributed a couple of times and of course I produced changes to the GIT head version and not something else.

You are making the assumption here that your contributions get eventually taken in. That's certainly not going to happen with mine.

 

[LnxBil]

How do you backport fix something?

Those kind of branches are already there, I thought you talk about feature branches and such.

Are you saying that when there's a "bump to version" commit in the master, that only goes to test at that point? This is not my observation.

Depends on the change. If it would be present everywhere at the same time, we would not need different repositories. We don't have this, so there must be a final human decision to push packages to non-test repositories.

No no no, suppose you have patches for your deployment that you want to roll (e.g. own pmxcfs flavour). If I am "just" on the head, it does not matter to me, I am building/testing what's there, but if I e.g. pay for the enterprise repository of course I would only want to keep patching my pmxcfs (that barely changes) and keep rolling the enterprise repo. What's wrong with that?

Therefore fork it and do whatever you want, yet you still need to embedd the changes directly, patches are not possible, it's a native package. Unless you change a lot in the package itself to make it into a quilt package.

You are making the assumption here that your contributions get eventually taken in. That's certainly not going to happen with mine.

Then have a lot of fun keeping up with GIT and merging everything by hand .... I would not want to do this. Maybe ask https://utinet.ru/soft/utinet-backdat/ how they do it.

 

[esi_y]

Depends on the change. If it would be present everywhere at the same time, we would not need different repositories. We don't have this, so there must be a final human decision to push packages to non-test repositories.

I am just saying that there's clearly 3 different repos, but no corresponding branching / tagging. Note I am not saying I want it for free, but if someone is subscribed, he should be able to have such git version checked out at any point.

Therefore fork it and do whatever you want, yet you still need to embedd the changes directly, patches are not possible, it's a native package.

I think this is a misunderstanding, whatever I need to patch, it is a patch. That I have to make install the result does not change it for me. I am patching the official sources.

Then have a lot of fun keeping up with GIT and merging everything by hand .... I would not want to do this. Maybe ask https://utinet.ru/soft/utinet-backdat/ how they do it.

I think I am totally misunderstood here. I do not want to be white labelling something in some dark cellar somewhere. There are two reasons I will not get things taken in:
1) they will not want it - feature wise
2) they will not want it, license wise (their own AGPL)

 

[LnxBil]

I am just saying that there's clearly 3 different repos, but no corresponding branching / tagging. Note I am not saying I want it for free, but if someone is subscribed, he should be able to have such git version checked out at any point.

You can also take the poor man's choice and reconstruct the source from the installed package. If we're only talking about PVE, it's written in interpreted languages, so the package is the source. Scripting around with dpkg -l and you can built something that can be maintained by dpkg-deb, yet it is not optimal. Yet in the end, debuild has no automatism that I know of that does what rpmbuild does with the generation of the source package. Tagging in GIT would help a lot for that, yet there is no upside for Proxmox to do this, just downsides. It's just the continous deliviery approach that is omnipresent.

I think I am totally misunderstood here. I do not want to be white labelling something in some dark cellar somewhere. There are two reasons I will not get things taken in:
1) they will not want it - feature wise
2) they will not want it, license wise (their own AGPL)

As with any open source contribution, you need to accept the license and sign a paper or you cannot send in patches, so the AGPL point should be taken care of ... feature wise .. yeah ... that can always be. The default answer to that was mine ... fork it

 

[esi_y]

You can also take the poor man's choice and reconstruct

No This is not what someone is paying for when subscribed. My point is, if there's no corresponding source available, then it's effectively closed-source. You can't just dump random (all sources all versions) at the customer and say your project is open source.

Tagging in GIT would help a lot for that, yet there is no upside for Proxmox to do this, just downsides. It's just the continous deliviery approach that is omnipresent.

Tagging and CI/CD go hand in hand, I can't imagine not having tags for any structured work in this space.

As with any open source contribution, you need to accept the license and sign a paper or you cannot send in patches,

Sorry, but this is entirely wrong. And it's not just me who took notice of this discrepancy:

https://forum.proxmox.com/threads/czech-translation-for-4-1.25448/#post-128119

so the AGPL point should be taken care of

That's a recurring misconception around here and when I asked about it specifically - expanding on that persons post, I got silent treatment:

https://forum.proxmox.com/threads/czech-translation-for-2-x.11797/#post-696451

... feature wise .. yeah ... that can always be. The default answer to that was mine ... fork it

If I was after forking the whole project, I would not have started asking about deb-src.

 

[LnxBil]

No This is not what someone is paying for when subscribed.

It's stated what you get if you pay for and if that is not to your liking, don't do it. What other commercial open source project in the Debian realm does this?

My point is, if there's no corresponding source available, then it's effectively closed-source. You can't just dump random (all sources all versions) at the customer and say your project is open source.

Have you seen how the GPL is treated by most of the companies using Linux as their underlying system? You get once a gigantic tar ball and that's it. That's way, way worse than providing a git repository with all its sources and you can track the changes from version to version. Yet feel free to add another bugreport to add tags to the repositories and/or add deb-src repositories.

Tagging and CI/CD go hand in hand, I can't imagine not having tags for any structured work in this space.

So, just a lack of imagination then
I've seen development teams having a dedicated "check in" person that handels the commits, and transfering files via USB and merging them manually was common, so common as the manually introduced bugs relase after release ....

Sorry, but this is entirely wrong. And it's not just me who took notice of this discrepancy:
https://forum.proxmox.com/threads/czech-translation-for-4-1.25448/#post-128119

I've signed papers like this for other OpenSource projects in the past, therefore it is common for me. How would you otherwise forfeit the copyright? At least here in Germany, everything I write is copyrighted by default so that no one can use it directly unless I explicitly forfeit my rights to it. Most people don't know this and think "it's on the internet, therefore it is free", which lead to a lot of written warnings and sueing. Just posting a patch somewhere online will not automatically make it AGPL, it's still mine. If they would use it directly and I would issue a written warning claiming my copytight, they would be in deep trouble. I assume in the neighboring Austria, there are similar rights in place, so it makes total sense to me that you need to sign the papers and I did it years ago. Maybe this is different in your country and you see this as a discrepancy.