Building Palemoon for Mageia but branding concerns

[New Tobin Paradigm]

Off-topic:
If this was a different time I suspect I could make big money being a technical policy drafting.. guy.

[Moonchild]

Off-topic:
You should look into doing consultancy work.

[New Tobin Paradigm]

Off-topic:
I'd be a great consultant just like my hero, Dogbert!

[tarakbumba]

Hey, there was a quite hot discussion here while I'm away. As I wrote, I perfectly understand Pale Moon development team and Moonchild. It's just what a developer's concern about his/her code. Same applies to distro developers and there's no common way. You afraid of bugs which would come from distro policies/libraries etc. and they afraid of same from your software. So, my way is clear. As I wrote, I packaged Pale Moon as what official branding rules demands.

If anyone interested here is the package source and how to install it

Ok. Per request I removed anything regarding Pale Moon from here.

[New Tobin Paradigm]

Your mozconfig is still not sane. You will remove it at once. What did you think gives you the right to just put this out there and advertise this when you KNEW there were problems to be resolved.

[Moonchild]

Well the mozconfig is -almost- sane.
And it would have been good to not release anything before running the changes by us(!) -- I understand you were eager to release it but it seems more than a little premature what you did just assuming you had it right and pushing to a live package without checking the final spec file with us.
Like... Why are you forcing host and target? You probably shouldn't.
What about export LDFLAGS="$(echo %{ldflags}),--no-keep-memory -Wl,--reduce-memory-overhead" -- are you assuming nobody has enough memory to build normally? Are you doing any sanity checks around it?
Etc.

ALSO: You need to please NOT be downloading source tarballs from our repo server. It's not calculated on being a file host. Copy it to your own infra and grab from there.

[tarakbumba]

Well the mozconfig is -almost- sane.
And it would have been good to not release anything before running the changes by us(!) -- I understand you were eager to release it but it seems more than a little premature what you did just assuming you had it right and pushing to a live package without checking the final spec file with us.
Like... Why are you forcing host and target? You probably shouldn't.
What about export LDFLAGS="$(echo %{ldflags}),--no-keep-memory -Wl,--reduce-memory-overhead" -- are you assuming nobody has enough memory to build normally? Are you doing any sanity checks around it?
Etc.

ALSO: You need to please NOT be downloading source tarballs from our repo server. It's not calculated on being a file host. Copy it to your own infra and grab from there.

Without forcing host and target, on a Mageia x86_64 chroot 32 bit package building fails. Gcc complains about this but I can't remember what exact message was. Also, without exporting LDFLAGS, even on Open Suse's build server machine becomes out of memory.

[Moonchild]

Right-o, thanks for clearing that up. Any potential fall-out from a limited-memory build will have to be on you; please make sure you do thorough tests at least once for every release as things may shift around.

I'm still a little muddy on how the build works for your distribution -- are you using build servers that only grab the source once for each version and then distribute that as built binaries to end users, or are end-users downloading and compiling themselves? In the latter case downloading the source tarball from rpmo is not good and you need to use your own infra to host a copy. In the former case it's OK.

Otherwise this looks good. Thanks for working with us.

[tarakbumba]

Right-o, thanks for clearing that up. Any potential fall-out from a limited-memory build will have to be on you; please make sure you do thorough tests at least once for every release as things may shift around.

I'm still a little muddy on how the build works for your distribution -- are you using build servers that only grab the source once for each version and then distribute that as built binaries to end users, or are end-users downloading and compiling themselves? In the latter case downloading the source tarball from rpmo is not good and you need to use your own infra to host a copy. In the former case it's OK.

Otherwise this looks good. Thanks for working with us.

OpenSuse Build Service is as name suggests a package build service. It can build OpenSuse, Fedora, Arch Linux, Debian (and derivatives) packages with proper config and hosts built packages. OBS grabs the source once for each version and then distribute that as built binaries to end users.

Anyway, I changed project config and deny anyone but me to download and install Pale Moon packages from my OBS project repository. So, case is closed for me. Btw, your post at FAQ section clarifies almost all for people like me. It's well written and easily understandable. Thank you for spending your time for this topic.

[Moonchild]

OK on the build process then, no problem re: pulling the source from rpmo.

Anyway, I changed project config and deny anyone but me to download and install Pale Moon packages from my OBS project repository. So, case is closed for me.

Sorry... I don't understand. So you go through all this trouble to have a package available for distribution, and working with us (using our time as well) to get everything OK for official branding for redistribution, and then you change it to be a private build for you alone (which wouldn't be subject to such stringent rules if you're not distributing it)...?

You're in the clear for distribution. Don't make this a wasted effort?

[tarakbumba]

OK on the build process then, no problem re: pulling the source from rpmo.

Anyway, I changed project config and deny anyone but me to download and install Pale Moon packages from my OBS project repository. So, case is closed for me.

Sorry... I don't understand. So you go through all this trouble to have a package available for distribution, and working with us (using our time as well) to get everything OK for official branding for redistribution, and then you change it to be a private build for you alone (which wouldn't be subject to such stringent rules if you're not distributing it)...?

You're in the clear for distribution. Don't make this a wasted effort?

Well, I may misunderstood since English isn't my native language. Do you allow me to publish those packages those I've built on OBS? I thought whatever I do they don't fit official branding rules. If I'm allowed than it's awesome! May I post again repository and package info here?

[vannilla]

If I remember correctly the accepted Debian and Ubuntu packages by Steve Pusser is also an OBS, so maybe you could ask him about how to properly set it up, at least regarding pulling the source code and distributing things to users.

[Moonchild]

Well, I may misunderstood since English isn't my native language. Do you allow me to publish those packages those I've built on OBS?

Yes, it all looks good after you've clarified what was still unclear to me regarding the spec file I had a look at (courtesy of Tobin telling me how to have a look at what was in it).
I only ask that you make sure to test for stability of the binaries because of your limited memory situation and take responsibility for your builds (i.e. be available if people have questions/issues with it).

[tarakbumba]

Well, I may misunderstood since English isn't my native language. Do you allow me to publish those packages those I've built on OBS?

Yes, it all looks good after you've clarified what was still unclear to me regarding the spec file I had a look at (courtesy of Tobin telling me how to have a look at what was in it).
I only ask that you make sure to test for stability of the binaries because of your limited memory situation and take responsibility for your builds (i.e. be available if people have questions/issues with it).

Thanks. OBS have bug tracking system so users may ask there in case of a problem. I'll re-add Pale Moon rpm packages asap.

Anyone who wants to try out please see installation instructions and getting Pale Moon rpm packages

[Tharthan]

This is great news.

I always love seeing Pale Moon become more and more available for more and more people.

Wouldn't it be wonderful if every OS that is not outright incompatible with Pale Moon's mission had a version of Pale Moon available for it?

[New Tobin Paradigm]

You should reach out to steve he has used obs for debian builds for years. Maybe you two can collaborate share the work load.

[tarakbumba]

You should reach out to steve he has used obs for debian builds for years. Maybe you two can collaborate share the work load.

Sorry for very late reply. I think we have different paths with steve as he's a Debian based distro maintainer and I'm a Rpm based one. They' re different packaging formats and share a little from packaging perspective. But sharing opinions and discussing on matters always a good thing. Anyways, is there a way to provide Mageia packages more apparent?

[stevenpusser]

Apparently, there are methods to generate rpm, debian, arch, and other distro packages from one set of source packages, if you look at what the SMPlayer dev is doing on the OBS...but it's beyond me at the moment, plus his Debian build is rather archaic by modern standards.

https://build.opensuse.org/package/show ... s/smplayer

[tarakbumba]

Apparently, there are methods to generate rpm, debian, arch, and other distro packages from one set of source packages, if you look at what the SMPlayer dev is doing on the OBS...but it's beyond me at the moment, plus his Debian build is rather archaic by modern standards.

https://build.opensuse.org/package/show ... s/smplayer

Thank you very much @stevepusser. I rather prefer to mess with my distro of knowledge. Since I don't use and don't know Debian based distros and deb packages I simply want to go with Mageia specific packages. Also, as you may see, configuration of osc (preferring some libraries over others, designing rpm spec file in unusual and messy way etc.) is not easy for multi distro packaging