July 2013

[opensuse-factory] /boot partition is too small when you selected "Create LVM Based Proposal"in "Suggested Partitioning" on installer .
by 1xx 15 Sep '13

15 Sep '13

Hi all . When I selected "Create LVM Based Proposal" in "Suggested Partitioning" on installer, Installer suggested "Create boot volume /dev/sda1 (156.88 MB)" . But it is too small for for updating the kernel . The present state is as follows. Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 154691 108188 38516 74% /boot rpm -qa 'kernel-desktop' kernel-desktop-3.7.10-1.16.1.x86_64 kernel-desktop-3.7.10-1.11.1.x86_64 Disk storage … [View More]

23 47

[opensuse-factory] openqa/factory lamp testing question
by doiggl＠velocitynet.com.au 19 Aug '13

19 Aug '13

Hello, I have a openqa/factory question:Perhaps for Bernhard. Can a test LAMP[1] be included in the openqa tests,to test the lamp software stack works with some software which uses all these components, see example see[2], The install output listed at[3] I have not tested the configuration settings yet as I have not been able to get apache2 part going yet. Thanks Glenn [1] definition Linux (operating system), Apache HTTP Server, MySQL (database software), and PHP, Perl or Python http://en.… [View More]wikipedia.org/wiki/LAMP_%28software_bundle%29 [2] LAMP_setup and software setup - http://en.opensuse.org/SDB:LAMP_setup - http://en.opensuse.org/Cacti changed/updated instructions to suit newer version of cacti. zypper ar http://download.opensuse.org/repositories/server:/monitoring/openSUSE_Facto… server:monitoring zypper in cacti cacti-plugin-autom8 cacti-plugin-boost cacti-plugin-clog cacti-plugin-cycle cacti-plugin-discovery cacti-plugin-docs cacti-plugin-flowview cacti-plugin-hostinfo cacti-plugin-loginmod cacti-plugin-mactrack cacti-plugin-monitor cacti-plugin-npc cacti-plugin-ntop cacti-plugin-realtime cacti-plugin-routerconfigs cacti-plugin-settings cacti-plugin-ssl cacti-plugin-syslog cacti-plugin-thold cacti-plugin-tools cacti-plugin-update cacti-plugin-weathermap [3] install output Loading repository data.. Reading installed packages.. Resolving package dependencies.. The following NEW packages are going to be installed: cacti cacti-plugin-autom8 cacti-plugin-boost cacti-plugin-clog cacti-plugin-cycle cacti-plugin-discovery cacti-plugin-docs cacti-plugin-flowview cacti-plugin-hostinfo cacti-plugin-loginmod cacti-plugin-mactrack cacti-plugin-monitor cacti-plugin-npc cacti-plugin-ntop cacti-plugin-realtime cacti-plugin-routerconfigs cacti-plugin-settings cacti-plugin-ssl cacti-plugin-syslog cacti-plugin-thold cacti-plugin-tools cacti-plugin-update 22 new packages to install. Overall download size: 7.7 MiB. After the operation, additional 22.5 MiB will be used. Continue? [y/n/?] (y): Retrieving package cacti-0.8.8a-14.2.noarch Installing: cacti-plugin-boost-5.1-2.3 ............................................................[done] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org [View Less]

9 14

[opensuse-factory] Qt5 and openSUSE
by Luca Beltrame 11 Aug '13

11 Aug '13

Hello, Qt 5.0 was released quite a while ago: the currently available version is Qt 5.1, with 5.2 on the horizon. In parallel, KDE Frameworks 5 development (KF5) has been slowly picking up steam. Given that: - Qt5 is incompatible with Qt4; - KF5 won't be released for a while; - Qt5 programs are also starting to appear; - We cannot overwrite people's installed Qt4; it would be very wise to have Qt5 co-installable with Qt4. It's not like people have been idle: shumski made quite an effort … [View More]

7 11

[opensuse-factory] On kmod-compat replacing m-i-t
by Jan Engelhardt 08 Aug '13

08 Aug '13

Currently, the only package that still blocks the removal of module-init-tools from a system is the kernel rpm package, with an express dependency "module-init-tools >= 3.4". What is so particular about m-i-t 3.4? Can it be replaced by modutils, or do we need to add some virtual Provides: mitmagic34 to both module-init-tools.spec and kmod-compat.spec? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

5 8

[opensuse-factory] unify ca-certificates installations
by Ruediger Meier 05 Aug '13

05 Aug '13

Hi, today I wanted to install globally a custom ca-certificate (actually just the ca-certificates-cacert rpm package). I found that it's a bit annoying that this is not easily possible since different programs are using different paths to look for ca certificates and we have a lot duplicated certs installed For example we have some packages giving us some certificates ca-certificates-mozilla: /usr/share/ca-certificates/mozilla/ kdelibs3: /opt/kde3/share/apps/kssl/ca-bundle.crt kdelibs4:… [View More]

4 19

[opensuse-factory] password behavior too nuts to file a bug - yet
by Felix Miata 03 Aug '13

03 Aug '13

I started to file the following as a bug, but seems like I must be missing something: Summary: passwordless and null password account logins rejected (KDE3 and vttys) Systems: both 12.3 & 13.1M2 on both i586 and x86_64 Comments: To reproduce: 1-install minimal X normally but without creating any regular user(s) 2-set grub cmdline(s) to include 3 parameter 3-set solver.onlyRequires=true in /etc/zypp.conf 4-install minimalist via zypper and set default KDM/KDE (3 and/or 4) 5-create group … [View More]

2 4

[opensuse-factory] Fiddling with our development model
by Robert Schweikert 03 Aug '13

03 Aug '13

Hi all, This is NOT board intervention, this is just me ;) While at present things appear to be reasonably smooth sailing some (including me) think that there is trouble brewing. Thus, before things move into a more troublesome direction it is probably a good thing to think about changes that could avoid wreckage. Behind the "smooth sailing" appearance is a ton of work that is ever increasing and getting ever more complex. The current push model leads to problems we experience every … [View More]time a new gcc version shows up, a bunch of stuff breaks and only 2 or 3 people fix things. While the use of staging projects "hides" the problems from Factory users, the problems remain the same. The work for the most part, ends up with the release team as they are the integrators. Partially the behavior of non release team members is understandable as for the most part getting your package build broken by others is annoying at best, and it generally happens at an inconvenient time. Partially the problem may also be that people plain and simply do not get the information about their package being broken in factory. With this as a short background I'd like to propose a change in development model for our beloved distribution. Everything needs a catchy title, thus I'll call it "Integration of independently released components with pull option", very catchy I know ;) . The idea is that we define components, this is going to be a chunk of work, and for each component we define it's dependencies. The component model is not set in stone and would get refined over time to reduce potential overlap and improve interoperability. A component is developed by a team and you can think of a component as a "mini factory replica" (factory as we know it today.) The component team works on releases of their component according to some common and some component specific guidelines we'd have to define and publish. Any component consists of one or more packages and may get fed by devel projects or development may take place in component branches. Each component advances based on it's own release cycle and the component team decides which release of it's dependent components to build against. Some tooling will be needed to help sort out the combinatorial problem. How does this work in more concrete terms? Lets say we have a "Core" component that includes the kernel, glibc, the toolchain and a few other things, but no fluff ;) . This component then gets released every time a new kernel is released and every time a new gcc or glibc are released, or based on some other criteria the core team determines and publishes. Every release gets a number. When a new release of the core component happens nothing breaks because by default nothing builds against the new release yet. Component teams higher up the stack decide against which release of a dependent component they want to build. This puts the "adopt a new toolchain" decision into the court of the component teams rather than having it in the realm of the release team, i.e. the integrators, or the realm of the toolchain team. Therefore, a component team decides on it's time scale when to build against a new release of a dependent component. This concept works whether a given component depends on one or many other components. Obviously there needs to be some notification mechanism that lets dependent component owners know when a new release of one of their dependent components is available. There also needs to be some tagging mechanism for releases and other mechanisms of notification and tracking. A simple example: Lets say component A depends on component B. Component A is released as version 1 (A-1) and component B is also released as version 1 (B-1). Now component team B decides to have release number 2 (B-2) and thus component team A gets notified. Component team A can now create a branch of component A and start building against B-2. If the changes to get A-1 to build against B-2 are trivial and A-1 can work with both B-1 and B-2, component team A merges the changes back from the branch and tags A-1 as working with B-1 and B-2. If the changes to A are extensive component team A may decide to have a new release, tag it as release 2 (A-2) and tag it to be working with B-1 and B-2 or only with B-2 if that is the case. These same principles apply for components with multiple dependencies, with the caveat that things get a bit more complex, still less cumbersome of course than the battles the release team has to fight day in and day out in today's model. This change does imply the end of factory as we know it today. Factory may be "empty" for a good chunk of the release cycle. The replacement for "living on the edge" developers is a set of component selections that can keep you in "alpha mode" all the time. When a release approaches,the release team picks a version of the core component that will be the base for the next openSUSE release. This version is used to populate factory and may be the only component that is in factory for a little while. As other component teams integrate and build against the version of their dependencies that end up in factory and make their own component releases the openSUSE release team can fill factory by pulling more and more per-integrated components. With things per-integrated at the released component level the work of the openSUSE release team becomes easier and sustainable. The underlying assumption is that component teams have an interest in having their component be part of the openSUSE release and thus component teams will have an interest in building against new releases of dependent components. This underlying assumption is not much different from today's. What do we gain from all of this? Interesting work of course ;) , but we also switch to a model that is sustainable in the long run. I am not the only one arguing that the work the release team is doing in its present form cannot be sustained with a growing distribution. The work has to be distributed in some way, and more people doing the same thing that is being done today is probably not the answer. We also gain a unique and interesting development model, that with some additional tooling will allow developers to generate a distribution that is tailored to exactly their need. This in turn should stir interest give us some nice publicity and help us find more fingers on the keyboard to help grow the developer community and with it the distribution. With the independent release of components one can easily imagine an interface where a developer picks a component at a given release level, gets choices of versions of dependent components to select and so on. In the end we can relatively easily generate a tailored "release". This also works the other way around, pick a released version of the core and the interface shows you other components that match this core and so on up the stack. Lots of work, yes, but in the long run we have to make some changes. Thus, the sooner we start the easier it will be. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei(a)suse.com rschweik(a)ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org [View Less]

24 70

[opensuse-factory] Intel video driver artifacts after resume with Tumbleweed kernel
by Ronan Arraes Jardim Chagas 02 Aug '13

02 Aug '13

Hi, I'm using OpenSUSE Tumbleweed with latest kernel (3.10.0-16.g3dcd746-desktop). After the last update, when I resume the computer from a hibernation, I see lots of artifacts on screen. Most of them disappear when the screen is redraw, but some are only fixed by restarting X. Is anyone having the same problem? Best regards, Ronan.

3 3

[opensuse-factory] Btrfs features
by Jeff Mahoney 02 Aug '13

02 Aug '13

Hi all - In another thread, someone posted about wanting an updated btrfsprogs (it's coming, as soon as I finish writing this email). He mentioned it in terms of wanting to try out the RAID5 code. One of the things that's made it possible for SUSE to support btrfs in our enterprise products is often overlooked in media reports and casual analysis: We limit the feature set we support. In SLE11 SP3, we actively limit the feature set without a mount option enabling access to those features. We … [View More]

6 9

[opensuse-factory] Contribute a new package to Factory
by GHui 02 Aug '13

02 Aug '13

Hi, I'm developing an open source program, it's named Paramon. I'm the beginner of the program. And I will upload the code to http://sourceforge.net/projects/openparamon. If I want to contribute the Paramon to SUSE distribution, what should I do? Any help will be appreciated. The following is the introduction of the Paramon. Paramon is a visual program for monitoring cpu used time, cpu sys+wa time, memory used rate, swap used rate, net send/recv MB per sec and disk read/write MB per sec. … [View More]

3 2

Main

Development

Information

Community

Social Media

Other

openSUSE Factory