January 2017 - openSUSE Factory - openSUSE Mailing Lists

[opensuse-factory] LVM logical volume not activated automatically
by Alin M Elena 06 Jan '17

06 Jan '17

The same setup as mine and the same problem after the update. however i think the solution is just a coincidence since I had both packages installed already. WHat I have noticed howeever is that I get two jobs running one for udev (udev-settle) with a limit of 180s and the one for lvm activation of 90s. now i speculate that whatever settle is doing has effect on lvm activation and is not finished in the 90s. I reduced the time in settle to 70s and after approx 2min i have the login screen up without the emergency systemd. systemd-analyze blame 1min 50.210s lvm2-activation-net.service 1min 10.197s systemd-udev-settle.service 8.664s systemd-cryptsetup@cr_nvme \x2d2002538435b1b37d4\x2dpart2.service my understanding is this can be cause by many things so once i get more time I may dig more. Alin -- Without Questions there are no Answers! _______________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ _______________________________________

2 4

[opensuse-factory] packman bugzilla ?
by Daniele 05 Jan '17

05 Jan '17

Hi guys, sorry if is OT but is there a packman bugzilla ? I filled this: https://links2linux.de/browse/PM-138 Is the right place ? Thanks, Daniele. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 2

[opensuse-factory] dropping repositories from devel:languages:python:Factory
by jan matejek 05 Jan '17

05 Jan '17

hello, just a heads-up: i'm about to remove "openSUSE_13.1" and "openSUSE_Factory" repositories from devel:languages:python:Factory project. 13.1 is arguably too old to keep around. If you're interested in it, feel free to make your own project and add it, i guess. (or, of course, voice some reasons why we should keep it) "openSUSE_Factory" is a duplicate of "openSUSE_Tumbleweed". If you're using it, please change your config to use Tumbleweed instead. 13.2 is EOLing soon, but i'll be keeping the repository alive for the foreseeable future. I am also using this opportunity to add Leap 42.2. regards m.

1 0

[opensuse-factory] Miracast
by A. den Oudsten 05 Jan '17

05 Jan '17

Is there a Miracast program for Linux? Andre den Oudsten -- 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] Splitting patterns
by Simon Lees 04 Jan '17

04 Jan '17

Hi All, Time for part 2 of the pattern cleanup (i've already put through an SR to update package names and remove packages that don't exist). In this round i am aiming to split the 1 pattern package into several so that A) some patterns can be maintained in there associated devel repo and B) hopefully so that we can share some patterns with SLE (with that in mind maybe we should remove openSUSE from the package names). The following is a suggestion of what I think we (I) should implement, it is of course all up for change and suggestions. With that in mind firstly i'd like to suggest that we drop the following patterns. The following are collections of miscellaneous similar software rather then software that works together to perform a task * devel_ide * misc_server * remote_desktop * voip The following should be dropped for there given reason. * generic_server - (Merge into the console pattern, as these are console tools) * devel_qt4 - (Only 1-2 packages) * non_oss / non_oss_opt - (these could just be merged, between them they recommend gst-fluendo-mp3 and unrar, then suggest 1-2 things) * tabletpc - (drivers should be part of X11) * sw_management - (only contains zypper which is in minimal) * rest_dvd9 - (not used) * rest_promo_dvd - (not used) These patterns are the only ones I'd like to do internal changes to. * base * enhanced_base * enhanced_base_opt * minimal_base * minimal_base-conflicts As was mentioned in the previous thread in SLE we have a "Minimal" and "Base" pattern, i'd like to replace the above with these. Any tools that are currently in enhanced_base/enhanced_base_opt but not in the new base can be moved into "console", console being what gets installed if you select "text mode" in the installer. This will mean that by default text only systems will get a decent set of tools but that users can use the advanced install options to strip back to a more basic system. As has been mentioned minimal and base aren't very descriptive, so I'm going to suggest minimal-appliance (minimal) and minimal-server (base), but I'll post the description of both so someone can suggest something better. Minimal: This is the minimal openSUSE runtime system. It is really a minimal system, you can login and a shell will be started, that's all. It is intended as base for Appliances. Base: This is the base runtime system. It contains only a minimal multiuser booting system. For running on real hardware, you need to add additional packages and pattern to make this pattern useful on its own. The following will stay in system:install:head/patterns-openSUSE but I will possibly rename it to "patterns-openSUSE-base" depending on what people think. * 32bit / 64bit * apparmor/apparmor_opt * console * update_test * x11 * x11_opt * x86 The following patterns were split out of base hopefully to make this more usable for SLES/SLED if thats not possible they could be included in the base package, most of the desktop patterns are here because I couldn't find a better place to put them, system:install:head/patterns-openSUSE-server * dhcp_dns_server * directory_server * file_server * gateway_server * kvm_server * lamp_server * mail_server * print_server * xen_server system:install:head/patterns-openSUSE-desktop * books * laptop * technical_writing * imaging * imaging_opt * multimedia * multimedia_opt * technical_writing The following devel pattern's I couldn't think of a better place for (someone else might be able too) these could also just go in patterns-openSUSE-base as well. system:install:head/patterns-openSUSE-devel-base * devel_basis * devel_kernel * devel_rpm_build * devel_web The "rest" patterns are used to build the iso's there big and annoying so I think they'd be best in there own package system:install:head/patterns-openSUSE-rest * rest_cd_gnome * rest_cd_kde * rest_cd_x11 * rest_core_dvd * rest_dvd I am suggesting that the remaining patterns are all moved to packages in there corresponding devel repos as follows. The idea here is that I won't modify the contents of these patterns but it will make it much easier for the individual maintainers to. devel:libraries:c_c++/patterns-openSUSE-devel-C-C++ * devel_C_C++ GNOME:Factory/patterns-openSUSE-gnome * devel_gnome * gnome * gnome_admin * gnome_basis * gnome_basis_opt * gnome_games * gnome_ide -> rename (gnome-devel-tools, dropping ide patterns) * gnome_imaging * gnome_imaging_opt * gnome_internet * gnome_laptop * gnome_multimedia * gnome_multimedia_opt * gnome_office * gnome_office_opt * gnome_utilities * gnome_yast * sw_management_gnome -> rename gnome_sw_management Java:packages/patterns-openSUSE-devel-java * devel_java KDE:Frameworks5/patterns-openSUSE-KDE * kde * kde_plasma * kde_edutainment * kde_games * kde_ide -> rename to kde_devel_tools * kde_imaging * kde_internet * kde_telepathy * kde_multimedia * kde_office * kde_utilities * kde_utilities_opt * kde_yast * sw_management_kde -> rename to kde_sw_management (could drop, only has libyui-qt-pkg) KDE:Qt5/patterns-openSUSE-devel-KDE (Maybe this should be part of the kde pattern?) * devel_kde_frameworks * devel_kde * devel_qt5 Mono:Factory/patterns-openSUSE-devel-mono * devel_mono devel:languages:perl/patterns-openSUSE-devel-perl * devel_perl devel:languages:python:Factory/patterns-openSUSE-devel-perl (maybe these should be in devel:languages:python?) * devel_python * devel_python3 openSUSE:Tools/patterns-openSUSE-devel-osc * devel_osc_build devel:languages:ruby/patterns-openSUSE-devel-ruby * devel_ruby devel:languages:tcl/patterns-openSUSE-devel-tcl * devel_tcl YaST:Head/patterns-openSUSE-yast * devel_yast * x11_yast * yast2_basis * yast2_install_wf X11:Enlightenment:Factory/patterns-openSUSE-enlightenment * enlightenment M17N:fonts/patterns-openSUSE-fonts * fonts * fonts_opt games/patterns-openSUSE-games * games devel:languages:haskell/patterns-openSUSE-haskell * haskell_platform network/patterns-openSUSE-network * network_admin network/patterns-openSUSE-leechcraft * leechcraft * leechcraft_media * leechcraft_messenger * leechcraft_netutils * leechcraft_office * leechcraft_utilities X11:lxde/patterns-openSUSE-lxde * lxde * lxde_laptop * lxde_office X11:lxqt/patterns-openSUSE-lxqt * lxqt X11:MATE:Factory/patterns-openSUSE-mate * mate * mate_admin * mate_basis * mate_internet * mate_laptop * mate_office * mate_office_opt * mate_utilities LibreOffice:Factory/patterns-openSUSE-office * office - (it only contains libre office anyway) X11:xfce/patterns-openSUSE-xfce * xfce -> X11:xfce * xfce_basis * xfce_laptop * xfce_office That was rather long, congrats if you got to the bottom. Looking forward to your feedback. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

3 2

[opensuse-factory] GNOME hamster-time-tracker package
by Martin Wilck 04 Jan '17

04 Jan '17

The package "hamster-time-tracker" (which is highly important for my daily work :-) has been removed from TW 1 year ago with the argument "depends on old things we would like to drop". I just installed the current version from GNOME:Apps and it pulled in exactly ZERO dependencies. The list of requirements looks indeed pretty harmless (https://paste.opensuse.org/56376182). What were the offending "old things" because of which this package has been dropped? Have these dependencies perhaps been fixed in the current GNOME:Apps package, and if this is so, would it be possible to re-add it to the TW core repo? Btw, https://software.opensuse.org/package/hamster-time-tracker?search_ term=hamster-time-tracker still lists this package with an "official release", but the respective links are broken; that looks like a bug to me. Best Regards, Martin -- Dr. Martin Wilck <mwilck(a)suse.com>, Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- 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] Factory Check Ins Status
by Peter Linnell 04 Jan '17

04 Jan '17

Hi all, Just a short note to let people know about a couple of things which are backing up acceptance into Factory. 1. With the holidays and a lot of people on vacation accepting new Factory submits is a bit backed up more than I like. So, please allow some patience to allow us to catch up. In my queue, the back log is about 135 packages, meaning I'm reviewing packages submitted 18 days ago. Security and maintenance packages always get priority and I personally try to get them checked in within 24 hours or less, provided all the QA checks are good. 2. For new packages which are under legal team review, the backlog is deeper given the sheer numbers (hundreds?) of packages going in to Factory and TW. This a good problem to have as we have more active packagers. IMO the quality of our packages is getting better and some of our community members are doing an outstanding job keeping them updated. End result a better openSUSE with a wider variety packages never seen before. If you meet an openSUSE packager in real life or virtually, buy them a beer :) From one of your friendly openSUSE review team members, Peter -- 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] using "include =" in smb.conf does not work on Leap 42.1
by Thomas Wagner 03 Jan '17

03 Jan '17

Hi On openSUSE 13.1, I used "include = /etc/samba/shares.conf/%U.conf" to include user specific shares via smb.conf. So, i had a working configuration. Using the configuration that worked on 13.1 does not work on Leap 42.1. There are no errors that a *.conf file cannot be found (thus my paths are correct), but the configuration is simply not included. Copying the stuff in my custom *.conf manually to smb.conf works though. Thus there seems to be no error in my config. Just the "include" is not performed. Have there been any changes to the "include =" feature of smb.conf from openSUSE 13.1 to Leap 42.1? best regards Thomas # smbd --version Version 4.2.4-21.3-3689-SUSE-SLE_12-x86_64 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 4

[opensuse-factory] btrfs qgroup / quotas concerns - revisited
by Ronan Arraes Jardim Chagas 03 Jan '17

03 Jan '17

Hi guys, Sometime ago, a BTRFS developer (Chris Murphy), which was helping me to fix a bug, warned that quotas must not be enabled by default in BTRFS because it is not stable. He actually sent a message to this mailing list: https://lists.opensuse.org/opensuse-factory/2016-09/msg00032.html However, some openSUSE developers contradicted Chris, specially Richard Brown: https://lists.opensuse.org/opensuse-factory/2016-09/msg00085.html Hence, nobody took the advice and quotas were enabled by default in Leap 42.2. I am sending this message because I think it is necessary to rethink this decision. A very annoying bug that I was having in all my openSUSE machines (Leap and Tumbleweed) is actually caused by quotas. Every week, when the maintenance script is started, my systems become unresponsive for almost 30 min. I mentioned it here but received just one answer: https://lists.opensuse.org/opensuse-factory/2016-09/msg00130.html Today, I saw a bug reported by Jan Ritzerfeld describing exactly the same behavior and mentioning that disabling quota fixes it: https://bugzilla.opensuse.org/show_bug.cgi?id=1017461 I tried, and I can confirm that the bug is indeed fixed by this workaround in Leap and Tumbleweed. My server, which was recently updated to Leap 42.2, started to show those freezes. Notice that quotas were not enabled in 42.1. Hence, I think we must revisit this subject as soon as possible. Best regards, Ronan Arraes -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

6 7

[opensuse-factory] updating tumbleweed - best practices
by nicholas 02 Jan '17

02 Jan '17

from experience and looking around forums, how to update tumbleweed correctly is not obvious, and not clearly presented. The lack of guidence is causing confusion and problems. The rest of this post is based on my ASSUMPTION that 'sudo zypper dup --no- allow-vendor-change' is best practice. Forums are filled with confusion over the update process e.g. https://forums.opensuse.org/showthread.php/517451-Differnce-between-zypper-… I have seen other suggestions of (including by forum global moderator) 'zypper up' mostly, 'zypper dup' occasionally, this is without clarfying to disable extra repos. https://forums.opensuse.org/showthread.php/504212-I-get-no-updates-to-Tumbl… there are also MANY implicit postings of problems suggesting the OP is not even aware of the issues. The current update process would appear: non-evident (not communicated, ambiguous (when to up/dup?), non deterministic (its ok to get out of sync sometimes?), error prone (new user forgets to disable extra repos), time consuming mess. in fact, do zypper up/dup really make sense conceptually or functionally to a rolling distribution? The question, IF the 'no allow vendor change' is best practice, should we make a more accessible command for updating out of the box (i.e. zypper tup/or other) and should best practices not be better communicated to new users? - I have 'alias tup=sudo zypper dup --no-allow-vendor-change' in .bashrc - Is the dup default of allow-vendor-change really required for leap upgrade? [my own learning curve was quite painful, you should not underestimate the conceptual overhead to new user of understanding all the zypper ins and outs regarding 'packages not being updated', 'changing vendor' etc -> your basically expecting the noob to learn *everything* in order to get a working and reliable system within the first few months] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

22 72