July 2012 - openSUSE Users - openSUSE Mailing Lists

[opensuse] Re: openSUSE build & testing procedure and faulty pruning of builds causing rpmbuild failures
by Linda Walsh 21 Jul '12

21 Jul '12

Brian K. White wrote > > To end on some shred of a positive note, I bet despite all this, if you > wanted, you would still probably get help figuring out what YOU are > getting wrong and get your package built and even show you the real > answer to any questions you have about how gpl is preserved at all > points along the way, if you asked that way. > ---- You apparently missed the part about the samba problems being resolved and that samba built just fine -- I had no problem with that part... But this part: > Using osc or rpmbuild are just conveniences. --- Open suse builds using this. If you have things installed, like the package you just built (the devel packages in the samba.spec file, in particular), then there is a bug in the spec file used by rpmbuild. Tries to build full support for everything you have installed. This includes support for the samba database tools ldb, and tdb (and their man pages). If you have those devel packages installed, the manpages are installed, (as one example of failure), and the build fails due to the build root having unexpected files produced. In another instance, the presence of the devel package for ldb (I think), led to the ldb tools being installed in the place where binaries get installed rather than a subdir. So again, the spec file fails because it tries to delete the tools out of (check my previous postings -- ) /usr/lib64/ldb/...when the tools they want to delete are in /usr/lib64. None of these issues are caused by my not knowing how to build -- but are caused by trying to build only parts of the normal samba package and delete others. The presence (installation) of the packages just built would trigger the parts in the script to install supporting files. By building in a sterile env, you don't get the same behavior as when you build those tools from a tarball. The normal tarball works, it's the sterilization code that was functioning improperly. So you are right, it's about my ignorance of a suse-specific build-system that is required to build suse packages. It's not even about rpmbuild (though it uses the spec file that doesn't "prune" the package corrrectly. If OS took the easy route and didn't try to delete files that would normally be installed, this problem wouldn't have happened. This is why I recommend suse build on systems that they support --- those installed with the release (or prior release) and that have devel packages associated with the product they are building installed. That's easily a normal expectation -- that suse requires the devel packages of the product you are building NOT to be installed goes against all standard software practice. imagine having to uninstall the linux kernel or sources before you generate it? Would that make sense? Then why should I expect devel packages in samba would cause a problem in building it? But you are right ... I'm not educated about these new fangled build procedures. There's always new stuff that I don't know... but that's why we have society and customs -- which include established ways of doing things. If you rewrite the rules at every release, of course you can claim they are ignorant - as you've violated normal and/or customary expectations. But you get to be right. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

3 2

Re: [opensuse] Re: openSUSE build & testing procedure and faulty pruning of builds causing rpmbuild failures
by Brian K. White 20 Jul '12

20 Jul '12

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(a)tlinx.org> 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(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

1 0

[opensuse] ext4 vs btrfs
by Hans Witvliet 20 Jul '12

20 Jul '12

Hi all, I was wondering when should one choose ext4 and when btrfs... Ofcourse i've googling for it, but in some comparisons they only measure throughput in general. I agree that _is_ important, but i presume other factors also play a role... When dealing with config files (in "/etc/.." or so) it is probably very handy to be able to do a roll-back. But when dealing with a large collection of ISO's ? Or when doing a local mirror? In that case one isn't interested in the possibility of a roll-back. But more in general overhead caused by intermediate inodes and so-on. And i presume that having mbox on btrfs isn't a good idea either. Any bright idea's when to use what FS? Hans -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

11 15

[opensuse] STL c++ - what is wrong with private declaration 'void addSources(const std::list<Source*>& inList);'
by David C. Rankin 20 Jul '12

20 Jul '12

c++ gurus, All, I am having fits with a new gcc'ism (4.7.1) throwing and error on a STL declaration that I cannot figure out. The source is TDE/kima and the error is: In file included from kima.moc.cpp:9:0: ./kima.h:179:24: error: 'list' in namespace 'std' does not name a type ./kima.h:179:29: warning: ISO C++ forbids declaration of 'parameter' with no type [-fpermissive] ./kima.h:179:33: error: expected ',' or '...' before '<' token I have put the header file up at: http://www.3111skyline.com/dl/dt/tde/err/kima/kima.h.txt The primary "error: 'list' in namespace 'std' does not name a type" seems like it would have an easy fix of the type http://www.cplusplus.com/forum/beginner/51696/ but it is already in the proper form/syntax/semantics, etc.. The error implies that somehow that list isn't namespace qualified, but it is. It is like gcc/glibc doesn't know what a STL list is any more. Anybody have a take on this one. It's probably simple, but I can't find it :) -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

1 1

[opensuse] Changing Yast behaviour
by eddie 19 Jul '12

19 Jul '12

I decided to try out mplayer2. There was also mplayer2-as-mplayer which adds "mplayer" symbolic links to mplayer2. When installing these two, I noticed that get_iplayer which has a mplayer dependency was also removed. When I tried to reinstall get_iplayer not only did it fail because it could not find mplayer but all other successful downloads where not installed also. The action of Yast not to install all other packages because one fails I find extremely annoying. Is there a way the to counter this action? I can understand why some may think this is a good idea but I honestly hate it. If one program fails to download it is enough just to be informed about it so that I can seek a solution but to stop all other installations whether or not they are related to the failed download is really not necessary and irritating. I have managed to install get_iplayer without mplayer and it works fine. However, everytime I start Yast it nags that there is a dependency issue with get_iplayer. Is there a way to turn this off too? Any help on how to change the behaviour of Yast would be greatly appreciated. Thanks Eddie -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

3 4

[opensuse] Open SuSE 11.4
by Carl Spitzer 19 Jul '12

19 Jul '12

at the login screen in the lower left corner there are two items: "Secession Type" and "Menu" and no mention on www.opensuse.com how to edit the first one. I have both kde4.x and the better KDE 3.5.10 and wish to add my choice to the Secession Type menu. I found nothing on the web either on this. Where do I find this item and edit it?? CWSIV -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

2 1

[opensuse] Wrong colours in flash videos viewed in Firefox 10.0.3
by Rodney Baker 19 Jul '12

19 Jul '12

Hi all. Running Firefox 10.0.3, flash player 11.2.202.236-17.1. Red and blue are swapped for video playback on web pages (esp. YouTube) in Firefox. Yes, I do mean that - red and blue are swapped. Whatever is supposed to be blue shows as red and vice versa (with corresponding effects on other colours containing either red or blue. The only colours not affected are purple (128,0,128) and green (0,255,0). They're fine in google chrome. NVidia GeForce 9400GT running the NVidia driver version 290.10 on kernel 3.1.0. Has anyone else seen this? Any suggestions (other than sticking to chrome for youtube etc.)? Thanks in advance, Rodney. -- ========================================================================== Rodney Baker VK5ZTV rodney.baker(a)iinet.net.au ========================================================================== -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

2 2

[opensuse] Re: openSUSE flaunting GPL
by Linda Walsh 18 Jul '12

18 Jul '12

Malcolm wrote: > > rpmbuild is not supported as far as I know, use osc and OBS..... --- They do not comply with the GPL -- they require accounts and off-machine "permissions" (i.e. a form of "licensing") to build...and do not support a local build. Besides the fact that they don't easily install and did not install under 11.4 and have not installed under 12.1. Apparently I don't have the correct extra -required- proprietary information needed to build those packages. That's violates the GPL. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

6 7

[opensuse] openSUSE flaunting GPL
by Linda Walsh 18 Jul '12

18 Jul '12

Seems like openSUSE doesn't bother to include sources anymore for building their packages. Since no one seem to care about the bug in the spec-file for samba-3.6.3 causing it's build to fail, the fact that perl5.14.2 doesn't build is become evidence of a pattern. The spec file has a requirement on a package 'db-devel', yet there is no such package. Presumably it would include the necessary /usr/include/db.h file that defines the dbm_open call needed for perl5 to build as well. Doesn't this violate the GPL that allows suse's software to be licensed under the GPL? -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

3 4

[opensuse] oracle VirtualBox backup
by lynn 18 Jul '12

18 Jul '12

12.1 with vb 4.1.18 Hi everyone Backing up a 16GB vdi to USB via rsync takes over 30 minutes, even though I have changed only one file within the VM. I realise the VM is one file, but is there a way of syncing it without doing the whole vdi each time? L x -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

12 22