64-bit packaging

[craesz]

Thanks guys.

[daniel]

Welcome aboard, craesz.

+1!     

+1 

[kjpetrie]

Can I ask a really silly (or is it profound) question?

What do we achieve by building and submitting packages for 64-bit?

Unless I'm missing something pretty fundamental, a source rpm installed into a 32-bit build system will build another source rpm and a 32-bit binary. If it is instead installed into a 64-bit build system it will build the same SRPM and a 64-bit binary. So if I take an SRPM and build it on my 64-bit system and submit the SRPM to Dropbox, what does Texstar gain over just taking the existing SRPM from the repo?

Is it just the preliminary test we will do before submitting the result, or am I missing a fundamental step in the process?

[Neal ManBear]

  You cannot build a 64bit RPM on a 32bit system. We build and test on 64bit systems for the 64bit repo. We do not build 64bit RPMs on a 32bit system. That would be foolish, as they would not be 64bit.      

If you do not have a 64bit install, 2 are available. Check the testers M/L for links.

[Archie]

At the moment, I think the process is more of restocking the 64-bit repository. Not all 32-bit SRC.RPM apps (avidemux, kino, moovida comes to mind) will build due to depends that are not yet in the 64-bit repos, and building the missing depends can also fail.

It also allows the packages to be re-checked - specfile, upgrade, etc.  Some packages are years old and some libs are either renamed or no longer exist/not yet built.

It gives us who want to get involved a chance to participate in the testing ... and the chance to learn and help package for PCLOS. Although the final process is still and will always be Texstar.

Some packages are easy to build and some can stress you out ...

I suppose the best thing in my experience is ... community. It brought Neal and me into a much closer relationship, and I'm glad for that.

[Neal ManBear]

At the moment, I think the process is more of restocking the 64-bit repository. Not all 32-bit SRC.RPM apps (avidemux, kino, moovida comes to mind) will build due to depends that are not yet in the 64-bit repos, and building the missing depends can also fail.

It also allows the packages to be re-checked - specfile, upgrade, etc.  Some packages are years old and some libs are either renamed or no longer exist/not yet built.

It gives us who want to get involved a chance to participate in the testing ... and the chance to learn and help package for PCLOS. Although the final process is still and will always be Texstar.

Some packages are easy to build and some can stress you out ...

I suppose the best thing in my experience is ... community. It brought Neal and me into a much closer relationship, and I'm glad for that.

     
Me, too!     

[kjpetrie]

Thanks, Archie. For a minute I thought I hadn't made myself clear enough.

But doesn't that mean converting to 64-bit and upgrading are two separate processes, and isn't upgrading as we go asking for trouble?

It seems to me that a script would be far better at working out dependencies to build packages in the right order, and then install them all, than human trial and error, and the rebuild could run largely unattended. Of course, some packages probably would fail because they're not right for the architecture or might not work as intended, but wouldn't it be better to concentrate the human effort on dealing with those?

So by submitting SRPMs rebuilt on our 64-bit systems we're achieving very little that couldn't be done better automatically using the existing SRPMs. If we think we're helping Texstar rebuild we're deluding ourselves.

Code: [Select]

$ md5sum Dropbox/SRPMS/lxautostart-0.6.5-1leiche2011.src.rpm
e62121b9ddabcc203f2a0fda13f00524  Dropbox/SRPMS/lxautostart-0.6.5-1leiche2011.src.rpm
$ md5sum Dropbox/SRPMS/x86_64/lxautostart-0.6.5-1leiche2011.src.rpm
e62121b9ddabcc203f2a0fda13f00524  Dropbox/SRPMS/x86_64/lxautostart-0.6.5-1leiche2011.src.rpm

The social benefit might be nice, but it's not the object of the exercise.

[gseaman]

I am not currently helping with this effort, but I think there is more value to this than you are realizing. If you scripted the packaging, almost every package would fail and have to be dealt with manually. Even if you don't have a lot of experience packaging, you can find things like changes in the names/versions of libraries, new locations/names of source files, etc. Then, when Tex builds from your srpm, most of the time it will also build on his system. This leaves him more time to solve the trickier problems.

Galen

[kjpetrie]

But surely that only happens when you upgrade. If you simply rebuild the libraries will have the same name. The only slight problem is the release numbers of packages built in previous years wouldn't be reset to 1 and they would all be bumped to 2011 with their current numbers, but if that matters the script could edit the files and even add a changelog entry. Why would most packages fail? They would have to be built in the right order to meet build dependencies, but a script would be better at parsing that information from all the spec files and package lists than a human. The only ones that would fail would be those with missing dependencies where these were not already installed.

I know what I'd do if I were faced with building 12,000 to 14,000 packages once I'd got a core system going to build them. When I had a replica of my 32-bit repo snapshot in 64-bit I'd look to upgrade it to current, and then I'd build for both in parallel. I just don't see how sending Texstar SRPMs he's already got helps him.

[Archie]

That's all true, kjpetrie. Tex and his build server would surely be able to handle all the SRPMS that are already on the 32-bit repository. For me, it is just a good clean exercise, and I don't expect my SRPMS to even be taken seriously. However, we are on an ever-continuing process of adding apps that do not have SRPMS on Tex's build server. I think this is where the contributors can really make a difference.

In addition, applications that have recent updates may not necessarily be on Tex's top priority of thing to do ...

[Texstar]

All 32bit srpms have to be updated and rebuilt on a 64bit system. The specfile in many packages have to be manually edited and converted to be both 32bit and 64bit compatible. Archie has done quite a few conversions.

[craesz]

I would really like to know what I can do to help. I have a box up and running a test 64 system but I thought one of the mini versions was necessary to package. I don't mind using that system to help package if someone could PM me about what issues I need to resolve to use it. I'll load that system up and ship everything built to Tex as soon as I can.... Love to help. Someone point me the right direction please. 

[kjpetrie]

OK, so what are the changes we need to make to the spec file to achieve this? Otherwise, those of us who don't know will start throwing packages at you which don't meet your requirements and that'll just make things worse.

[daniel]

Thanks, Archie. For a minute I thought I hadn't made myself clear enough.

But doesn't that mean converting to 64-bit and upgrading are two separate processes, and isn't upgrading as we go asking for trouble?

It seems to me that a script would be far better at working out dependencies to build packages in the right order, and then install them all, than human trial and error, and the rebuild could run largely unattended. Of course, some packages probably would fail because they're not right for the architecture or might not work as intended, but wouldn't it be better to concentrate the human effort on dealing with those?

So by submitting SRPMs rebuilt on our 64-bit systems we're achieving very little that couldn't be done better automatically using the existing SRPMs. If we think we're helping Texstar rebuild we're deluding ourselves.

Code: [Select]

$ md5sum Dropbox/SRPMS/lxautostart-0.6.5-1leiche2011.src.rpm
e62121b9ddabcc203f2a0fda13f00524  Dropbox/SRPMS/lxautostart-0.6.5-1leiche2011.src.rpm
$ md5sum Dropbox/SRPMS/x86_64/lxautostart-0.6.5-1leiche2011.src.rpm
e62121b9ddabcc203f2a0fda13f00524  Dropbox/SRPMS/x86_64/lxautostart-0.6.5-1leiche2011.src.rpm

The social benefit might be nice, but it's not the object of the exercise.

This is really a bad sample, because it's only a script, nothing more.
For applications like avidemux, or dvdstyler, who need libs, can stress you out...
Often need conversation with maintainer of this applications, see latest winff 

[glamdring]

Are the changes that need to be made to spec available in the testers mailing list? I will try and help out after finals, unfortunately I won't have too much free time until Summer.