December 2013 - openSUSE Factory - openSUSE Mailing Lists

[opensuse-factory] Re: zypper dup 12.2 -> 13.1 fail
by Jim Henderson 09 Dec '13

09 Dec '13

On Mon, 09 Dec 2013 02:27:44 +0100, Carlos E. R. wrote: >> I spent the better part of 3 hours trying to get it working, and in the >> end, I decided there was some old cruft on the system that was probably >> causing problems, and I could have spent another day trying to get it >> to work, or I could just install / from scratch and have a clean setup. >> I opted for the latter. > > There are two kinds of cruft after a system upgrade. Three, but OK. > * One, is that as the DVD is too small to contain the full oss repo, a > lot is missing. So you have to do after it: Well, yes, or if you've installed software from other sources that's not compatible with the new libraries, etc. Or if you have lots of repos configured (as I have done in the past). > * The second issue is stale config files. If you run "rcrpmconfigcheck" > you get a list of config files to check. Even on normal updates you get > them: I back those up regardless of how I do an upgrade. Better to be safe than sorry. This time around, I missed user cron jobs. Ah well, nothing overly complex in them, so recreating them isn't a problem. Third kind of cruft, BTW - are those things that are installed from unofficial sources. To each his own - I prefer doing a clean install every now and then regardless of the OS. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 3

[opensuse-factory] armvl build finished since Dec. 3rd but still in status "scheduled"
by Bernhard Voelker 09 Dec '13

09 Dec '13

An 'armvl' build finished 3 days ago [1]: [ 605s] armbuild13 finished "build coreutils.spec" at Tue Dec 3 22:59:53 UTC 2013. but the status is still "scheduled" [2]. [1] https://build.opensuse.org/package/live_build_log/Base:System/coreutils/ope… [2] https://build.opensuse.org/package/show/Base:System/coreutils Why? Thanks & have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 1

[opensuse-factory] Apache config changes needed
by Christian Boltz 07 Dec '13

07 Dec '13

Hello, if you are updating to the latest Apache packages from Factory, you'll get a "Forbidden" error, and the log contains: AH01630: client denied by server configuration This is probably caused by * Mo Nov 04 2013 freek(a)opensuse.org - Removed obsolete directive DefaultType - Changed all access control to new Require directive The solution is to replace Order allow,deny Allow from all with Require all granted in the apache config. This change is needed even if the access_compat module is loaded [1] :-( Freek, was this an intentional change, or something we should call a bug? ;-) Regards, Christian Boltz [1] APACHE_MODULES="actions alias auth_basic authz_host authz_groupfile authz_user authn_dbm autoindex cgi dir env expires include log_config mime negotiation setenvif ssl suexec userdir php5 rewrite proxy proxy_http reqtimeout unixd access_compat authz_core systemd authn_core" -- Maybe the next openSUSE conference should have a mandatory group hug after all... ;-) [Jos Poortvliet in opensuse-factory] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 9

[opensuse-factory] openQA in the new proposal
by Alberto Planas Dominguez 07 Dec '13

07 Dec '13

Hello list, as outlined in the mail sent by coolo last Thursday, the current approach of having openQA only run after Factory emits an ISO image does not prevent Factory from getting broken. Problems can only be detected when it's basically already too late. Therefore coolo's mail proposed this workflow that strengthens openQA's importance by including pre-integration tests in the Factory submission process. https://progress.opensuse.org/workflow/factory-proposal.html That mode of operation adds new requirements on openQA. In no particular order of importance: 1. Accessible In order to allow Factory and staging project maintainers to evaluate and fix test runs openQA's web interface needs to be enhanced to work with multiple users. That means introducing an actual web framework instead of using CGI.pm, introducing a proper database backend, coming up with a permissions model, etc. Also, there needs to be a way to allow users to edit test cases. Right now one has to do that outside of the tool via direct git access. Fulfilling this requirement is basically precondition for hosting openQA in public, ie needed for full upstream acceptance. 2. Reliable In it's current state openQA needs constant care taking by an operator with root access. Way too often jobs get stuck or fail in an unpredictable way. Many times the reasons for that are deadlocks in the threading model, issues with the monitor interface of QEMU, race conditions that depend on the load and disk IO or side effects of tests. Effort needs to be put into eliminating random failures by e.g. avoiding Perl threads, enhancing QEMU's QMP interface, avoiding sleep() or leveraging VM snapshots in a smarter way. 3. Scalable openQA already is able to run several QEMU instances on one machine. There are natural limits on the amount of RAM and CPU of affordable machines though. So even the fastest machine seen so far can only run eight installations in parallel. To be able to run both Factory tests as well as pre-integration tests projects in a reasonable amount of time openQA needs to be parallelized to run on several machines. The way OBS uses workers can serve as inspiration here. This feature requires implementing smart ways to distribute input files like test scripts, reference images, RPMs or ISO images among workers. It requires a database model that allows live updating of test results and a new way to provide the back channel for the live view. 4. Debuggable Sometimes tests just fail in a way that is not debuggable after the fact. Therefore there needs to be a mode that allows developers to interactively take control of the virtual machine that runs the test. If that doesn't help either, there should be a way to clone jobs to a local instance to reproduce it there. 5. Interfacable So far openQA test results are meant to be interpreted by humans. To be able to serve as good input for automatically judging whether a staging project is good enough, the results must be available in a way for the machine to understand. E.g. for displaying test results directly in OBS projects. To implement the listed features, several man months of concentrated development effort would be needed. p.s The original author of this email is Ludwig Nussel, but I edited it a bit before sending. That means that the good parts are from him, and the mistakes are mine. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 4

[opensuse-factory] Update to 13.1 = total fail
by Ilya Chernykh 07 Dec '13

07 Dec '13

I have tried to upgrade to 13.1. After an install I got a pure Grub prompt. I found an old 11.4 LiveDVD and tried to repair and re-install grub, unsuccessfully. Then installed grub2 and os-prober packages via chroot, executed grub2-install. The grub still did not boot asking for "directory". I gave an ad-hoc name and it asked for a file modinfo.sh. Via google I found it to be in grub2-i386-pc package. I installed it via chroot. The system booted up, first and last time. The video was working only in 2D mode. I made the following changes: removed package grub (because there was already grub2), removed nvidia g02 drivers (because they anyway do not support my card), changed the grub2 wait time from 10 to 2 seconds via yast, made zypper up. The internet connection disappeared somewhat 5 minutes from boot and could not be restored. I decided to reboot. The system did not boot any more. After the message about successful mounting of the root file system the booting stopped. The last messages were cut off so I could not guess the cause. I booted from the live DVD and in chroot tried to reverse the last changes. Re-installed grub, the g02 drivers, restored the grub settings from the file grub.old. This did not help. Then I re-installed grub2 several times, changed the kernel to different versions - from 3.11 to 3.7 and 3.4, variants from desktop to default and vanilla. No effect. So I googled the kernel boot options so to chnge the video mode at boot. So I set up the low-res text mode in grub2 so that the messages were not cut. The message was "Error loading shared libraries libwrap.so.0. Not synchronized. Attempted to kill init. Kernel panic". I found that libwrap.so.0 file is in the package tcpd. I re-installed this package, but wihout effect. I also tred to change the mount options of the root filesystem in fstab (the root file system is ext4), but again this did not help. So I decided to roll back. The chroot environment could not resolve host names so I added the Google DNS 8.8.8.8 to the config file. Then I started to update tho the previous release. In the course of update some packages were hanging on scripts so I had to interrupt zypper. After one such interrupt zypper refused to start again due to incorrect glib version. So I downloaded libzypp and zypper via wget and installed with rpm -i --force. After that the installation completed. I was again met with grub prompt, but made grub2-install and the system booted in text mode. I installed the nvidia drivers and it booted successfully. So this is the system I use currently. I think all these operations are not well suitable to an average user. I also have no idea on how to make 13.1 to work. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

8 15

[opensuse-factory] yast2-http-server no longer usable with apache 2.4 in openSUSE 13.1 and Factory
by Freek de Kruijf 05 Dec '13

05 Dec '13

With the appearance of apache2 version 2.4 in openSUSE 13.1 and Factory. the module yast2-http-server is no longer usable. I studied the ruby code, but I don't think I will be able to adopt it to the requirements of apache2 2.4, without putting a lot of effort in it, but it will take too long time to complete. I have a general idea about what needs to be changed, so when there is somebody who is knowledgeable in ruby and in the details of how a yast2 module must be made, I can give directions on what the module needs to do. This all is under the condition that the community has a need for such a module. -- fr.gr. Freek de Kruijf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

7 8

[opensuse-factory] may coreutils soon need libcrypto?
by Bernhard Voelker 05 Dec '13

05 Dec '13

Hi ... maybe Coolo? The next coreutils release is coming out in a few days. Besides many other changes, it comes with a performance boost for the md5sum + sha*sum programs up to 50% due to now linking against "openssl" (per default). This is cool per se, but I see potential new build cycles: $ ldd /usr/bin/md5sum md5sum-new /usr/bin/md5sum: linux-vdso.so.1 (0x00007fffdc520000) libc.so.6 => /lib64/libc.so.6 (0x00007f4c917aa000) /lib64/ld-linux-x86-64.so.2 (0x00007f4c91b59000) md5sum-new: linux-vdso.so.1 (0x00007fff457fe000) libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0 (0x00007f33b0603000) libc.so.6 => /lib64/libc.so.6 (0x00007f33b0254000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f33b0050000) libz.so.1 => /lib64/libz.so.1 (0x00007f33afe3a000) /lib64/ld-linux-x86-64.so.2 (0x00007f33b09ee000) Should I use that new default setting, or should I configure --with-openssl=no ? Thanks & have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 8

[opensuse-factory] Suse on a Raspberry Pi
by gm1mqe＠aol.com 04 Dec '13

04 Dec '13

All you need to do is go here! http://zq1.de/~bernhard/linux/opensuse/ Andy Norrie -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 4

[opensuse-factory] Short term staging projects [WAS: One of the options for staging projects]
by Greg Freemyer 03 Dec '13

03 Dec '13

On Tue, Dec 3, 2013 at 10:30 AM, Michal Hrusecky <mhrusecky(a)suse.cz> wrote: > Greg Freemyer - 9:34 3.12.13 wrote: > From here > >> --- create short term staging project - A BtrFS read/write snapshot of >> factory is created. This should only take a couple seconds >> >> --- Update the affected packages based on the SR / SR batch - I assume >> a few more seconds >> >> --- Run the build logic and build the updated packages and anything >> that depends on them - this is the time consumer, put hopefully this >> class of build can be given top priority. > > to here we don't need special workflow as it would be handled by OBS > >> --- If no build errors, forward original SR / SR batch to factory >> reviewers and destroy BtrFS snapshot. >> >> --- if build errors, hoover up the build logs from all the builds and >> attach them to the SR, reject the SR, and destroy the BtrFS snapshot. >> >> If the above is totally automated, it seems the BtrFS snapshot may >> only live for a an hour or less typically. >> >> With that process it seems the overhead of creating a staging projects >> is minimal and even single package SRs of leaf packages could be run >> through a quick staging compile / dependency compile. >> === > > Not a good idea to hack a new OBS from scratches living next to the official > one. And I don't see what should be the difference between the short term and > long term ones. Short ones are rejected right away without striving for > solution in staging? I'm not proposing a new OBS. I'm proposing the short term staging projects be created via BtrFS snapshots. I don't know how OBS manages the data, but I assuming it is on a different filesystem instance than the OBS application software. I guess I left the design goal in my head. I'm not expert with BtrFS, but I've been a storage engineer in my past and at least with other snapshot creating technologies I've worked with you had to design the implementation around the storage technology. As to the possibility of most SRs create a staging projects, that has 2 fundamental problems from my possibly naive perspective: - a human seems to be required in the process described so far. If most SRs are to be staged in some way, then for the vast majority of the SRs the whole thing from creation to destruction needs to be automated. The long term staging projects on the other hand are designed for human interaction. - Having dozens/hundreds of BtrFS snapshots in use simultaneously for a significant duration is probably a horrendous idea. It is much better to use linked packages in all likelihood. Thus it makes sense (to me) to treat the 2 use cases as separate with different goals and technical solutions: ======= short term staging projects ======== Goals: - Identify SRs that have BuildRequired dependencies in the devel project, but not in factory - Identify SRs that break other packages in factory that are not in the devel project. - For successful SRs, neither the submitter nor the factory reviewer should see any additional workload as compared to the current process - Must be very fast / efficient to create, execute, and destroy the staging project and totally automated. Technical assumption: - creating a staging project with 6,000 linked packages is slow / inefficient from a storage resource perspective - creating a staging project via a BtrFS snapshot is fast / efficient from a storage resource perspective Proposed solution: create a new SR automated workflow that uses BtrFS snapshots to - create a staging project, - runs the test builds - collect results - destroy the staging project. >> -- How many "leaf" SRs per day are there anyway? > > No idea. > >> -- How many simultaneous BtrFS snapshots can exist and still get >> reasonable performance? > > No idea and doesn't matter. It does for the proposal I made. >> --- If one assumes 10 simultaneous BtrFS snapshots is reasonable to >> maintain, then a queue could be established to push leaf package >> staging projects through. If the average leaf staging project lives >> for 1 hour, then that's 240 SR / SR batches per day that could be >> treated this way.. >> > > Scheduling, building takes some time, there are other stuff, overall I think > that we don't need staging for everything (although it might be nice). Agreed that it is a nicety. When it was first proposed, my first thought was no way. Just the effort of creating all those staging projects would be rediculous. Then I thought about how efficient it would be to use BtrFS snapshots for that step and I changed my mind. > -- > Michal HRUSECKY SUSE LINUX, s.r.o. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 4

[opensuse-factory] RE: [Bug 847971] Chromium from openSUSE has MP3/MP4 support
by Ignacio Areta 03 Dec '13

03 Dec '13

Oh sorry, you understood (and I too). So, let's redo the story. (= This is a little strange. Recently, you changed the package to add protobuf dependency. This is a major change, isn't it? In the last year, you moved Chromium to Packman because of FFMpeg. At that time, Chromium was shipped without FFMpeg. Some days after doing this, you moved these packages back to openSUSE after discovering a method to compile Chromium's FFMpeg only with free codecs support. Then was born the chromium-ffmpegsumo package. Support to the the proprietary codecs weren't in openSUSE's package beacause as we know, these formats has issues with patents in some countries. Right? People, now this isn't working properly, because chromium-ffmpegsumo is reproducing MP3/MP4. The chromium.spec has these two lines: -Dproprietary_codecs=1 -Dffmpeg_branding=Chrome According to the Chromium's wiki ( www.chromium.org/audio-video ) the use of these 2 build flags activates the support for the proprietary formats. I think the way to fix this is changing these values to 0 and Chromium, respectively. Any other idea? Regards, Ignacio PS: Raymond, I forgot to subscribing to the list, so I can't reply your email directly. PS2: sorry for the 6th paragraph in the comment 1 of the bug. I used the wrong words. >Thanks for making me look stupid and that I do not understand the issue. The >reason why I asked you to write to this mailinglist was your statement that >Chromium should be build without the proprietary-codec and branding=chrome >options. This would mean that Chromium no longer would support H.264, MP4, etc >codecs that normally are supported by Chrome. As that this is a major change, >I asked you to validate this on this mailinglist. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

12 28