[opensuse-factory] How do changed & new modules enter 'openSUSE'?
So how do changed and new modulels get into the openSUSE factory tree? Is there any control on how packages are added to the tree both at its creation and during its pre-release testing? I'm wondering how a package gets checked into the tree that doesn't appear to have a source that builds? To developers make changes then check them into the openSUSE tree to be 'tested' by the community or do developers ensure they compile before checking them in? Maybe the developer's have something different in their environment than I'm using? Else I don't see how the openssh-keyconverter sub-util in the openssh-5.0p1 source package would not block re-generation of the RPM from the source RPM... ??? --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Linda Walsh
So how do changed and new modulels get into the openSUSE factory tree?
Is there any control on how packages are added to the tree both at its creation and during its pre-release testing?
I'm wondering how a package gets checked into the tree that doesn't appear to have a source that builds? To developers make changes then check them into the openSUSE tree to be 'tested' by the community or do developers ensure they compile before checking them in?
Maybe the developer's have something different in their environment than I'm using? Else I don't see how the openssh-keyconverter sub-util in the openssh-5.0p1 source package would not block re-generation of the RPM from the source RPM...
Are you using the build command? All I can say is that it builds without problems. Otherwise you would not have a src rpm to look at ;-) Andreas -- Andreas Jaeger, Director Platform/openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Andreas Jaeger wrote:
Are you using the build command?
All I can say is that it builds without problems. Otherwise you would not have a src rpm to look at ;-)
Andreas
I understand, I think, your point -- how did the src rpm get generated if it didn't work. That's what I'm trying to find out. I'm using rpmbuild -ba. I'm doing things that build might not support -- but that *shouldn't* make a difference. If I find something that is making the difference, I want to understand why its failing and correct the problem. 1) My initial purpose was to drain the swamp that had the alligators in it...no. Wait, that was last week. 1a) Initial purpose was to apply high-performance source patches to scp/ssh. Goal -- going from current ~3MB/s up to about 10 times that. Max raw TCP with jumbo packets was over 90MB/s. So I have a bit of headroom to improve on. Max file transfer with normal size packets was ~70+MB/s over UDB (CIFS). I hoped NFS/TCP would do better, but that hasn't been the case so far. Nevertheless, my most common method of xferring files has been scp/ssh. So that's my short-term goal. The patches were available against 4.7 or 5.0 versions of openssh. suse10.3 has 4.6 in it. I thought I'd have better luck in 'eventual integration into my systems if I started with a suSE rpm -- I prefer packaging my software mods in rpms -- they are usually fairly stable ways of reproducing the software and preserving its source for later. I checked suse11.0 -- and it is using openssh5.0 -- one of the versions supported by the patchsets. Discovered via trial&error that applying the high-perf patches, Then applying the rest of the suse patches generated fewest conflicts. Only conflict was in a makefile that added suse's libaudit to a link. So at this point, I'm building across releases 11.0 src rpm on 10.3 with 3rd party patches. Is this something "build" is designed for? I had one incompatibility in the resulting 11.0 binary that wanted a krb-gssapi routine I wasn't familiar with. I just assumed it might be new in 11.0 -- and I needed it, I'd need to regen those libs, *however* I don't need krb-gssapi, and since that's an optional component when specifying open-ssh's "Configure" options, I removed it. Now is when I ran into the missing pthread problem. It happens in building a 'subutil' built within the openssh rpm. The openssh.spec builds 2 or 3 separate components -- most recently 'openssh-askpass' was merged (was separate in 10.3). During the change-over, someone removed the pthreads lib from the global LDFLAGS var. While that works for the main prog and the new askpass util, it caused missing libpthread calls in one subpackage. They actually removed it for the entire package -- and it seems it is only this one subpackage that needs it. There's even a comment in the .spec file that says the "posix threads' defines and -lpthread call were "Obsoleted" -- but no reason saying why. -- So whoever made the change thought they had done something to eliminate the need. Maybe that need is hidden or taken care of by using the build command -- but the downside is that the source rpm no longer can be used to build the rpm stand-alone. Whether or not 'build' could be used to reproduce the issue, I don't know -- it's certainly alot more setup to rebuild the openssh package -- "-ba" takes about a minute. It doesn't appear that build would be quite so fast -- and I'm not sure about it's flexibility -- but if it is hiding problems that are 'valid' problems in standalone rpmbuild commands, that's troubling and like peculiar. 99. So now as I find myself up to my bum in alligators...(so to speak...) -- trying to figure out why the rpmbuild command isn't working when it "should"... Am I making sense about why I'm going about and doing things the way I am? Sorry to stir things up needlessly if things were really fine before...really not sure why it wouldn't work now...just weird. Linda ...very tired...brain only firing on a few cylinders... so will have to see if I can sleep now (have sporadic sleeplessness...so...of course I get on my computer and do relaxing things like this...:-) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Linda Walsh
Andreas Jaeger wrote:
Are you using the build command?
All I can say is that it builds without problems. Otherwise you would not have a src rpm to look at ;-)
Andreas
I understand, I think, your point -- how did the src rpm get generated if it didn't work.
That's what I'm trying to find out.
I'm using rpmbuild -ba.
That might mean that you have different packages in the environment than we have. Please double check the BuildRequires line.
I'm doing things that build might not support -- but that *shouldn't* make a difference. If I find something that is making the difference, I want to understand why its failing and correct the problem.
1) My initial purpose was to drain the swamp that had the alligators in it...no. Wait, that was last week.
1a) Initial purpose was to apply high-performance source patches to scp/ssh. Goal -- going from current ~3MB/s up to about 10 times that. Max raw TCP with jumbo packets was over 90MB/s. So I have a bit of headroom to improve on. Max file transfer with normal size packets was ~70+MB/s over UDB (CIFS). I hoped NFS/TCP would do better, but that hasn't been the case so far. Nevertheless, my most common method of xferring files has been scp/ssh. So that's my short-term goal.
The patches were available against 4.7 or 5.0 versions of openssh. suse10.3 has 4.6 in it. I thought I'd have better luck in 'eventual integration into my systems if I started with a suSE rpm -- I prefer packaging my software mods in rpms -- they are usually fairly stable ways of reproducing the software and preserving its source for later.
I checked suse11.0 -- and it is using openssh5.0 -- one of the versions supported by the patchsets. Discovered via trial&error that applying the high-perf patches, Then applying the rest of the suse patches generated fewest conflicts. Only conflict was in a makefile that added suse's libaudit to a link.
So at this point, I'm building across releases 11.0 src rpm on 10.3 with 3rd party patches. Is this something "build" is designed for?
Yes, it is. It might be that more people can help you on the opensuse-packaging mailing list - or try the IRC channel, Andreas -- Andreas Jaeger, Director Platform/openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Andreas Jaeger wrote:
That's what I'm trying to find out.
I'm using rpmbuild -ba.
That might mean that you have different packages in the environment than we have. Please double check the BuildRequires line.
Unless rpm has changed, it also checks the BuildRequires line -- so "theoretically...." :-)
So at this point, I'm building across releases 11.0 src rpm on 10.3 with 3rd party patches. Is this something "build" is designed for?
Yes, it is.
Might be worth at least "setting up", but given how it re-installs all packages from scratch -- If I'm building for a different & incompatible architecture, that's one thing -- but I prefer to work on making packages usable across all my systems. _Usually_, rebuilding a package with one's current environment will make sure that it links with the libraries it needs to run on that system. Ideally --as has been traditional in linux and Open source since the start -- if you wanted something to run on your system, you built it from source on your system and 'configure' tried to take care of the individual system differences. If build installs different packages from what is using in on one's system, doesn't that make build-built packages less likely to be compatible with one's current system.?
It might be that more people can help you on the opensuse-packaging mailing list - or try the IRC channel,
Not a fast typer, so I find IRC not so ideal to use (not to mention my desktop is behind a FW and needs to go through one of my proxies to get to the net). There's likely some howto docs -- the main thing I'd likely want to be able to do is point build at my own, local package dirs -- that might contain some custom packages -- so I'd want to be able to (re)generate needed 'Db's. Of course it still doesn't help me figure out why the spec file has removed pthreads when they appear to be needed. It doesn't *look* like a missing-requirements issue -- I have pthreads. In fact, to get things working, I created a patch to add the needed "-lpthread" arg back into the makefile of the affected util - added it to the sources & included in the spec file -- and everything builds "fine". So my real question at this point is why the pthread lib was removed in the first place any how/why this error hasn't popped up before, as, the way it is, it appears the specfile is broken. I did start my questing by wondering if "libpthread" had somehow become "inherent" in the 11.0 link environment -- if the threads had been included in a standardly included lib, or if gcc included them by default. But that doesn't appear to be the case. As far as anyone has been able to tell me -- any prog needing pthreads still needs to explicitly link libpthread in 11.0. Hey -- question -- when factory is "built", I assume logs of each package built are generated and stored somewhere. Are those logs able to be examined? That might tell me something right there... Thanks for anyone that might know about these issues. linda --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, 23 May 2008 10:30:20 -0700, Linda Walsh wrote:
If build installs different packages from what is using in on one's system, doesn't that make build-built packages less likely to be compatible with one's current system.?
That's why build has an option to specify the location of alternative packages. That's where you put your newly built rpm packages and thus eventually get the complete dependency chains built according to what you use.
There's likely some howto docs -- the main thing I'd likely want to be able to do is point build at my own, local package dirs -- that might contain some custom packages -- so I'd want to be able to (re)generate needed 'Db's.
See above :)
Hey -- question -- when factory is "built", I assume logs of each package built are generated and stored somewhere. Are those logs able to be examined? That might tell me something right there...
With a valid BS account you can look into the build log of packages. Philipp --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Philipp Thomas wrote:
With a valid BS account you can look into the build log of packages.
One thing, that strikes me "uncomfortable", right off the bat.. For better or worse, I often run "rpmbuild" as non-root. Build doesn't allow that -- I'd rather it be like the "CPAN" system, where to do 'installs', a user can 'optionally' set it up to use 'sudo' for the installs. Obviously not so much a 'security concern', but a 'safety/cockpit' concern -- I'm less than human when it comes to absent-mindedness... I *know*, I make dumb mistakes...(and I know others do to, despite their assurances to the contrary). .. but .. just my '4 cents' (or 2 pence... :-)). A valid BS account, eh? ..you need an account to BS these days? (yeah. buildsystem, I know...just it was there...I had to take it...:-) ) Will have to get one of those...I'd really hate to be caught BS'ing without a valid account. ...Linda --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sat, 24 May 2008 16:25:15 -0700, Linda Walsh wrote:
One thing, that strikes me "uncomfortable", right off the bat.. For better or worse, I often run "rpmbuild" as non-root.
Build doesn't allow that
Don't let that mislead you! Build needs to run as root to execute chroot, but most of our spec files have a # norootforbuild at the top and that tells build to not run rpmbuild as root.
A valid BS account, eh? ..you need an account to BS these days? (yeah. buildsystem, I know...just it was there...I had to take it...:-) )
Hadn't thought of that ;-))) Shows that English isn't my native language. Philipp --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Linda Walsh wrote:
Andreas Jaeger wrote:
Are you using the build command?
All I can say is that it builds without problems. Otherwise you would not have a src rpm to look at ;-)
Andreas
I understand, I think, your point -- how did the src rpm get generated if it didn't work.
That's what I'm trying to find out.
I'm using rpmbuild -ba.
I'm doing things that build might not support -- but that *shouldn't* make a difference. If I find something that is making the difference, I want to understand why its failing and correct the problem.
1) My initial purpose was to drain the swamp that had the alligators in it...no. Wait, that was last week.
1a) Initial purpose was to apply high-performance source patches to scp/ssh. Goal -- going from current ~3MB/s up to about 10 times that. Max raw TCP with jumbo packets was over 90MB/s. So I have a bit of headroom to improve on. Max file transfer with normal size packets was ~70+MB/s over UDB (CIFS). I hoped NFS/TCP would do better, but that hasn't been the case so far. Nevertheless, my most common method of xferring files has been scp/ssh. So that's my short-term goal.
The patches were available against 4.7 or 5.0 versions of openssh. suse10.3 has 4.6 in it. I thought I'd have better luck in 'eventual integration into my systems if I started with a suSE rpm -- I prefer packaging my software mods in rpms -- they are usually fairly stable ways of reproducing the software and preserving its source for later.
I checked suse11.0 -- and it is using openssh5.0 -- one of the versions supported by the patchsets. Discovered via trial&error that applying the high-perf patches, Then applying the rest of the suse patches generated fewest conflicts. Only conflict was in a makefile that added suse's libaudit to a link.
So at this point, I'm building across releases 11.0 src rpm on 10.3 with 3rd party patches. Is this something "build" is designed for?
I had one incompatibility in the resulting 11.0 binary that wanted a krb-gssapi routine I wasn't familiar with. I just assumed it might be new in 11.0 -- and I needed it, I'd need to regen those libs, *however* I don't need krb-gssapi, and since that's an optional component when specifying open-ssh's "Configure" options, I removed it.
Now is when I ran into the missing pthread problem. It happens in building a 'subutil' built within the openssh rpm. The openssh.spec builds 2 or 3 separate components -- most recently 'openssh-askpass' was merged (was separate in 10.3). During the change-over, someone removed the pthreads lib from the global LDFLAGS var. While that works for the main prog and the new askpass util, it caused missing libpthread calls in one subpackage.
They actually removed it for the entire package -- and it seems it is only this one subpackage that needs it. There's even a comment in the .spec file that says the "posix threads' defines and -lpthread call were "Obsoleted" -- but no reason saying why. -- So whoever made the change thought they had done something to eliminate the need. Maybe that need is hidden or taken care of by using the build command -- but the downside is that the source rpm no longer can be used to build the rpm stand-alone.
Whether or not 'build' could be used to reproduce the issue, I don't know -- it's certainly alot more setup to rebuild the openssh package -- "-ba" takes about a minute. It doesn't appear that build would be quite so fast -- and I'm not sure about it's flexibility -- but if it is hiding problems that are 'valid' problems in standalone rpmbuild commands, that's troubling and like peculiar.
99. So now as I find myself up to my bum in alligators...(so to speak...) -- trying to figure out why the rpmbuild command isn't working when it "should"...
Am I making sense about why I'm going about and doing things the way I am?
Sorry to stir things up needlessly if things were really fine before...really not sure why it wouldn't work now...just weird.
Linda ...very tired...brain only firing on a few cylinders... so will have to see if I can sleep now (have sporadic sleeplessness...so...of course I get on my computer and do relaxing things like this...:-) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
The best way to find all the dependencies is to enable the factory repo in yast and try to install openssh and note the other packages it wants to install and remove. regards Dave P. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (4)
-
Andreas Jaeger -
Dave Plater -
Linda Walsh -
Philipp Thomas