Mailinglist Archive: opensuse (818 mails)

< Previous Next >
Re: [opensuse] Re: openSUSE build & testing procedure and faulty pruning of builds causing rpmbuild failures
Top-posting because I would be saying essentially the same thing over and over to each of your statements.

(1) The build environment has always affected the build. That same statement is the response to probably half of your statements. It's not new, it's not a problem, it's not some regression in suse. Yes I build lots of stuff both in and out of the rpm or osc systems, and as I mentioned not just on linux even.

(2) You keep saying things that just aren't true. You saying something doesn't work or isn't possible anymore is pointless to keep arguing with. All the same things are _exactly_ as possible as always. I do it all the time. A stock opensuse install IS a sane gcc build environment. The clean system used inside of obs, osc, rpm is nothing but a stock opensuse install.

I think I'll just drop (1) and (2) references to each line below.



On 7/20/2012 2:33 PM, Linda Walsh wrote:
Greg Freemyer wrote:
> On Fri, Jul 20, 2012 at 12:17 AM, Linda Walsh <suse@xxxxxxxxx> wrote:
>> What it *sounds* like is that openSuSE is no longer a development
>> / build environment -- that is supported to work to build it's own
>> RPM's.
> openSUSE has moved to a new build paradigm and you are complaining the
> old one no longer works and you can't use it to build the distro
> pieces.
---

I am complaining that one cannot use a standard suse
distro machine to do a build of the source packages anymore.

(2)

It's not about new and old. I get new versions of compiler make, even
samba uses a python tool instead of configure/make for samba4, but it
still builds on my local OpenSuSE12.1 system.

The source packages from OBS are not robust.

(2)

It is NOT that they don't have requirements listed -- they do -- but
they are requiring something that the rpm build system never provisioned
for...

False.

They are requiring you NOT to have various packages installed *during
the build*, because the build can pick up extra available tools to build
more support or to optimize the build.

(1)

Instead of building packages as they would be build by an installed
distro, they
are building some arbitrary subset that isn't built to work with the entire
distro they ship.

(1)

If that's the case, they should stop shipping those extra packages
and sources and stop pretending that this giant collection of RPMs is all
one compatible distribution.

This doesn't make any sense. It's false in so far as the collection of rpms absolutely does assemble into a single consistent system. so, (2).

It's more important, TO ME, to have a distribution that works together
that I can use to rebuild itself, than to have "bigger numbers" of packages
that I can't really use (but don't know it) because if I do, builds will go
awry.

Gobbledy-gook, and (1) and (2)

> I think this thread (series of threads) have made is clear the core
> set of openSUSE maintianers simply don't care if the old legacy way
> still works or not.
-----------

Several people have mentioned to me that they and others who
no longer post have given up on trying to get their opinions heard, but
that they appreciate my efforts, as it bespeaks to many of the issues they
brought up, attempted to have addressed, and had ignored.

Several people have thanked me for trying to explain the basic facts of life to you too, so let's call that even and forget about trying to make it a popularity contest.

> openSUSE has invested great effort into obs and they are properly
> proud of it. I think OBS is one of the crown jewels of opensuse.
---

Of that I have think no one disagrees -- and that's part of the problem.
If you had such a nice new toy... and someone didn't want to use it, how
well would you respond?

You don't have to use it. (2)

I didn't even ask them *NOT* to use it -- I asked them to
change their 'base system', from a "minimum necessary" (which will NEVER
represent what users have on their machines), to a full development install,
which should catch 90% of the interactions between packages during build
that
can happen to customers -- and allow them to be fixed before they hit
the customer.

Gibberish based on falsehoods (2) and apparently a continuing failure to understand or believe (1)

I know this upsets the 'train schedule' theory of product release, but
sorry, you can't schedule creative efforts like building machines. Each
release
is something that has NEVER been done before. It's never been tried --
never
been put together "exactly this way" -- to expect that you can predict
how long
that is going to take reliable is foolish, wishful thinking.

What? This isn't even intelligible. Or rather, doesn't seem to have any bearing on anything.

How can you predict how long that which has never been done before? One
way is to eliminate all complexity and as many unknowns as possible. You can
do this by NOT creating a distro, but by building a collection of
packages in
isolation from each other -- that when run in a particular way (like a
script),
will give a more specific result. But no longer do you have a
distribution that's
integrated and designed to work together -- but a collection of packages
designed to be run and generated in only certain predictable ways.

That's not a personal computer -- that's an appliance.

EVERY system since the dawn of software had to have a non-trivial level of integration. This argument applies to systemd taking over from from what used to be separate utilities, and running by reading config files instead of executing scripts written in any fully expressive and functional languages you want, but it does not apply to the fact that samba has to know something about the rest of the system in order to function.

What people are talking about is shifting SuSE from a linux-distro
builder to
a linux-appliance builder (or a platform for building linux
appliances). That would
indicate that openSuSE is removing themselves from the linux distro
market, and going
for a niche subset market, while still telling people they are a linux
distro.

I wanna know -- when was the decision made to shift away from being a linux
distro and become an appliance-OS vendor?

I actually agree, but only because of systemd. None of the things you have mentioned in the SLIGHTEST way supports this accusation.
If any of the things you claimed about stuff no longer working were true, maybe, but those claims are false and so all further arguments based on them are fantasy.

Was this made clear to everyone working with opensuse? I didn't
realize it until this set of emails, that this was the most likely
reason, behind the scenes, for
this to occur.... but it makes sense with other projects open Suse has
gotten into.

More goobilygobble?


I could say more, but I want to address your other points...


> The normal way from my perspective to build a package is to checkout a
> local copy of the package from OBS and use "osc build" to build it.
>
> You've argued that since that interacts with OBS it isn't satisfactory.
---

No... checking it out from OBS -- let me use svs/cvs/mercurial/git...
whatever, osc hasn't worked for me yet. Tried yesturday to install more of
those packages and they failed due to the server being down/unreachable.

2012-07-19 14:17:50 <2> Ishtar(2980) [YCP] PackageCallbacks.ycp:2075
Download failed: error 4: File
'./x86_64/obs-server-2.3.3-5.1.x86_64.rpm' not found on medium
'http://download.opensuse.org/repositories/openSUSE:/Tools/openSUSE_12.1/'
2012-07-19 14:19:48 <2> Ishtar(2980) [YCP] PackageCallbacks.ycp:2075
Download failed: error 4: File './x86_64/obs-api-2.3.3-5.1.x86_64.rpm'
not found on medium
'http://download.opensuse.org/repositories/openSUSE:/Tools/openSUSE_12.1/'
2012-07-19 14:23:05 <1> Ishtar(2980) [YCP] PackagesUI.ycp:494
Installation summary:


Package Installation Failed

* Error Message:


Packages

* Failed Packages: 2
obs-api, obs-server
* Installed Packages: 93
MozillaThunderbird, apache2-mod_xforward, augeas, dbus-1-glib-doc,
deltarpm, enblend-enfuse, flash-player-gnome, flash-player-kde4...
(more) <installed_packages>
* Removed Packages: 1
esound-daemon


Statistics

* Elapsed Time: 03:04
* Total Installed Size: 152.38 MB
* Total Downloaded Size: 4.89 MB


Details

* Installation log <install_log>
* Post-Installation log (SUSEconfig) <postinstall_log>


Note -- despite my posts here, I am still trying to make progress on
multiple
fronts, -- including installing the recommended osc packages, which, as
you can
tell from yesterday's summary, failed.

>
> It is untested for me but working with a source tarball this should
> work in isolation from OBS.
>
> mkdir ~/osc
> mkdir ~/osc/my_local_projects
> cd ~/osc/my_local_projects
> osc importsrcpkg <source rpm> --local-package
> cd <package>
> osc build --local-package

I read in the manpage that the above says it builds locally. So how
about it giving
the option of producing a shell script that can be run -- since, the
above looks like
you are running the "local build" through a remote osc session -- will
this work
when you are not connected online (for example)? (or if osc is down? or
you have
no working osc connection?)

osc requires an api connection to an osc server. You CAN actually install your own full obs server since not only is obs open source, they even provide live dvd's of it preloaded, but, it is a bit non-trivial to get your own obs server actually running. So normally, osc requires a connection to suse's obs server mostly just to download build requirements. You can cache the full build targets and not need any further connection after that.

But, you don't actually need osc either. It's by far a convenience once you get it working, but it's just a convenience.

So, no you don't need any external connection. You would need to download the full distro of binary, noarch, and src rpms together one time, but after that you are missing nothing. opensuse could disappear and you could rebuild every single thing.

If you want to scrap all this thread and get back to just building samba (or whatever) I'm sure you can get some help, I might even, but I for one am not interested in trying to debug your installed system from these complaints that amount to "I ran this command and it should have all just worked and it didn't so that means suse isn't a linux distro"

Debugging the problem is as always a tedious process of halving the job one part at a time to eventually zero in on the cause. It's already tedious enough just normally under the ideal conditions. Embedded in this thread it's completely untenable and thankless.


> I do have confidence that if you drop the --local-package options and
> assuming you have your OBS account initialized (by logging into OBS
> one time) and you have internet access then something like the above
> will work except it is more like:

The idea of a local build is so that once you have the sources
downloaded, you
don't have to be on the internet.

Of course. But you may need any number of other packages to support building the one package you want. osc will fetch them all automatically on-demand. You can cache them all ahead of time by a few different methods so that you should never need the connection again unless you intentionally want to pull updates or add more repos.

> You may not like the new workflow, but to argue openSUSE has lost the
> ability to build packages locally is simply false. It is just that
> opensuse has moved to a new paradigm and you are still using the old
> one.

The new system uses rpmbuild as well, I'm told --
So what directory do I 'cd' to and run my rpmbuild command?

THIS is a far more productive conversation. I suggest we start it in a new thread, or possibly re-start it here and scrap all old quotes?

rpmbuild doesn't care what directory you are sitting in when you run rpmbuild.

It will create things under /usr/src, but you can be standing anywhere yourself when you run it. There are lot's of ways to run it so you could rpmbuild an src.rpm file (could be anywhere also) or you could rpmbuild a spec file which could also be anywhere, but would normally expect the rest of the sources and patches to be in /usr/src/RPM/SOURCES that would have normally been in the src.rpm.

Maybe it would be better to start with a simpler package than samba?
Would you be interested in working up to samba by first establishing that rpmbuild itself has all it's requirements installed and can build something simple, possibly having to back up and debug that if not?

--
bkw
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >