|
|
|
Home » Developing U++ » Releasing U++ » Does the provided upp.spec works for you and on which distro?
| Re: Does the provided upp.spec works for you and on which distro? [message #17702 is a reply to message #17701] |
Tue, 26 August 2008 19:50   |
cbpporter
Messages: 1401
Registered: September 2007
|
Ultimate Contributor |
|
|
| amrein wrote on Tue, 26 August 2008 19:29 |
Because upp is not part of the default OpenSuse repository (I mean, on their website). The install tool only show what is available in their repository.
|
Yes, you are right! It shows the online package version. If all goes well maybe we can include it there. openSuse has the Factory system, which allows users to upload packages. I guess having Suse and Mandriva online packages in third party repository could help a little in boosting U++ popularity. AFAIK, Ubuntu deb is not in any official repository.
| Quote: |
With OpenSuse, the two way I found to install an external rpm are:
- with command line ("Yast -i" or "rpm -i").
- with YaST install/remove tool. But only if the rpm distributor have made a repository specially for OpenSuse. You then need to add first this repository.
|
There is also "zypper install <package>", but as YaST interface, it only works for packages in online repository. It is similar to apt-get, yum and urpmi. I wish people would stop inventing their own package manager front-ends.
| Quote: |
There's also perhaps another way, because I saw a few page on the web with a special "click me" button for quick rpm installation. Something like " click me and I will install this package X from this website " but just for Suse distro.
|
That's the "one click install". It automatically registers a repository, and downloads and installs a package together with it's dependencies. Very useful for KDE (getting the latest 4.x) and other huge packages.
| Quote: |
It works here without problem.
I think you should update your distro with last bug fix.
Options for update (like MS Win update) are in YaST. Mine was buggy even before I tried U++ then I've got the updates and no problem since.
|
I'm up to date and still get crash. I'll try to clean system and do a reinstall to see if the problem persists.
|
|
|
|
| Re: Does the provided upp.spec works for you and on which distro? [message #17703 is a reply to message #17701] |
Tue, 26 August 2008 21:31 |
 |
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| amrein wrote on Tue, 26 August 2008 12:29 |
| cbpporter wrote on Tue, 26 August 2008 00:56 |
I installed the opensuse rpm on two machines, one of them beeing "clean" and It worked. U++ also behaves correctly after install.
There are some issues though.
1. In YaST, the License field for the rpm states "BSD-like, GPL-2.1, LGPL". That's a little much, is it not?
|
U++ include external components using those license. If I write BSD-like only, then people won't know about GPL and LGPL code inside.
|
Only mingw release contains GPLed code. Worst you get for linux releases is LGPL in ndisasm package (which, quite ironically, is only needed for native MSC debugger 
Mirek
|
|
|
|
|
|
|
|
| Re: Does the provided upp.spec works for you and on which distro? [message #17719 is a reply to message #17525] |
Wed, 27 August 2008 15:08 |
 |
amrein
Messages: 278
Registered: August 2008
Location: France
|
Experienced Member |
|
|
There's something wrong in building rpms each night: for me there is no interest for end user and it could be a very big waste of time.
There are 2 types of users:
1. Those who want to use and work with U++ and TheIDE
2. Those who want to contribute and work on U++ and TheIDE source code and send improvements/patches
The fist category wants stable release (deb, rpm). The second category wants access to the svn source code and wants to build Ultimate++ themselves. None of them need everyday rpm build.
| Quote: |
*EXCELLENT* work, thanks a lot.
Might we open a discussion how to do this each night automatically?
IMO, we will need 4 chroot environments, correct?
I guess I should setup something like SFTP on "infra" server so that maintainers can establish (upload) chroot environments required for builds.
IMO, we perhaps need some unified scripting interface to make everything work too..
|
cbpporter talked about OpenSuse "having the Factory system", which allows users to upload packages and build them for many distro on OpenSuse website. Their factory source code is available online (must register to download it).
They don't use chroot but VMWare to simulate all those distro (virtual machines) and have automatic package build from them. We could use VirtualBox instead of VMWare (VMWare is faster and have more options but not so much).
The difference is not so big between virtual computers and real computers. With virtual machines, you can clone the virtual computers easily (on any new installed server). You can make snapshots with one click. You can ask the virtual machine to go back to a previous snapshot with one click to get back to a working and clean build environment. You don't have issue with dbus/sys/proc/hal/... You don't have to mess up with scripts not working because of "chroot ." in another distro root.
Really, I said that it was the easier solution. I didn't know about Novell factory. If people like Novel/OpenSuse use virtual machines, I think they know what they are doing.
Note: This build architecture will be needed for next Ultimate++ release. How many time before 2008.2?
|
|
|
|
| Re: Does the provided upp.spec works for you and on which distro? [message #17722 is a reply to message #17719] |
Wed, 27 August 2008 15:48 |
cbpporter
Messages: 1401
Registered: September 2007
|
Ultimate Contributor |
|
|
| Quote: |
There's something wrong in building rpms each night: for me there is no interest for end user and it could be a very big waste of time.
There are 2 types of users:
1. Those who want to use and work with U++ and TheIDE
2. Those who want to contribute and work on U++ and TheIDE source code and send improvements/patches
The fist category wants stable release (deb, rpm). The second category wants access to the svn source code and wants to build Ultimate++ themselves. None of them need everyday rpm build.
|
I have to agree. Normal users want stable releases. Even I use stable releases most of the time and for all official stuff, and maintain some patches until next dev if I need a fix. Of course, on my hacking machine where I experiment with stuff, I have all the source dirs linked to svn and remain always up to date, except when I'm doing some experimental patch.
But having a working make system that does all the building for all targeted distros is a must, and if the machine is working there is no reason to not do nightly builds, even if most users will stick with stable packages.
What would be better than nightly builds would be to create some kind of Update packages once a small number of bugs have been fixed. These updates must not break anything. If a user downloads 2008.1, he/she will most likely stick with it. But if offered 2008.1 Update 1, which is identical to 2008.1, except for fixed bugs, there would be incentive to upgrade. This is similar to current systems with dev builds, but devs have free form content (like the new allocator that was introduced some while ago and needed some testing before it was proven stable) which offer few advantages for users who want stability. So basically I propose smaller and more frequent updates which are guaranteed not to break anything (except accident of course), and when new features or changes are included, some beta/rc packages followed shortly by by new release and removing dev releases.
Dev branches can be checked out from svn by all developers/testers.
| Quote: |
Note: This build architecture will be needed for next Ultimate++ release. How many time before 2008.2?
|
I don't know when Mirek wants it, but basically I think the sooner the better.
I don't think that with current release schedule we'll have a 2008.2 (but a 2009.1), but probably we'll get to 2008.dev-2 by winter.
|
|
|
|
|
|
|
|
|
|
| Re: Does the provided upp.spec works for you and on which distro? [message #17733 is a reply to message #17727] |
Wed, 27 August 2008 16:31 |
mr_ped
Messages: 825
Registered: November 2005
Location: Czech Republic - Praha
|
Experienced Contributor |
|
|
| luzr wrote on Wed, 27 August 2008 16:17 |
Actually, I was suggesting that the ".1" is not really needed... because it is unlikely we will have another "major" release this year.
In fact, I would like to have next release sort of "ultimate", we remaining U++ issues possibly solved (see and extend "The plan...").
Mirek
|
I would try (if possible and it makes sense) to change+finish 1 thing from "The plan" at a time and release after each one is done.
Waiting for "ultimate" version may easily go from something like 1 year to 5-10 years, and at that point everyone will be either using svn/dev's releases as stable, or still stick to 2008.1 (unlikely).
I mean, let's find the smallest possible set of new features, which makes sense to be implemented together, do them and release. (See also "SCRUM" for reference what I feel)
While I would love version with "all issues solved", I don't believe into such things anymore. There will be always some new issue.
|
|
|
|
| Re: Does the provided upp.spec works for you and on which distro? [message #17739 is a reply to message #17525] |
Wed, 27 August 2008 20:36 |
|
amrein
Messages: 278
Registered: August 2008
Location: France
|
Experienced Member |
|
|
I think I have finally understood why you are still asking for this. If fact, you want to be sure that all U++ svn commit won't break Linux compatibility. Am I wrong?
Ok, but as long as U++ can build on Ubuntu, big patches won't be needed for rpm based distro. Here is a proof, there is no fix for the source code in my src.rpm. Nothing. I just fought with the rpm external dependencies.
Why no break on other distro? Because they use package with the same major release: GTK+ 2.x.x, xorg-1.4.x.x, ...
So, in my opinion, the only think to do is to test if building the unstable release works in Ubuntu.
I will add this:
- A ".rpm" file is a compressed file (using cpio), a kind of tar.gz of the binary (I mean what you get with "make install") with a few extra information at the beginning of the cpio file for authors, licenses, ... That's all.
- A src.rpms is a compressed file too. It's the original source code tarball with a few extra information at the beginning + an automatic build script. That's all. It's like having the tarball + a build script (doing make, make install) + info about the needed dependencies.
If you don't trust me, just type in a console:
# rpm2cpio upp-2008.1-1.src.rpm | cpio -mdiv
# rpm2cpio upp-2008.1-1.fc9.i386.rpm | cpio -mdiv
Really, building a rpm each night is a waste of time. There is no need to test it on all distro each night, only on one distro like Ubuntu is enough. You could even build unstable U++ with TheIDE from the stable release.
Be that as it may, I understood that you would like to create this build factory right now. So, to create this build environment for final release, I think OpenSuse source code from their "Factory system" will speed this process a lot.
[Updated on: Wed, 27 August 2008 20:44] Report message to a moderator |
|
|
|
|
|
|
|
|
|
|
|
| Re: Does the provided upp.spec works for you and on which distro? [message #17897 is a reply to message #17525] |
Tue, 02 September 2008 14:07 |
mr_ped
Messages: 825
Registered: November 2005
Location: Czech Republic - Praha
|
Experienced Contributor |
|
|
EDIT: this was supposed to be reply to another post in I think different thread, but it somehow got lost/deleted/moved when I was posting this?
And you still didn't even hit the "contribute the code, get refused anyway" scenario. 
Well, keep contributing with ideas, discussing them, and your target is to make Mirek believe those changes are good and important. (Or "Uno" is your second change to change something in official U++, the third member of core U++ team does not show up at forums AFAIK)
But don't expect anything happen very fast, if it does not directly suit their needs. Patience. (many of us are going trough this, with complete finished source package it is usually easier to get included into U++, and even that takes lot of time and labor, with major concept changes like your proposals the resistance will be even higher)
Also most of us do use U++ for real projects. Even if those projects are just for fun or their are commercial, but we have very specific needs, etc... most of the time we are just trying to "make it work, eventually fix it in universal way", not the opposite way.
[Updated on: Tue, 02 September 2008 14:18] Report message to a moderator |
|
|
|
Goto Forum:
Current Time: Sat Apr 20 02:29:37 CEST 2024
Total time taken to generate the page: 0.16433 seconds
|
|
|
Members
Pages
Help
Register
Login
Home
