April 2017 - openSUSE Factory - openSUSE Mailing Lists

[opensuse-factory] Repository organization
by Nate Graham 24 Apr '17

24 Apr '17

Howdy folks, I'm running Tumbleweed, and the separation of packages across so many different repos is something I'm still not sure I understand. Having to juggle a bunch of repos one of my persistent frustrations with this otherwise excellent distro. I understand why software that's non-OSS or has license issues must stay out of the main repo, but why is so much stable FOSS software scattered across different repos? For example: To install LuckyBackup, I need to activate http://download.opensuse.org/repositories/KDE:/Extra/openSUSE_Tumbleweed/ To install openSCAD, I need to activate http://download.opensuse.org/repositories/graphics/openSUSE_Tumbleweed/ Both of these programs are FOSS and have been rock-solid stable for me. *somebody* is clearly packaging them for Tumbleweed; why aren't they in the main repo? Why the separation? Nate -- 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] VLC installation with codecs
by Karagkiaouris Diamantis 24 Apr '17

24 Apr '17

Hello, Is it better to install vlc from packman repository or from Videolan? I think also that packman is missing libdvdcss2. I couldn't find it in repository. I am using the latest updated tumbleweed. Thank you -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

6 11

[opensuse-factory] Looking for libqt5-qtwebsocket and libqt5-qtquick1-devel
by Chan Ju Ping 24 Apr '17

24 Apr '17

I am trying to compile Mycroft for the Tumbleweed desktop, with the help of a Mycroft developer, and I have hit a snag on finding equivalent packages for: *libqt5-qtwebsocket *libqt5-qtquick1-devel I can find the source download for the former, though I am wondering whether there is any particular problem with the program because it is not offered in the main repo for TW. I can't find the equivalent development packages for the latter. Any help is appreciated, and could possibly make installing Mycroft easier for future TW users.

2 2

[opensuse-factory] Tumbleweed x86_64 Snapshot 20170419 plasma desktop not starting ...
by Verwijs 23 Apr '17

23 Apr '17

Tumbleweed x86_64 Snapshot 20170419: plasma desktop not starting. everything goes well until plasma-desktop needs to start... see video https://vimeo.com/214389950 i use default nouveau packages (nvidia) when i look at: http://ftp1.nluug.nl/os/Linux/distr/opensuse/tumbleweed/iso/Changes.2017041… (change log) /==== python-sip ==== - Revert back to version 4.14.7 to prevent crashes in Plasma-desktop (bko#323899). / not sure if related... ----- ____________________________________________________ Dank U.. Thank You.. My Twitter Page: http://twitter.com/OpenSimFan My Facebook page (be my friend, please ) http://www.facebook.com/andre.verwijs My Google+ page (follow me please ) André Verwijs - Google+ . -- View this message in context: http://opensuse.14.x6.nabble.com/Tumbleweed-x86-64-Snapshot-20170419-plasma… Sent from the opensuse-factory mailing list archive at Nabble.com. -- 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] Adjusting desktop defaults to reflect project realities
by Tomas Chvatal 23 Apr '17

23 Apr '17

Hello all, Given the latest thread about the desktop on our bellowed factory mailing list I would like to propose the following: "Desktop selection dialogue won't have preselected any default value." This, of course, means there won't be any default and preferred environment for users to use. Our project is not just about the desktop, and as we like to say again and again 'it is not just a distribution' :). We are more about the ecosystem and the possibilities you can do with your machines. Thus to avoid the discussion about A being bigger^Wbetter than B lets rather focus on how to keep rolling forward and keeping friendly atmosphere while we all work on things we care about. In the end, if we go the full road we support all the stuff we have on the FTP anyway. From the top brass to least downloaded tiers users can really play with anything: GNOME/KDE Cinnamon/Enlightenment/MATE/XFCE/ All the millions of WMs If users report an issue we (here I mean the maintainers) work on it regardless if the issue pops up on the 'currently selected default' or somewhere else. Yes, some of the WMs and DEs might contain more bugs than the others but it is in the hands of the upstream in the end, because of our upstream first policies anyway. Cheers Tom

43 130

[opensuse-factory] VirtualBox in Tumbleweed 20170414 - host modules no longer loaded by default
by René Krell 23 Apr '17

23 Apr '17

Hi all, after an upgrade from 20170407 to 20170414 I've got trouble with virtualbox. My Windows 7 host does not start at all. There is none of the vbox* modules loaded by default although virtualbox-host-kmp-default is up to date. If adding them all four manually by applying 'insmod' all goes fine. Anyone else or just me? René -- 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] Highlighting Desktop Options (was Adjusting desktop defaults to reflect project realities)
by Richard Brown 23 Apr '17

23 Apr '17

On 22 April 2017 at 11:11, Luke Jones <luke.nukem.jones(a)gmail.com> wrote: > Regarding the desktop selection process, I've spotted a few > suggestions in other mails to this topic; > - No Default > - Do not change the ordering of the choices (this could spark another "war") > - Provide guides in the install process which users can click on. > > I like the above. In fact this could give openSUSE an edge as the > first distro to provide a full offline installation medium with guides > to desktop selection provided within the installer. > The guides could be a button next to each selection [Details], which > brings up a window of clickables that shows such things as; > - what a clean default Desktop looks like, along with description of > capabilities and/or highlights. > + A list of the main default applications, each of which can be > clicked, eg, as below. > - what the default browser, office suite, and pdf viewer are plus > concise descriptions of capabilities, > - the default music player, video player, and perhaps image viewer > are, along with concise details as above. > > So basically highlight the main points of each default install > selection for each desktop. It seems that if we cover the main > applications and use cases in the suggested installer addition, then > we could easily let new users decide what they might be comfortable > with trying. > > Would it be worth discussing the above in a new thread perhaps? > > Kind regards, > Luke Jones. Yes, this sounds like a topic worthy of a new thread, here's the thread I think the easiest way to implement this would probably be in adding a new 'Help Me Decide?' button to the Role Selection screen That Help Me Decide button could then load up a separate window inside YaST, such as we already do with the Release Notes It should be possible to have it somewhat 'rich' with fonts and graphics, maybe even HTML'y so easy for anyone to contribute to. It's theoretically possible it could actually retrieve it's content remotely, like the Release Notes now do, which would make it even more contribution friendly and flexible considering Tumbleweed's desktop offerings will always be in a somewhat flexible state. Such an approach should also be easy to render differently or disable in Text Only installations. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 7

Re: [opensuse-factory] VLC installation with codecs
by Carlos E. R. 22 Apr '17

22 Apr '17

Please remember to post to the mail list, not in private. On 2017-04-22 20:22, Diamantis Karagkiaouris wrote: >> It doesn't matter, but be sure you do not mix packages from both sources >> (main and codecs or libraries for vlc) > > How is it possible? How can i reassure this from zypper? I do it on YaST. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

1 0

[opensuse-factory] openSUSE Tumbleweed - Review of the week 2017/12
by Dimstar / Dominique Leuenberger 22 Apr '17

22 Apr '17

Dear Tumbleweed users and hackers, What a week! Tumbleweed once again is the first (to my knowledge) to ship the just released GNOME 3.24.0 as part of its main repository. Being shipped to the users in less than 48 hours since the official release announcement is something we can only do thanks to all the automatic building and testing AND the efforts put into the packages! If packagers would not be at the ball the whole time, this would not be possible. Even though the week has seen ‘only’ 4 snapshots (0317, 0318, 0320 and 0322) the changes delivered to the user base is enormous. The major changes this week were: * GNOME 3.24.0 – Released on March 22nd, part of snapshot 0322 * The YaST Teams work regarding the desktop selection workflow [0] * qemu 2.8.0 * Linux kernel 4.10.4 * Mozilla Firefox 52 – NOTE: no more support for NPAPI plugins * GCC 7 is available as optional compiler (distro still built using gcc6 though) * More work to get the ‘system user’ situation changed, having special packages creating the users [1] One important note at this point: again there were users falling into the trap with incomplete updated systems with snapshot 0322. Important: """zypper up""" is NOT the right thing to keep your Tumbleweed system running. Use """zypper dup [--no-allow-vendor-change]""" Things currently being prepared for you * GCC7 as default compiler – this might still take a while, but it IS coming * KDE Plasma 5.9.4 * Linux kernel 4.10.5 – and beyond * More python packages converted to singlespec For the next three weeks, Tumbleweed will be given in the careful care of Max and Ludwig, while I will be enjoying some time off. As is usual when teams are running on lower resources, it is possible that snapshots might be delayed a little bit, but I don’t fear to much for that: you can continue submitting as you’re used to – just in case of some delays, please show some understanding. I’m sure Max and Ludwig will be there for you if you need any help. Also, in this period, I will not provide the weekly reviews. I might try to do a recap once I’m back, but no promises there. Cheers, Dominique [0] https://lizards.opensuse.org/2017/02/20/highlights-of-yast-developm ent-sprint-31/ [1] https://lists.opensuse.org/opensuse-packaging/2017-02/msg00022.html -- Dimstar / Dominique Leuenberger <dimstar(a)opensuse.org>

6 20

Re: [opensuse-factory] openSUSE Leap's Next Major Version Number
by ianseeks 22 Apr '17

22 Apr '17

On Saturday, 22 April 2017 14:00:27 BST Richard Brown wrote: > I don't think you thoroughly read the whole email given the last line asked > responses to opensuse-project(a)opensuse.org, not factory ;) I'm not on the opensuse-project list so i responded to the one posted to tumbleweed. I'll have a read of the list and see if i have anything to contribute. > On 22 April 2017 at 14:53, ianseeks <bingmybong(a)btinternet.com> wrote: > > On Saturday, 22 April 2017 12:37:48 BST Richard Brown wrote: > >> Hi all, > >> > >> On behalf of the openSUSE Board and Leap Release Management I am > >> pleased to announce the next version of openSUSE Leap after 42.3 will > >> be: > >> > >> openSUSE Leap 15 > > > > Oh dear.... This continual rebranding, renumbering and renaming only > > causes > > confusion, it looks like no-one knows what they are doing especially after > > the big-sell of Leap and 42. > > The same happened with the rebranding of KDE5 to Plasma when everyone > > expects common sense to continue with KDE5 as its got so much history and > > its logical to go from KDE4 to KDE5. > > > > I guess it keeps someone busy. > > > >> As with Leap 42.x, minor releases are expected annually for at least 3 > >> years, so you can expect a Leap 15.1 to follow, then 15.2 and onwards. > >> > >> Obviously this is quite a dramatic change from the current version > >> number of 42.x, so I will explain what justifies this change in some > >> detail below. > >> > >> First, some history. When we started openSUSE Leap, the version number > >> was an issue that needed addressing. openSUSE at that time was at > >> 13.2, but SUSE Linux Enterprise (SLE) was at 12 and heading towards 12 > >> SP1. > >> > >> As the main unique selling point of Leap compared to every other > >> distribution is the fact it is based on SLE sources. We wanted to > >> reflect that in the version number. > >> This was particularly important when you consider that a major version > >> in SLE really means something ("major architectural changes from the > >> last version are introduced here") whereas minor versions/service > >> packs have a very different message ("easy to upgrade to, no major > >> workflow breaking changes"). Leap follows a similar philosophy, so we > >> wanted a versioning scheme to reflect SLEs. > >> > >> But openSUSE had already had versions starting with 12, so we couldn't > >> sync up with SLE. This is where 42.x came from. It gave us the > >> opportunity to establish a relationship with SLE versions (SLE Version > >> + 30 = Leap Version), reflect the major/minor nature of Leap releases, > >> and avoid clashes with version numbers we'd already used. > >> The choice of 42 doubled as a humorous nod to hitchhikers guide to the > >> galaxy and the first version numbers of SuSE Linux and YaST (4.2 and > >> 0.42 respectively). > >> > >> The plan was therefore for the next version of Leap to be 43 with it's > >> release aligned with SLE 13, followed by Leap 43.1 (with SLE 13 SP1), > >> Leap 43.2 (w. SP2), etc > >> > >> However, like all good plans, things change. > >> > >> SUSE have decided that their next version of SLE will be 15, not 13. > >> > >> Upon learning of SUSE's plans the Board and Leap release team have > >> been considering our options. > >> This included ignoring the changes to SLE and releasing Leap 43 as > >> planned, at the cost of the link between SLE versions and Leap > >> versions. > >> 45 was also considered, as were some frankly hilarious ideas that made > >> me worry about my own sanity and that of my fellow contributors. > >> > >> After considering the pros and cons of all the options however, the > >> decision has been that Leap 15 will be our next version. > >> > >> SUSE's decision to skip SLE 13 and 14 gave us a perfect opportunity to > >> sync up with SLE versions like we always wanted to originally with > >> Leap. It's an opportunity we will not be able to take so easily a few > >> years from now if we continued with Leaps current versioning. > >> > >> There are only a few packages in our distribution that reference the > >> 42.x versioning, and they should be easily handled as part of a zypper > >> dup, so we are not concerned about this decision impacting users > >> upgrading. > >> > >> We are aware that this decision could be a minor annoyance for users > >> of Leap with configuration management tools like saltstack and puppet, > >> but the long term opportunity to simplify such configuration (by being > >> able to treat SLE and Leap similarly) outweighed our desire to avoid a > >> 'one-time' effort for people currently handling the overly complicated > >> situation caused by Leap being at 42.x and SLE being at 12 SPx. > >> > >> Packagers should be able to look forward to an easier time of things > >> as a result of this change. We intend to deprecate the > >> 0%{leap_version} macro and simplify the current complex nest of > >> suse_version and sle_versions that can make it very frustrating to > >> build packages appropriately for Tumbleweed, Leap and SLE. > >> > >> 0%{suse_version} should continue to be available as a simple indicator > >> of the major version of Leap & SLE for packagers (eg, 0%{suse_version} > >> == 1500 is the expected value for SLE 15 and Leap 15 and all of their > >> minor versions/service packs). > >> > >> 0%{sle_version} should remain as a more precise indicator when > >> packagers need to handle specific versions of Leap and SLE (eg. > >> 0%{sle_version} == 150000 is the expected value for SLE 15 & Leap 15, > >> with 150100 being the expected value for SLE 15 SP1 & Leap 15.1) > >> > >> 0%{is_opensuse} will continue for those times when packagers need to > >> distinguish between Leap and SLE even though they will now more > >> closely share their versions. > >> > >> The above examples and what the future suse_version number will be for > >> Tumbleweed is not yet final, so expect to see emails from ludwig in > >> opensuse-factory(a)opensuse.org when they are set. > >> > >> Thanks to everyone involved in this so far, I'm looking forward to > >> seeing what we make out of Leap 15, and even though I cross-posted > >> this I would like to ask that any followup conversation is kept to the > >> opensuse-project(a)opensuse.org thread. > >> > >> Regards, > >> > >> Richard Brown > >> on behalf of the openSUSE Board > > > > -- > > opensuse:tumbleweed:20170419 > > Qt: 5.7.1 > > KDE Frameworks: 5.32.0 > > KDE Plasma: 5.9.4 > > kwin 5.9.4 > > kmail2 5.4.3 > > akonadiserver 5.4.3 > > Kernel: 4.10.9-1-default > > Nouveau: 1.0.14_2.1 > > > > -- > > To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org > > To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org -- opensuse:tumbleweed:20170419 Qt: 5.7.1 KDE Frameworks: 5.32.0 KDE Plasma: 5.9.4 kwin 5.9.4 kmail2 5.4.3 akonadiserver 5.4.3 Kernel: 4.10.9-1-default Nouveau: 1.0.14_2.1 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0