February 2016 - openSUSE Factory - openSUSE Mailing Lists

[opensuse-factory] Too low download speed
by Michal Hlavac 02 Feb '16

02 Feb '16

Hi, i am trying to update tumbleweed from http://download.opensuse.org/tumbleweed/ repositories, but dowload speed is very slow (in bytes). I am in Czech republic and I've noticed this problem few times before. thanks, m. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 2

Re: [Fwd: Re: [opensuse-factory] why there are so few packages in Factory, revisited]
by Robert Schweikert 02 Feb '16

02 Feb '16

On 02/02/2016 03:59 AM, Dominique Leuenberger / DimStar wrote: <snip> > > I wonder if we should more promote to active maintainers that they set > themselves as a reviewer of a package; would that stop a prj maintainer > to step in and accept within hours? (might be worthy to explore - I for > one had not the worst experiences with this) Well I have run into a few cases where it does not work, i.e. even though I have set myself as a reviewer on packages a project maintainer accepted changes to the package anyway (with no chance for me to review, a matter of hours). I think we all appreciate that other people help out and update packages. However, as a package maintainer, in the end, if I am the sole maintainer, I expect to have final say about what gets accepted and what not. We have plenty of packages that have no active maintainers and thus having project maintainers that look after those and keep them up to date is great. However, the whole thing backfires very quickly as the practice of project maintainers overstepping their reach is very much discouraging to those that actually do care about their packages. But enough whining, I think there is at least a partial technical solution that could be implemented, and I think I have proposed this previously. Yes I know, if it is to change it is up to me, but there are just not enough hours in a day. Anyway here it goes: When a SR is submitted to a package the informational mail about the SR only gets send to the package maintainer, reviewer, or bug owner if they are set in OBS. If after a week the request has not seen any action, no comments etc, then a mail is sent to the project maintainers and they can then manage the request. Having the SR not show up in the project maintainers Inbox right away reduces the temptation to step in, reduces the flood of messages in project maintainers Inboxes as there will be many requests they will never see, and it gives the package maintainer the chance to act. From my point of view this is a win win for everyone and could certainly help smooth out some of the ripples. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei(a)suse.com IRC: robjo

1 0

[opensuse-factory] Re: Gefeliciteerd!
by Knurpht - Gertjan Lettink 02 Feb '16

02 Feb '16

Op dinsdag 2 februari 2016 08:24:04 CET schreef Hans de Raad: > Proficiat uber-geeko!:-) > > Hrgrt,HdR Dank je wel, Hans. Vandaag maar even bekomen van de schrik :) -- Gertjan Lettink, a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 2

Re: [opensuse-packaging] Re: [opensuse-factory] why there are so few packages in Factory, revisited
by Martin Pluskal 02 Feb '16

02 Feb '16

On úterý 2. února 2016 8:35:56 CET Marcus Meissner wrote: > On Tue, Feb 02, 2016 at 12:49:46AM +0100, Dominique Leuenberger / DimStar wrote: > > Michal, et.al. > > > > > - add "V=1" to make > > > Why? To make build warnings harder to see? > > > > A constant battle - I know that one. I myself consider V=1 great for > > debug perpose... as long as gcc's warnings are there if it's not > > specified, I don't enable it. > > Actually we are parsing the gcc commandline to spot if you are using > optflags and do some post build checks. (post-build-checks, check_gcc) Indeed there are actually several cases when lack of of usage of optflags was not observed due to silent build, such as in ninja, thin-provisioning tools and himeno - and those are just few cases which I noticed in last few days. > > > > - add %{?_smp_mflags} also to make install > > > Well, why not. But definitely not _after_ the argument. > > > > Parallel installation - how big is that package :) I doubt it makes > > much difference (but then: the latest version of spec-cleaner does this > > automatically IIRC - so the submitter might not have done this > > explicitly) > > I fixed several packages that build fine with -j2 but did not with -j8, > which was annoying. so this actually has the cause to break things, but > it is rare. > > Ciao, Marcus

2 1

[opensuse-factory] New Tumbleweed snapshot 20160130 released!
by Ludwig Nussel 02 Feb '16

02 Feb '16

Please note that this mail was generated by a script. The described changes are computed based on the x86_64 DVD. The full online repo contains too many changes to be listed here. Please check the known defects of this snapshot before upgrading: https://openqa.opensuse.org/tests/overview?distri=opensuse&groupid=1&versio… Packages changed: apache-commons-logging (1.1.3 -> 1.2) babl (0.1.12 -> 0.1.14) biosdevname (0.6.2 -> 0.7.1) crash (7.1.3_k4.4.0_2 -> 7.1.4_k4.4.0_2) dhcp (4.3.3 -> 4.3.3.P1) digikam fuse (2.9.4 -> 2.9.5) gegl libinput (1.1.4 -> 1.1.5) libxcb openldap2 (2.4.42 -> 2.4.43) openldap2-client (2.4.42 -> 2.4.43) pinentry privoxy (3.0.23 -> 3.0.24) python-keyring (5.7 -> 7.1.2) python3-six vim (7.4.1087 -> 7.4.1194) === Details === ==== apache-commons-logging ==== Version update (1.1.3 -> 1.2) - Update to version 1.2 see http://commons.apache.org/proper/commons-logging/changes-report.html or RELEASE-NOTES.txt for details ==== babl ==== Version update (0.1.12 -> 0.1.14) - Update to version 0.1.14: + sRGB precision tuning + Stability fixes + Locale fix for setting error tolerance. ==== biosdevname ==== Version update (0.6.2 -> 0.7.1) - Update to 0.7.1 * no upstream changelog provided ==== crash ==== Version update (7.1.3_k4.4.0_2 -> 7.1.4_k4.4.0_2) - Upgrade to 7.1.4 from upstream. For a detailed changelog see http://people.redhat.com/anderson/crash.changelog.html ==== dhcp ==== Version update (4.3.3 -> 4.3.3.P1) Subpackages: dhcp-client dhcp-doc dhcp-relay dhcp-server - Update to dhcp-4.3.3-P1 correcting bounds checking when receiving a packet (bsc#961305,CVE-2015-8605,ISC-Bugs#41267). - adjusted interval check. [*0019-dhcp-4.2.4-P1-interval.patch] - Fixed improper lease duration checking. Also added fixes for integer overflows in the date and time handling code(bsc#936923, bsc#880984). [+0020-dhcp-4.x.x-fixed-improper-lease-duration-checking.patch] - fixed service files to start dhcpd after slapd (bsc#956159) - dhclient-script: complain in the log about conflicts, added a see log messages to the dhclient log message (bsc#960506) [* 0018-client-fail-on-script-pre-init-error-bsc-912098.patch] ==== digikam ==== Subpackages: digikam-lang digikam-libs kipi-plugins kipi-plugins-acquireimage kipi-plugins-geolocation kipi-plugins-lang - Split out the five plugins that upstream ships with a metainfo.xml file: color, decorate, enhance, fxfilters and transform. All new subpackages for now supplement the main package (which is equal to the main package recommending them). - Add symlinks for solid actions so Plasma5 can use digikam to import images from the device notifier applet ==== fuse ==== Version update (2.9.4 -> 2.9.5) Subpackages: libfuse2 - fuse 2.9.5: * fix warning in mount.c:receive_fd(). * fix possible memory leak. * new upstream project and source URL * add new maintainer keyring and verify source signature ==== gegl ==== Subpackages: gegl-0_2 gegl-0_2-lang libgegl-0_2-0 - Add gegl-0.2.0-linker-flags.patch to add -lm to linker flags ==== libinput ==== Version update (1.1.4 -> 1.1.5) Subpackages: libinput-devel libinput-udev libinput10 - Update to version 1.1.5: * This release fixes a disable-while-typing issue on the Macbook Pro and works around some middle-finger tap issues on semi-mt devices. Unfortunately, due to the inconsistent (and often garbage) data that semi-mt touchpads send we had to resort to disabling pinch gestures on those devices to make three-finger taps reliable. ==== libxcb ==== Subpackages: libxcb-composite0 libxcb-damage0 libxcb-devel libxcb-dpms0 libxcb-dri2-0 libxcb-dri2-0-32bit libxcb-dri3-0 libxcb-dri3-0-32bit libxcb-glx0 libxcb-glx0-32bit libxcb-present0 libxcb-present0-32bit libxcb-randr0 libxcb-record0 libxcb-render0 libxcb-render0-32bit libxcb-res0 libxcb-screensaver0 libxcb-shape0 libxcb-shm0 libxcb-shm0-32bit libxcb-sync1 libxcb-sync1-32bit libxcb-xevie0 libxcb-xf86dri0 libxcb-xfixes0 libxcb-xfixes0-32bit libxcb-xinerama0 libxcb-xkb1 libxcb-xprint0 libxcb-xtest0 libxcb-xv0 libxcb-xvmc0 libxcb1 libxcb1-32bit - n_If-auth-with-credentials-for-hostname-fails-retry-with-XAUTHLOCALHOSTNAME.patch: If auth with credentials for hostname fails retry with XAUTHLOCALHOSTNAME (boo#906622). ==== openldap2 ==== Version update (2.4.42 -> 2.4.43) - Relabel patch 0011-Enforce-minimum-DH-size-of-1024.patch into 0010-Enforce-minimum-DH-size-of-1024.patch - Upgrade to upstream 2.4.43 release with accumulated bug fixes. - Still build on SLES12 - Loadable backend and overlay modules are now installed into arch-specific path %{_libdir}/openldap - All backends and overlays as modules for smaller memory footprint on memory constrained systems - Added extra package for back-sock - Consequent use of %{_rundir} everywhere - Rely on upstream ./configure script instead of any other macro foo - Dropped linking with libwrap - Dropped 0004-libldap-use-gethostbyname_r.dif because this work-around for nss_ldap is obsolete - New sub-package openldap2-contrib with selected contrib/ overlays - Replaced addonschema.tar.gz with separate schema sources - Updated ldapns.schema from recent slapo-nssov source tree - Added symbolic link to slapd executable in /usr/sbin/ - Added more complex example configuration file /etc/openldap/slapd.conf.example - Set OPENLDAP_START_LDAPI="yes" in /etc/sysconfig/openldap - Set OPENLDAP_REGISTER_SLP="no" in /etc/sysconfig/openldap - Added patch for OpenLDAP ITS#7796 to avoid excessive "not index" logging: 0011-openldap-re24-its7796.patch - Replaced openldap-rc.tgz with single source files - Added soft dependency (Recommends) to cyrus-sasl - Added soft dependency (Recommends) to cyrus-sasl-devel to openldap2-devel - Added patch for OpenLDAP ITS#8336 (assert in liblmdb): 0012-openldap-re24-its8336.patch - Remove obsolete patch 0001-build-adjustments.dif ==== openldap2-client ==== Version update (2.4.42 -> 2.4.43) Subpackages: libldap-2_4-2 libldap-2_4-2-32bit openldap2-devel - Relabel patch 0011-Enforce-minimum-DH-size-of-1024.patch into 0010-Enforce-minimum-DH-size-of-1024.patch - Upgrade to upstream 2.4.43 release with accumulated bug fixes. - Still build on SLES12 - Loadable backend and overlay modules are now installed into arch-specific path %{_libdir}/openldap - All backends and overlays as modules for smaller memory footprint on memory constrained systems - Added extra package for back-sock - Consequent use of %{_rundir} everywhere - Rely on upstream ./configure script instead of any other macro foo - Dropped linking with libwrap - Dropped 0004-libldap-use-gethostbyname_r.dif because this work-around for nss_ldap is obsolete - New sub-package openldap2-contrib with selected contrib/ overlays - Replaced addonschema.tar.gz with separate schema sources - Updated ldapns.schema from recent slapo-nssov source tree - Added symbolic link to slapd executable in /usr/sbin/ - Added more complex example configuration file /etc/openldap/slapd.conf.example - Set OPENLDAP_START_LDAPI="yes" in /etc/sysconfig/openldap - Set OPENLDAP_REGISTER_SLP="no" in /etc/sysconfig/openldap - Added patch for OpenLDAP ITS#7796 to avoid excessive "not index" logging: 0011-openldap-re24-its7796.patch - Replaced openldap-rc.tgz with single source files - Added soft dependency (Recommends) to cyrus-sasl - Added soft dependency (Recommends) to cyrus-sasl-devel to openldap2-devel - Added patch for OpenLDAP ITS#8336 (assert in liblmdb): 0012-openldap-re24-its8336.patch - Remove obsolete patch 0001-build-adjustments.dif ==== pinentry ==== Subpackages: pinentry-gnome3 pinentry-gtk2 pinentry-qt5 - completely rename to qt5 [boo#962076] - fix self-deprecation rpmlint warning ==== privoxy ==== Version update (3.0.23 -> 3.0.24) - Privoxy 3.0.24 Includes fixes for two security issues that may be used to remotely trigger crashes on platforms that carefully check memory accesses. * Security fixes (denial of service): + Prevent invalid reads in case of corrupt chunk-encoded content. CVE-2016-1982 [boo#963151] + Remove empty Host headers in client requests. Previously they would result in invalid reads. CVE-2016-1983 [boo#963152] * General bug fixes and improvements * White and blacklist updates ==== python-keyring ==== Version update (5.7 -> 7.1.2) - update to upstream release 7.1.2 - require Python 2.7+ - require python-setuptools_scm 1.9+ 7.1 * Issue #186: Removed preference for keyrings based on ``XDG_CURRENT_DESKTOP`` as these values are to varied to be a reliable indicator of which keyring implementation might be preferable. 7.0.2 * Issue #187: Restore ``Keyring`` name in ``kwallet`` backend. Users of keyring 6.1 or later should prefer an explicit reference to DBusKeyring or QtKeyring instead. 7.0.1 * Issue #183 and Issue #185: Gnome keyring no longer relies on environment variables, but instead relies on the GnomeKeyring library to determine viability. 7.0 * Issue #99: Keyring now expects the config file to be located in the XDG_CONFIG_HOME rather than XDG_DATA_HOME and will fail to start if the config is found in the old location but not the new. On systems where the two locations are distinct, simply copy or symlink the config to remain compatible with older versions or move the file to work only with 7.0 and later. * Replaced Pull Request #182 with a conditional SessionBus construction, based on subsequent discussion. 6.1.1 * Pull Request #182: Prevent DBus from indicating as a viable backend when no viable X DISPLAY variable is present. 6.1 * Pull Request #174: Add DBus backend for KWallet, preferred to Qt backend. Theoretically, it should be auto-detected based on available libraries and interchangeable with the Qt backend. 6.0 * Drop support for Python 2.6. 5.7.1 * Updated project metadata to match Github hosting and generally refreshed the metadata structure to match practices with other projects. ==== python3-six ==== - Fix issue with directory -> folder cpio error ==== vim ==== Version update (7.4.1087 -> 7.4.1194) Subpackages: gvim vim-data - Updated to revision 1194, fixes the following problems * New lines in the viminfo file are dropped. * Old style tests for the argument list. * Generated function prototypes still have __ARGS(). * Wrong argument to assert_exception() causes a crash. * Illegal memory access when using :copen and :cclose. * When running gvim in the foreground some icons are missing. * Recognizing <sid> does not work when the language is Turkish. * Using searchpair() with a skip expression that uses syntax highlighting sometimes doesn't work. * Cannot define keyword characters for a syntax file. * Can't sort on floating point numbers. * Default features are conservative. * Conflict for "chartab". * Using the local value of 'errorformat' causes more problems than it solves. * 'langmap' applies to the first character typed in Select mode. * Langmap test fails with normal build. * Autocommands triggered by quickfix cannot always get the current title value. * No support for JSON. * Build with normal features fails. * Coverity warns for NULL pointer and ignoring return value. * type() does not work for v:true, v:none, etc. * Automatically generated function prototypes use __ARGS. * No error for jsondecode('"'). * ":argadd" without argument is supposed to add the current buffer name to the arglist. * Missing error number in MzScheme. * Expressions "0 + v:true" and "'' . v:true" cause an error. * No tests for "is" and "isnot" with the new variables. * This doesn't give the right result: eval(string(v:true)). * No test for new behavior of v:true et al. * The +channel feature is not in :version output. * empty() doesn't work for the new special variables. * test_writefile and test_viml do not delete the tempfile. * Crash with invalid argument to glob2regpat(). * free_tv() can't handle special variables. * Error messages for security context are hard to translate. * The channel feature isn't working yet. * Can't build with FEAT_EVAL but without FEAT_MBYTE. * Compiler warning for not using return value of fwrite(). - Updated to revision 1130, fixes the following problems * Repeating CTRL-A doesn't work. * No tests for :hardcopy and related options. * When making a change while need_wait_return is set there is a two second delay. * With 'rightleft' and concealing the cursor may move to the wrong position. * Vim can create a directory but not delete it. * When using ":next" with an illegal file name no error is reported. * Using {ns} in variable name does not work. (lilydjwg) * delete() does not work well with symbolic links. * delete(x, 'rf') does not delete files starting with a dot. * No longer get "." and ".." in directory list. * argidx() has a wrong value after ":%argdelete". (Yegappan Lakshmanan) * delete(x, 'rf') fails if a directory is empty. (Lcd) * Using ":argadd" when there are no arguments results in the second argument to be the current one. (Yegappan Lakshmanan) * There is no perleval(). * Can only get the directory of the current window. * Python None value can't be converted to a Vim value. * Memory leak in :vimgrep. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0

[opensuse-factory] openSUSE & You: Contributing to our Project
by Richard Brown 01 Feb '16

01 Feb '16

First, apologies for cross-posting this, but it's relevant to more than just the opensuse-project(a)opensuse.org audience. In order to cut down the noise on other lists, I ask that all responses are sent to opensuse-project(a)opensuse.org only. Second, this is a 'from the heart' and somewhat 'off the cuff' post from me and me alone. This has not been reviewed by anyone else, so please don't interpret this as some kind of statement from the Board, the Project, or SUSE. This is just me, talking about things I see and giving advice that I hope will be useful to the majority of the people who read it. So, what is this all about? Well a lot of people talk to me, and after a very inspirational FOSDEM I got thinking about recurring trends of questions that come my way: "How does the openSUSE Project work?" "Who decides what happens?" "What do you need me to do?" "How do I get started?" These questions come from not only newcomers and potential newcomers to the Project, but also people I would consider 'veterans' who I would have assumed already knew the answers to these questions naturally. This post is my attempt to provide answers to these and related questions. 1 - How does the Project work? The Project is a self-organised, self-governed, community working on the openSUSE Distributions (Tumbleweed & Leap) as well as various other Free and Open Source Software, including OBS, openQA, OSEM, Portus, Machinery, and more. We have no Product Managers, Project Managers, or Community Managers. We have no Technical Committees or Steering Groups. For those who have read "The Cathedral and the Bazaar", openSUSE is very much a "Bazaar" and hardly anything like a "Cathedral". Whatever Teams we do have are self-organised by the members of those teams, with different ways of working together to accomplish whatever particular goals within the project they are working on. The Project does have the openSUSE Board [1], who's role is to 'lead' the Project by acting as a central point of contact and conflict resolution. In other words, they help keep everyone in the loop with what everyone else is doing, help resolve any conflicts that arise, and being the 'decision makers of last resort' in situations where decisions need to be made and there is no one else available or willing to do so. The Board is a little like the 'A-Team' - If you have a problem, if no one else can help, then the Board is there for you, either to help out, or help you find better help elsewhere. The Board is elected by the openSUSE Members [2], those contributors who have demonstrated sustained and substantial contributions to the Project. SUSE are the primary sponsor of the openSUSE Project. All SUSE employees are encouraged to contribute to the openSUSE Project. These contributions are carried out as 'peers'; No special treatment is granted to SUSE employees, in fact the employer of a contributor should be irrelevant within the openSUSE Project. In areas of particular interest or importance to SUSE, they may hire folk to work in particular roles within the openSUSE Project. With one exception (the role of Chairman of the Board), none of these roles should be considered 'exclusive' to SUSE. There is scope for anyone to contribute to the openSUSE project at any level, assuming they are willing and capable to do the work. 2 - Who decides what happens? You Do We are driven by our contributions. If something is not being done, it's because no one has decided to do it. We do our best to make openSUSE very accessible in order to make us the natural choice to be the Project through which you give your time & effort. The openSUSE Project is structured the way it is to empower our contributors to really shape the direction of the Project. Also a significant amount of the tools we have as a Project exist in order to make those contributions easier. OBS and OSEM are obvious examples, but this is true in all aspects of the project, from the technical ones to the diverse range of other activities, marketing, advocacy, outreach, community, wiki, documentation, etc. You don't need to ask permission to get started, you just need to know what you want to do. 3 - What do you need me to do? You Decide Please don't be terrified by this! To quote The Cathedral and the Bazaar, "Every good work [...] starts by scratching a [...] personal itch.". Find things inside openSUSE, our Project, our distributions, our tools, our wiki, that you do not like, that affect you, that get in your way, and decide to change them. While it may sound selfish, there is no better motivation than solving the issues which affect you first and foremost, the benefit of doing that as part of a community means your work ends up helping others, and others will in turn help you when they share that same itch that needs scratching. Don't expect someone else to do it. Don't think it is someone else's job to fix. It is your responsibility to help make openSUSE succeed in the areas that matter to you And don't expect anyone else to tell you what to do or what needs doing - volunteers are rarely motivated when given orders from others, so that just isn't typically the openSUSE way. That said, I do believe we could do with having some indications of particular areas where we need help..the new openSUSE Mentoring website [3] is a perfect example of something the Project now has to solve this problem (Thanks to Chris and Henne and everyone else who has contributed to this!) In the highly unlikely event that you think everything is wonderful and there is nothing that annoys you, but you still want to give something back to the openSUSE project, then dig a little deeper, try something new, either technically in our products, or get involved in a new aspect of the Project that interests you - I guarantee you'll find something somewhere which could do with your help. 4 - How to get started? So, you've picked something to work on, how to get started. Here is my advice. 4a. Do your homework - Make sure you understand the topic you're tackling. Dig through the problem to make sure you haven't missed something. Read our wiki pages on the topic. Google. Look at how other FOSS Projects deal with the problem? Is their solution better or worse that what you are thinking? Talk to people who might know stuff about the topic, and bounce your ideas off them. Our IRC channels are a good place for such discussions, as are events like our openSUSE Conferences. 4b. Plan your solution - You've decided what you want to do, decide how you intend to do it. You don't need to have all the details worked out, but you should have a clear understanding of the direction you want to go in, and how things should look when you are done 4c. Do you need help? Is this going to impact other people in a noticeable way? Do you want a second opinion? If the answers to any of these questions are yes, continue to 4d. If no, skip to 4h 4d. Share with the Project - Take everything you have learned, and what you plan, and put it all together in a clear, succinct email for the mailinglists. Avoid writing open ended questions. Despite everyone's best intentions, coming to the Project with a question like "What do you think we should do about X?" will lead to either silence, or an almost infinite number of responses, many of which will disagree with you, often without proposing alternatives. Write the email from the perspective of "This is what I think we need to do, and this is what I intend to do about it". Describe your findings from step 4a, explain your plan from step 4b. Include proof of concepts if you have them. Post this mail to an appropriate mailinglist [4]. If you cannot identify an appropriate list, or you think the topic is deserving of a project-wide audience, then use either opensuse-factory(a)opensuse.org for technical changes, and opensuse-project(a)opensuse.org for everything else. Once you are happy the email makes it possible for everyone else to understand the problem, and that this is your problem and you are going to solve it, fire away. Now it is the responsibility of everyone else in the Project to convince you that you need to do things differently. 4e. Listen - the openSUSE Project is full of very clever people. Listen to their feedback, consider it. Your proposal included your reasoning, their feedback should be equally reasoned and informative, and so even a 'failure' of a proposal at this point is a learning experience. 4f. Respond - fast feedback drives innovation. If people are giving you feedback, discuss back with them, tell them when you agree with what they're saying, tell them when you disagree and why. This is how you will find other people to work with you on this thing. 4g. Decide - You do not need to accept all, or any, of the feedback. If nothing comes up that convinces you to deviate from your plan, then carry on as you planned. If something gets in the way, then work together to find a solution, either one that includes a compromise that everyone is equally unhappy with, or one where 'both' options are possible. This is an aspect of the openSUSE community that we often overlook - when we have two sets of contributors wanting to pull in two different directions, our collective natural instinct is to often find a way of accomplishing *both* - How else do you think we ended up with KDE, GNOME, XFCE, LXDE, Enlightenment, etc? This is a good thing, makes our project reflect everything which our contributions want to work on, and something which really sets us apart from many other Projects out there 4h. Do it 4i. Talk about it! Our statistics show that the openSUSE Project is on the up and up, and we are in many ways ahead of a great many similar projects who are often perceived as being more successful than us. A big part of that is because we excel at doing stuff, and are lousy about talking about it. So this is a call to action to ask that everyone reading this email keeps in mind the cool stuff that they're working on as part of openSUSE, and talk about it. Social media, conferences, meetups, whenever you get a chance, tell the world about what you're doing. It is not just a case of being 'Green and Proud', but talking about recent successes often leads to conversations that reveal what the next challenge is, and so the cycle continues, but at least it's a lot of fun ;) Thanks to all for reading this. Hopefully it is food for thought for old and new contributors alike. I intend to throw this up on some blog sometime, or find a way of squishing some of these thoughts onto the wiki, so please direct any feedback and discussion to the opensuse-project(a)opensuse.org mailinglist where I promise to listen and respond ;) - Richard [1] https://en.opensuse.org/openSUSE:Board [2] https://en.opensuse.org/openSUSE:Members [3] https://opensuse.github.io/mentoring/ [4] https://lists.opensuse.org/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0

[opensuse-factory] Requesting new devel projects for Ceph and openATTIC
by Nathan Cutler 01 Feb '16

01 Feb '16

Hi Factory ML: Ceph[1] is a unified, distributed storage system designed for excellent performance, reliability and scalability. openATTIC[2] is a storage management and monitoring tool that our team is currently in the process of adapting to work with Ceph clusters. My colleagues and I are very interested to submit the latest, greatest versions of these two interesting pieces of software to openSUSE:Factory. Projects are already created: https://build.opensuse.org/project/show/filesystems:ceph https://build.opensuse.org/project/show/filesystems:openATTIC What do we need to do to obtain "Factory devel project" status for these projects? Thanks in advance, Nathan Cutler [1] http://ceph.com [2] http://openattic.org/ -- 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] Nginx Mainline (1.9.x)
by Ibrahim M. Ghazal 01 Feb '16

01 Feb '16

I'm curious, why does Tumbleweed have Nginx "stable" (1.8.x) and not "mainline" (1.9.x)? >From https://www.nginx.com/blog/nginx-1-6-1-7-released/ : > Note that stable does not mean more reliable or more bug-free. In fact, the mainline is generally regarded as more reliable because we port all bug fixes to it, and not just critical fixes as for the stable branch. And > We recommend that in general you deploy the NGINX mainline branch at all times. -- 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] Do we want the encryption method selector during install?
by Ancor Gonzalez Sosa 01 Feb '16

01 Feb '16

The changes described (screenshots included) in this pull request are already in their way to Tumbleweed (sr#356569) https://github.com/yast/yast-users/pull/84 So the question now is - should we adapt the control.xml file for Tumbleweed or is it fine to not offer the selection of password encryption method during installation anymore? In case you believe it should be there, what do you prefer - the verbose "users" proposal or the more concrete "users_encryption" one? Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

5 4

[opensuse-factory] grub.cfg in multiboot environments
by Hans de Faber 01 Feb '16

01 Feb '16

Hello everybody, On my efi desktopsystem I have a multiboot environment with 3 flavours of opensuse and win10. 1. opensuse 13.2 the previous 2.leap42.1 the workhorse 3. tumbleweed the future 4. win10 for flightgear 5. system rescue disk I set my efiboot variable always to leap42 the workhorse for everyday. Each installation is a complete install and has its own boot (grub) environment, unchanged. Problem: After a kernel update the grub.cfg of the non updated versions point to the purged kernel Question: Why points grub.cfg to a specific kernel an not to the logical link vmlinuz and initrd ? Thanks, Hans -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 1