On 2016-02-06 14:22, Frans de Boer wrote:

On 02/06/2016 01:13 PM, Per Jessen wrote:

I still wonder why Leap was ever conceived. Wishful thinking? Maybe quality is of no concern with OpenSUSE anymore? Tumbleweed was a nice idea, but they use (fresh) factory packages for it to fill it, which - in my opinion - is a sure recipe for trouble.

Well, I use 13.1. Leap doesn't convince me. And Tumbleweed is just the new name for the improved factory, so of course it can't be as stable as any other release. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

Frans de Boer wrote:

On 02/06/2016 01:13 PM, Per Jessen wrote:

...

Frans de Boer wrote:

...

Dear reader,

When I initially tried Leap, the stability was a disaster. So, I went back to Tumbleweed. Which at the time was stable enough. However, from time to time I still have to go back to 13.2 because Tumbleweed is not always so stable.

Leap is now around for some time, so I wonder if it is stable enough nowadays to be used instead of 13.2. The later is kind off showing his age.

Hi Frans

for everyday office work, I would go with 13.2. As for showing its age, you should see my 10.3 workstation (veryyyyy stable though). I have a test desktop with Leap, but it's not reliable.

...

I know now that using Tumbleweed is participating in a lottery, but has OpenSUSE nothing newer to offer which is just as stable as 13.2 is?

Not to my knowledge. Right now, 13.2 is my preferred version.

Thanks Per,

Just as I expected the reply would be. And yes, I had 10.3 before 13.2, but some libraries needed to be updated, which in turn called for many dependencies aka, much manual labor.

Yeah - so far, 10.3 does everything I need it to, and I'm too lazy to upgrade it.

Tumbleweed was a nice idea, but they use (fresh) factory packages for it to fill it, which - in my opinion - is a sure recipe for trouble.

Yes, TW is a playground, something always breaks. Which is fine, TW users know about and (presumably) don't have to rely on it. -- Per Jessen, Zürich (10.9°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 02/06/2016 06:58 AM, Per Jessen wrote:

...

...

Tumbleweed was a nice idea, but they use (fresh) factory packages for it to fill it, which - in my opinion - is a sure recipe for trouble.

Yes, TW is a playground, something always breaks. Which is fine, TW users know about and (presumably) don't have to rely on it.

I've stopped my testing of Leap after finding it sort of unstable, well, more broken than unstable, I guess, as I had the sense not to install BTRFS. I figured I'd get back to leap in a of point releases, or the EOL of 13.2. I have to say that 13.2 is one of the better releases I've seen from Opensuse. In Leap's place, I've been testing the KDE/Plasma5 version of Manjaro. Since Manjaro is based on Arch, and Arch is a rolling release, you would not expect it was targeted at the same user base as Leap. But I've been very presently surprised. Its utterly stable, very robust, and they don't seem to push broken stuff at me, other than they have two installers, one beta, and it does not allocate disk properly, and another that is shared with several other distros, which does a fine job. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 02/06/2016 05:26 AM, Frans de Boer wrote:

Rich, stable means to me "it does not crash to often". Leap does crash(ed?) to often.

Frans

Plasma 5 may have been a "do or die" move. They knew it was going to be semi-unstable, but in the end the move made the most sense as the Qt 5 toolkit is, in most regards, technically better than Qt 4. Now when I say better, I mean in relation to application speed and features available to application developers, and maybe also taking advantage of new CPU instruction sets. It's not better in terms of stability. I can already take note of this because the speed I was getting from my machine pertaining to general desktop application usage was noticeably improved under Plasma 5 over 13.2 on KDE 4.x. Faster on 3+ old hardware, you say? Where do I sign up? I was one of those people who installed the Plasma 5 base system on 13.2 just to play around with it, and what I saw impressed me. I made the decision that I would live with the instability of Plasma 5 because the pros outweighed the cons. I like the look of Plasma 5 over KDE 4, too; it just looks more like a professional clean and "no frills gets business done" executive desktop than the cartoonish looking KDE 4. And in this past few months, I have noticed huge stability improvements with Leap in my machine. I had to tweak Leap on and off since November until I finally got it working right. It came down to some bad hardware I had and some packages I had to cherry pick (actually get rid of with zypper) until it ran well. Since up until just this past week, I had been running Tumbleweed. ymmv. sdm -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 02/06/2016 10:01 AM, Per Jessen wrote:

Plasmashell still crashes regularly though, and I am missing pdf+office previews in dolphin.

Installing kdegraphics-thumbnailers and kdegraphics-svgpart as well as some portions of calligra plugins returns previews of additional files back, specifically pdfs and svg files. Sadly, not odt or doc formats yet. I haven't had a single plasmashell crash on Manjaro. I have had Dolphin crash once or twice, as well as Akregator doing weird things while reading feeds if you leave Automark on. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Dave Plater wrote:

On 06/02/2016 20:01, Per Jessen wrote:

...

SDM wrote:

...

I like the look of Plasma 5 over KDE 4, too; it just looks more like a professional clean and "no frills gets business done" executive desktop than the cartoonish looking KDE 4. Yes, that appeals to me too. I would have liked to keep the screensavers, but no big deal.

Plasmashell still crashes regularly though, and I am missing pdf+office previews in dolphin.

Do you run nVidia graphics card on Leap?

Yes, an Quadro NVS 440. I'm even using 'nouveau'.

and the graphics suddenly became blurry with the nouveau driver. I then went through hell trying to get the propriety nVidia drivers to work

At first, I also tried with the proprietary driver, no big deal, but now nouveau works fine. (for the very few things I do with this box). -- Per Jessen, Zürich (8.8°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 07/02/2016 16:46, Michael Fischer wrote:

On Sun, Feb 07, Dave Plater wrote:

...

My only gripe is not being able to go to any runlevel besides 1 and 5. Is that an effect of some bug, or a "design decision" to make runlevel 3 unavailable in some way?

*confused*

Michael It seems to be a design decision but one I want to change, it made my nVidia hell worse. Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 07/02/2016 18:09, Andrei Borzenkov wrote:

07.02.2016 17:46, Michael Fischer пишет:

...

On Sun, Feb 07, Dave Plater wrote:

...

My only gripe is not being able to go to any runlevel besides 1 and 5. Is that an effect of some bug, or a "design decision" to make runlevel 3 unavailable in some way?

When you finished with conspiracy theories you could explain what you mean. I am just now running 13.2 VM in run level 3, so it is obviously possible. openSUSE:Leap:42.1 doesn't let you select any runlevel apart from graphical user interface runlevel 5 or single user runlevel 1 aka s. Init 3 leaves you at 5 and init 1 or init s takes you to 1. If you have a problem with x on runlevel 5 you cannot kill the x sever and you can only go to single user runlevel 1 with no network access. I found this out when I tried to get my nVidia card working and plasma5 kept crashing. I gave up and removed the card, when I have a lot of spare time on my hands and when I've worked out how to get runlevel 3 back again, I'll try again. Dave P -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

07.02.2016 19:58, Dave Plater пишет:

On 07/02/2016 18:09, Andrei Borzenkov wrote:

...

07.02.2016 17:46, Michael Fischer пишет:

...

On Sun, Feb 07, Dave Plater wrote:

...

My only gripe is not being able to go to any runlevel besides 1 and 5. Is that an effect of some bug, or a "design decision" to make runlevel 3 unavailable in some way?

When you finished with conspiracy theories you could explain what you mean. I am just now running 13.2 VM in run level 3, so it is obviously possible. openSUSE:Leap:42.1 doesn't let you select any runlevel apart from graphical user interface runlevel 5 or single user runlevel 1 aka s. Init 3 leaves you at 5 and init 1 or init s takes you to 1. If you have

I just tested and I can both boot into run level 3 by simply adding `3' to kernel parameters in bootloader and switch to run level 3 from runlevel 5 by using "init 3". In the latter case it indeed does not switch to tty with text mode login prompt, you need manually do Alt-F1. Of course "systemctl set-default multi-user.target" and reboot is always an option. So you need to be more precise what exactly you do and how you try to "select runlevel".

a problem with x on runlevel 5 you cannot kill the x sever and you can only go to single user runlevel 1 with no network access. I found this out when I tried to get my nVidia card working and plasma5 kept crashing. I gave up and removed the card, when I have a lot of spare time on my hands and when I've worked out how to get runlevel 3 back again, I'll try again. Dave P

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 02/07/2016 12:18 PM, Dave Plater wrote:

I see that Yast2 services manager has options for different targets besides graphical but that still isn't the same as being able to enter init 3 to work on x problems.

well when I need to work on X problems such as editing /etc/X11/xorg.conf.d/ files, I hot key to VT1, log in as root, do the edit then use systemctl to restart the DM. There are other ways of doing it. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 07/02/2016 19:28, Anton Aylward wrote:

systemctl isolate runlevel3.target doesn't do anything but you reminded me, rpm -ql systemd reveals this : /etc/systemd/system/runlevel2.target /etc/systemd/system/runlevel3.target /etc/systemd/system/runlevel4.target /etc/systemd/system/runlevel5.target but ls -l /etc/systemd/system/ shows nothing named runlevel* at all. Dave P -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

07.02.2016 20:49, Dave Plater пишет:

On 07/02/2016 19:28, Anton Aylward wrote:

...

systemctl isolate runlevel3.target doesn't do anything

Are you running it as root?

but you reminded me, rpm -ql systemd reveals this : /etc/systemd/system/runlevel2.target /etc/systemd/system/runlevel3.target /etc/systemd/system/runlevel4.target /etc/systemd/system/runlevel5.target but ls -l /etc/systemd/system/ shows nothing named runlevel* at all.

They are %ghost files that are never installed by package itself. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 07/02/2016 19:46, Andrei Borzenkov wrote:

07.02.2016 20:18, Dave Plater пишет:

...

On 07/02/2016 19:11, Andrei Borzenkov wrote:

...

I just tested and I can both boot into run level 3 by simply adding `3' to kernel parameters in bootloader and switch to run level 3 from runlevel 5 by using "init 3". In the latter case it indeed does not switch to tty with text mode login prompt, you need manually do Alt-F1.

Of course "systemctl set-default multi-user.target" and reboot is always an option.

So you need to be more precise what exactly you do and how you try to "select runlevel". You must have a different openSUSE:Leap:42.1 to mine, even typing 1 at start up doesn't stop runlevel 5.

I have no idea what "typing 1 at start up" means, sorry. Do you mean that you literally hit `1' when system boots?

...

I see that Yast2 services manager has options for different targets besides graphical but that still isn't the same as being able to enter init 3 to work on x problems. And what exactly is the difference? Exactly, whats the difference -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 07/02/2016 20:15, Anton Aylward wrote:

On 02/07/2016 12:46 PM, Andrei Borzenkov wrote:

...

I have no idea what "typing 1 at start up" means, sorry. Do you mean that you literally hit `1' when system boots? Assuming grub2 ...

When you see the graphical menu offering whatever versions of the kernel you have installed you hit 'e' to go into edit mode, scroll down to the command line, where it says "boot=" and "swap=" and stuff and add "1" on that line.

The press F10 to continue the boot.

I think I managed that when I had the problem but your other answer is beginning to enlighten me. systemctl is-enabled runlevel3.target does something, it says static. I shall investigate the systemctl commands and hopefully I shall be able to enable runlevel 3 and more. Give a man a fish and he eats for a day, teach him to fish and he'll eat forever (as long as there's fish to catch :-) ) Thanks Dave P -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sun, Feb 07, Felix Miata wrote:

Dave Plater composed on 2016-02-07 20:23 (UTC+0200):

...

systemctl is-enabled runlevel3.target does something, it says static. I shall investigate the systemctl commands and hopefully I shall be able to enable runlevel 3 and more. Give a man a fish and he eats for a day, teach him to fish and he'll eat forever (as long as there's fish to catch :-) )

Under systemd, "runlevels" technically do not exist. The init/telinit [1,2,3,5] commands are compatibility aliases to closest match systemd targets that, I have often found, as you using 42.1, don't do what's expected of them.

Under Leap, does the installer still offer the "runlevel 3" choice? Ok, yes, it is using "back compat language" when it does so, but is the choice there and the upshot on the running system after install the same?

To work around the problem, try using aliases that I use (adjust as necessary for your dm of choice):

alias init3='systemctl isolate multi-user.target; killall kdm; killall Xorg ' alias init5='systemctl isolate graphical.target '

The following may also be helpful:

1: # systemctl set-default multi-user.target 2: reconfigure grub with 5 as last parameter on cmdline, and when you want to boot directly to "runlevel 3", remove the 5 "on the fly" from the selected grub stanza.

Thanks for the tips and tricks. Michael -- Michael Fischer michael@visv.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Am Sonntag, 7. Februar 2016, 19:18:45 schrieb Dave Plater:

I see that Yast2 services manager has options for different targets besides graphical but that still isn't the same as being able to enter init 3 to work on x problems. Does your system complain about not knowing the init command if you type "init 3" ? Then you are probably missing the "systemd-sysvinit" package.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 02/06/2016 08:10 AM, Richard Brown wrote:

On 6 February 2016 at 12:53, Frans de Boer wrote:

openSUSE Leap is more stable, reliable, and polished than 13.2 is. While I admit that Plasma 5 doesn't quite meet the same level of quality as we were used to with KDE 4 in 13.2, our KDE team have done an amazing job of rectifying that and if that isn't good enough for you Leap contains several other desktop environments that you can try - all are equally supported by the openSUSE Project, we're desktop-agnostic after all.

Indeed, I can see that the platform on which any desktop runs has to be 'agnostic'. But the reality is that some of only really perceive and interact with the desktop layer I'm sure if KDE4.14 was the default rather that Plasma5 many of the complaints about Leap would either not have been posted here or could have been more specific. As it stands, I'm sure many people are like Franz, discouraged by the number of complaints here. I am. We've had discussions here about USB3 speeds and many of us such or can get cards with such quite easily. q.v those threads. A proper LiveUSB, as oppose to what seems to be the cutdown versions, something that is 'real' in that it has a number of desktops to compare, can add repositories for out 'pet' interests (audio, video, photography and so on) and really compare Leap to the 13.1/13/2 systems we're running is needed. Install Leap on a USB? I see that Don has been trying that and venting his frustrations here. I'm OK with experimenting and learning the apps I want to use, but as far as the underlying things such as installation go, I want it to work. I may see ways round some of the problems Don raises, but the fact that he raises them at all bothers me. At one time, various magazines, even the ones more oriented to Windows that only looked at Linux out of curiosity, opinioned that Suse has the smoothest, easiest installer. Now I wonder.

If you want a stable openSUSE that doesn't change every day, that's the one to go for

Tumbleweed is not like participating in a lottery. It is the reliable rolling release. It works, it's reliable, but I avoid using the word 'stable' when describing tumbleweed because stable, to me, implies 'not changing', and of course change is part of the point of Tumbleweed

Well, there I have to disagree. Try this; Take the spare tyre out of your car at the top of a hill and let it roll down the hill, Run along beside it. After 30 feet or so try pushing it over. Try dropkicking it over. I assure you, that changing wheel is quite stable! Then again, many of us see 'stability' as "working properly" or perhaps "immune to security flaws" and want the flaws in (a) the specific applications we use and (b) the kernel to be fixed ASAP. Linux has always taken the high ground over security - well perhaps not quite as high as BSD - but a secure kernel is important and that does mean updates when they come out. I use the KERNEL_STABLE repository for that reason and find updates about once a week. We have these option. That is the point. We have options. Your use case may not admit 13.2, but some people have pointed out that 10.1 is adequate for THEIR use case. If we want a system where the updates and upgrades are forced upon us whether we want that or not, where, if we're happy with a particular release or need it for compatibility with some application we have, but have an upgrade forced upon us that breaks it and breaks our business process, then we'd be using Microsoft Windows. That is the point. We have options. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 02/06/2016 02:05 PM, don fisher wrote:

I need Leap for the V4 kernel series which supports my video card, as stated in the nouveau lists.

Pardon me, but you don't need leap in order to run the V4 series kernels. I'm running 13.1 on the machine I'm currently typing at and have been using the v4 series kernels for nearly six months. Linux Mainbox 4.4.0-8.g9f68b90-default #1 SMP PREEMPT Thu Jan 28 08:15:06 UTC 2016 (9f68b90) x86_64 x86_64 x86_64 GNU/Linux No big deal. As I've said a number of times, I'm using the KERNEL_STABLE repository http://download.opensuse.org/repositories/Kernel:/stable/standard/ -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 6 February 2016 at 20:18, don fisher wrote:

On 02/06/2016 06:10 AM, Richard Brown wrote:

...

On 6 February 2016 at 12:53, Frans de Boer wrote:

...

Dear reader,

When I initially tried Leap, the stability was a disaster. So, I went back to Tumbleweed. Which at the time was stable enough. However, from time to time I still have to go back to 13.2 because Tumbleweed is not always so stable.

Leap is now around for some time, so I wonder if it is stable enough nowadays to be used instead of 13.2. The later is kind off showing his age.

I know now that using Tumbleweed is participating in a lottery, but has OpenSUSE nothing newer to offer which is just as stable as 13.2 is?

Hi Frans

openSUSE Leap is more stable, reliable, and polished than 13.2 is. While I admit that Plasma 5 doesn't quite meet the same level of quality as we were used to with KDE 4 in 13.2, our KDE team have done an amazing job of rectifying that and if that isn't good enough for you Leap contains several other desktop environments that you can try - all are equally supported by the openSUSE Project, we're desktop-agnostic after all.

If you want a stable openSUSE that doesn't change every day, that's the one to go for

Tumbleweed is not like participating in a lottery. It is the reliable rolling release. It works, it's reliable, but I avoid using the word 'stable' when describing tumbleweed because stable, to me, implies 'not changing', and of course change is part of the point of Tumbleweed

13.2 is just too long in the tooth for any of my use cases and with too short a supported lifespan (expected end-of-life Jan 2017) for me to realistically recommend to anyone. If it works for you though, that's fine with me :)

TL;DR

Leap for unchanging reliableness Tumbleweed for changing reliableness 13.2 if you're prepared to upgrade in less than 12 months

Rich

Has anybody loaded the devel:libraries:c_c++.repo?

http://download.opensuse.org/repositories/devel:/libraries:/c_c++/openSUSE_4...

That was the last thing I remember doing before my previous Leap system became unbootable. Zypper listed many conflicts, so I rebooted and never could get it back. Could just be a coincidence, but it is a costly experiment to try again. Has anybody else done this?

As soon as are add *any* non-official repository, you are no longer running a 'pure'/untainted openSUSE Leap system You're running your very own custom distribution which is awesome if it works, but if it breaks, you should not blame Leap or the openSUSE Project - it is a problem of your own creation The official Leap repositories are: =Binaries= http://download.opensuse.org/distribution/leap/42.1/repo/oss/ http://download.opensuse.org/distribution/leap/42.1/repo/non-oss/ =Updates= http://download.opensuse.org/update/leap/42.1/ http://download.opensuse.org/update/leap/42.1/non-oss/ =Sources= http://download.opensuse.org/source/distribution/leap/42.1/repo/oss/ http://download.opensuse.org/source/distribution/leap/42.1/repo/non-oss/ =Debug Info= http://download.opensuse.org/debug/distribution/leap/42.1/repo/oss/ http://download.opensuse.org/debug/update/leap/42.1/oss/ Anything else is NOT part of the openSUSE Leap 42.1 distribution. I state this not only from the legal perspective (Leap 42.1 is published under the GPLv2) but also a technical one - only the above repositories are build together, tested together, and therefore should be assumed to work perfectly together Of course, there are other repositories from other sources which, while not 'official', do try and provide packages that can be relied upon for use with openSUSE Leap 42.1 NVIDIA drivers, ATI drivers, Packman, are all examples of community run repositories which at least attempt to maintain compatibility and fully support Leap 42.1 The 'community repos' list in YaST is a good list of these 'unofficial but probably reliable' repositories. Anything else, *especially* any Devel or Home Project in the Build Service Devel projects are *designed* to be broken. They are meant to be where Developers play and break things before sending it to Tumbleweed. If they also build for Leap 42.1 the resulting software packages should be considered to be provided 'as-is', with NO expectation as to whether or not it works or not. If you want something stable with Leap, and if you think Tumbleweed isn't stable enough for you, then I deeply question the logic of anyone who goes to a devel repo to get a new version of a package. Even if they do work for you today, they WILL break for you at some point, unlike in Tumbleweed where we have standards and quality to controls to prevent such breakage. Home repos should be considered with an even higher level of scepticism. Anyone can do whatever they want in there. TL;DR - don't use additional repositories unless you know what you're doing. Don't blame Leap for incompatibilities introduced by your decision to use unsupported software from repositories which make no promises about their quality, stability, or reliability -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 02/06/2016 05:50 PM, listreader wrote:

Real life can't wait for an official patch to be released. So anyone who does actual ordinary useful stuff on Leap must of necessity be "un-pure".

True, and it harkens back to my assertion that bug reports are largely wasted efforts as far as I can tell, because subsequent release will go out the door without them being fixed. You might expect this will something like Gnucash, as not everyone uses it and is not a core opensuse product anyway. But when you suddenly can't boot because the system won't provide enough time for password entry, and you file a bug report and the only official response is that Fink starts a turf war about who's job it is to fix it (963526), it becomes a bit disheartening. If I upgrade, the work around that I did for that issue will almost certainly be lost, or maybe the issue will go away, because Leap is back level, only to reappear when leap catches up. Chrome and Chromium won't launch on 13.2. No other distro has this problem. Bug report and wait for 13.2 to reach EOL? Or find our own solution? Why should any user fret for 2 seconds about "tainting" a opensuse installation, and running some that is (horrors!!!) unsupported when what is supported breaks without warning, and stays broken for months? Mr Brown, I think thou doth protest too much! -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2/6/2016 6:40 PM, Richard Brown wrote:

On 7 February 2016 at 03:22, John Andersen wrote:

...

But when you suddenly can't boot because the system won't provide enough time for password entry, and you file a bug report and the only official response is that Fink starts a turf war about who's job it is to fix it (963526), it becomes a bit disheartening.

The only 'turf' war was caused by you inappropriately and incorrectly filing the bug as a systemd issue (It's a YaST issue, just like you say in the first word of the subject of the bug)

I mentioned both systemd and Yast, because there is no way to know which is responsible, as neither was doing the job correctly.

If you do not know who to assign it to, don't - Nothing annoys our developers more than being given work they don't need to do. We have bug screeners that catch all the bugs in that are not assigned.

I assigned it to exactly who I was told to assign it to.

Also setting the Priority for our developers is a height of bad manners - Bug reporters have the 'Severity' field to declare how important the bug is, it's the right and responsibility for our maintainers to prioritise their work.

The priority field is for the submitter. The proof of that is that the submitter is able to set the priority. I'm permitted to set any field I'm allowed to set, Something that disables my machine is very high priority and i recorded it that way. If the field is something your have decided it yours and yours alone to set, then don't let the user set it.

To be frank, I'm surprised Dr. Fink was as polite to you as he was and fixed the inappropriately assigned bug for you

It is his job, is it not ?

Even taking into account the poor etiquette, the bug was reported on 26th Jan at 04:23 UTC Thanks to Dr. Fink and Thomas Blume, it was fixed by 27th Jan at 06:31 UTC

Its not fixed. If I remove my temporary hack, it resorts to less then 5 seconds of wait for the password. The bug is not closed, the latest updates behave in exactly the same way.

Bug report to fix coded and submitted in less than 29 hours? I'm sorry, bug 963526 is a testament to bug reports _working_ exceptionally well.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 02/06/2016 11:41 PM, tech@reachthetribes.org wrote:

I know it will improve. Whenever there is a big jump, there are more bugs to work out. I have heard that there were a lot of loud complaints when the switch was made from KDE 3 to KDE 4. Now we are into 5.

There was a big difference between 3-to-4 and 4-to-5 if you ask me. KDE4 was released well in excess of a year too early, and made the default install to boot. KDE5/Plasma seems like only maybe a month or three too early, just about everything works today, allowing for some stragglers. Its orders of magnitude less painful than the KDE4 roll-out. In my daily work load, I haven't found anything where K5/Plasma fails me. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Saturday 06 February 2016 21:34:25 Richard Brown wrote:

[…] If you want something stable with Leap, and if you think Tumbleweed isn't stable enough for you, then I deeply question the logic of anyone who goes to a devel repo to get a new version of a package. Even if they do work for you today, they WILL break for you at some point, unlike in Tumbleweed where we have standards and quality to controls to prevent such breakage.

Yes, this sounds right. The problem I see for myself is a slightly different one: The "stable" definition is a tricky one. I like the ideas of rolling distributions and also use them though not everywhere. The problem I see from a user perspective is mainly I am not looking for new versions of applications but just making *any* version of an application available on a system, for the sake of example, say "python-humanize", which is not available in any official repositories for oS13.2, oS L 42.1, or TW. As I would like to use zypper rather than "pip", "easy_install" or "build everything manual and mess up /usr/local" I look on https://software.opensuse.org/package/python-humanize?search_term=python-hum... (or the awesome "osc" plugin to search and install directly from command line) and find the package being available in "devel:languages:python" as well as "home:mimi_vx". Now, I just download the RPM manually but this is more messy than using the package manager which can help me with resolving dependencies so the only option I see left is adding the repo ("devel" being a better choice than any "home" for reasons already stated in this thread) and installing the package from there. I don't see a better way of doing this and Tumbleweed would not have helped in this regard. Obviously, if I have problems with this package I don't blame the openSUSE community part which is offering me the official repositories *only*. Still, I am wondering if from an overall "community" thinking we can improve on how we see additional repositories. I see the point of "devel" repositories, it has "development" in the name. But where else should I have installed "python-humanize" from? Mainly I don't see many differences to the "scratch my own itch" approach which also PPAs in ubuntu and the AUR in arch offers. Oliver -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 02/06/2016 07:58 PM, Felix Miata wrote:

Frans de Boer composed on 2016-02-06 12:53 (UTC+0100):

...

Leap is now around for some time, so I wonder if it is stable enough nowadays to be used instead of 13.2. The later is kind off showing his age.

I waited over a year to upgrade my primary machine from 11.4 to 13.1, proceeding to 13.1 only after 13.2 was released, in order to eventually take advantage of Evergreen. It was not my favorite upgrade. The only upgrade I preferred to the prior version was one of 10.2, 11.0 or 11.2. All were too long ago to remember.

Less than a month after release of 42.1 I "upgraded" from 13.1 to it (via fresh install to different / on md filesystem). I'm glad I did.

On my primary machine the only DE I used and use is KDE3. I use 8 virtual desktops, each with unique wallpaper, something impossible with other DEs I have any familiarity with. I run 7 different windows of 5 different Mozilla products 23.9/7 (I shut the primary down briefly daily to back it up separately), and at times 1 or 2 or even 3 additional. Other than the Mozillas, the only non-KDE3 apps I use are Gimp, LO, and various MM apps from Packman.

For me, 42.1 on this machine seems as stable as anything I've ever used.

Felix, KDE3 is not the choice I made. As for others: yes, using packages from elsewhere is also a risk for stability - no crashes and continues performance. That was not what I used, I used just the basic repositories. But, as with any first release, I mostly skip these first releases because they tend to be somewhat unstable. By renaming the first release a .1 release instead of .0, does not make the system more reliable. It is just a name change, nothing else. Quality does not change because you name the first release a .1 release! So, I ques I wait until Leap 42.2 before I try again. For daily production I keep on using 13.2 and use Tumbleweed as a playground as long as it takes to have a more stable environment. If Tumbleweed is indeed nothing more then a renamed factory, it is unreliable for daily use and I probably will remove it in due time. I very much liked Tumbleweed+KDE+Plasma, but only when it is stable enough. A Rolling release does - in my opinion - not mean it has to be completely/mostly untested. Frans. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 6 February 2016 at 22:33, John Andersen wrote:

I don't consider Tumbleweed to be a rolling release when it is planned to re-base it every once in a while, which implies a pretty major untested upgrade process.

Just as you get used to not having to re install (and you skills get degraded), bank! Tumbleweed re-bases and all bets are off.

Since 4th November 2014 Tumbleweed no longer rebases It is a pure rolling release -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sat, Feb 6, 2016 at 4:04 PM, Frans de Boer wrote:

If Tumbleweed is indeed nothing more then a renamed factory, it is unreliable for daily use and I probably will remove it in due time.

A major automated integration and test system was put in place in 2014. The end result was Tumbleweed. So factory from 2014 and before had basically zero integration testing before it was released to the testers as a factory release. It could be so broken that even booting common setups could fail. That is not true of Tumbleweed. It is put through numerous tests (thousands?) before it is ever released. You should check out the autoQA system. Here's the results from yesterday's build: https://openqa.opensuse.org/tests/overview?distri=opensuse&version=Tumbleweed&build=20160205&groupid=1 Notice all the major subsystems that are tested, but a few failed, so that snapshot won't make it out the door as a Tumbleweed release. Now click through on a test failure. Here's the steps from the chromium failure in Gnome: https://openqa.opensuse.org/tests/118818/modules/chromium/steps/1 Step through it to see where it fails. Look on the left at a list of the steps that the test goes through. Take a look now at the Thunderbird test for gnome: https://openqa.opensuse.org/tests/118818/modules/thunderbird/steps/1 step through its tests to see what is being tested. If you see a critical to you feature not being tested, either write and submit your own test or try to get someone else to do it for you. As more and more tests get added to Tumbleweeds autoQA setup it just gets better and better. == Now remember Tumbleweed has to pass all of those subsystem and component tests before it gets released. (I don't know the exact criteria. Maybe some failures are allowed?) If anyone thinks pre-2015 Factory ever had pre-release testing anywhere close to that they're simply wrong. Greg -- Greg Freemyer www.IntelligentAvatar.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Richard Brown wrote:

On 7 February 2016 at 00:40, Greg Freemyer wrote:

...

<lots of good stuff ending on this point>

If anyone thinks pre-2015 Factory ever had pre-release testing anywhere close to that they're simply wrong.

Well said

Not only that, but since 2014, SUSE have now adopted openQA for testing their enterprise distributions and addons, so it should go without saying that it's effective, broad, trustworthy testing. oooh, I guess we can say it's 'Enterprise Grade' even ;)

(and if anyone is wondering - yes, SUSE actively contribute their SLE test cases back into openSUSE - we have just one shared test suite for SLE/Leap/Tumbleweed which provides the code for those hundreds of scenarios and thousands of different test module runs)

Do you know where one can go to see what's being tested? -- Per Jessen, Zürich (9.3°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sunday 07 February 2016 10:03:28 Per Jessen wrote:

...

Richard Brown wrote:

...

On 7 February 2016 at 00:40, Greg Freemyer

wrote:

...

<lots of good stuff ending on this point>

If anyone thinks pre-2015 Factory ever had pre-release testing anywhere close to that they're simply wrong. Well said

Not only that, but since 2014, SUSE have now adopted openQA for testing their enterprise distributions and addons, so it should go without saying that it's effective, broad, trustworthy testing. oooh, I guess we can say it's 'Enterprise Grade' even ;)

(and if anyone is wondering - yes, SUSE actively contribute their SLE test cases back into openSUSE - we have just one shared test suite for SLE/Leap/Tumbleweed which provides the code for those hundreds of scenarios and thousands of different test module runs) Do you know where one can go to see what's being tested? TL;DR: Yes, Greg already described it, read again :-)

Greg just posted a very nice introduction of how you can get it from openQA but I will try again to explain that maybe from a slightly different perspective even though this would be a more appropriate topic for "opensuse- factory".

Starting from http://openqa.opensuse.org/ you can see what products are currently tested, e.g. Tumbleweed - as a DVD image from Factory snapshot, as well as updates for the releases of e.g. openSUSE 13.2 and openSUSE Leap 42.1. Selecting any Tumbleweed build, say https://openqa.opensuse.org/tests/overview?distri=opensuse&version=Tumbleweed&build=20160205&groupid=1 you can see a table with a column "Test" describing individual scenarios next to green, not-so-green and red bubbles under the column "x86_64", probably the architecture you are interested in. The test scenarios as stated describe which "scenarios" are tested, e.g. starting from top a "RAID0" installation and such. Other scenarios go further than installing trying out if applications work, e.g. "gnome" also testing browsers, etc.. Click on the bubbles to find out what steps exactly are executed in which scenario. If you are interested if a certain application is working fine, say "firefox", this is tested for each Tumbleweed snapshot, as well as e.g. gnucash. So you can be sure that basic functionality is tested every time. If one would encounter a serious issue in one of these applications and it is missed by the openQA tests, feel free to help providing these tests. If you think an application which is not covered should be tested I would recommend to propose it to the openQA test developers first and discuss if and where it should be included. Of course, if we would include all possible applications and scenarios for every product the tests would run too long and we would never get a new Tumbleweed snapshot so a decision has to be made of which importance to a release a certain application is. Certainly, major priority falls to packages included in the DVD image.

If you want to learn more about openQA, go to http://openqa.opensuse.org/, click "Learn more", ask on opensuse-factory mailling list or IRC channel.

Regards, Oliver Under Plasma 5 on TW, there's a quite severe memory leak in X or

On 02/07/2016 02:57 AM, Oliver Kurz wrote: plasmashell (i'm not sure where it lies) that causes RAM usage on my machine to skyrocket to over 5 GB in 12 hours. It's X that consumes the large amount of memory, but from what I've gathered plasmashell can be the culprit and cause X to appear it's leaking memory when it's really not. That makes TW unusable for me at this point in time for a production machine. Everything was fine up until about a month ago, when an updated TW snapshot was released. That's when the skyrocketing X memory usage started happening. On the same machine this does not occur under Leap, and this is with using an ATI video card with the open source drivers installed with Leap. I installed Fedora on a second machine running Plasma 5 for testing purposes, and the same leak occurred so it's not specific to Tumbleweed or my specific machine. The point is, though, that in cases like this, staying a few versions behind allows for greater stability. That's what SLED is all about. Imagine if companies purchased a license to run SLED but SLED with Tumbleweed packages. Does anybody really think that would be a good idea? How is OpenQA going to simulate the myriad of hardware out there where specific hardware can exploit bugs? I'm not buying the whole argument that Tumbleweed is the "tried and true" "stable" desktop. Proof is in the putting, not marketing speak. sdm -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 7 February 2016 at 12:38, Oliver Kurz wrote:

"Staying a few versions behind" can work because others with a close enough environment of yours have hopefully already tried out the new version, reported bugs and fixes have been provided. The probability for this will increase the longer you wait with the downside of missing new features. Eventually also bugs are not fixed anymore for the old version you were intended to jump on.

From the openSUSE developers perspective it's easier to maintain -

This statement has triggered an interested train of thought I wish to share with everyone for their opinions First I want to start by making a few assumptions I believe everyone wants to/should want to run supported software. This means not only that 'it works', but that it is cared for and maintained. By maintenance in this context I mean 'security & functionality issues are found & fixed', and possibly also 'new features and hardware enablement are provided. I realise this isn't true of everyone in every circumstance - but if you're an exception to the above assumption, then it doesn't matter in the context of this discussion as you can pick whatever openSUSE release that suits your use cases. I also wish to make the assumption, more of an assertion really, that open source developers are primarily interested in developing 'new stuff'. The open source model's openness to innovation is what drives contributions to open source software. I believe this to be equally true regardless of the other motivations behind a particular persons contributions. Volunteer, employed, whatever, at their heart I believe the vast majority of open source developers are interested in developing 'new stuff' - whatever that 'new stuff' may be. Maintenance of 'old stuff' is time consuming, complex and often thankless work that often requires more thought and effort than developing new stuff. Some developers may embrace this task to a greater or lesser degree, but regardless I think few would argue with the statement that they would rather be doing 'new stuff'. It is also worth mentioning that 'maintenance' of old stuff often also means resolving integration issues with other parts of the stack that are still moving. This can often be even worse in terms of time, effort and complexity, and sometimes can just be fundamentally infeasible. This leads to a situation where many volunteer led open source projects often make dramatic strides forward while simultaneously reducing/removing the maintenance of previous versions. Plasma 5 is a perfect case study of this approach, with the KDE project abandoning maintenance of KDE 4 relatively quickly. That meant no security and bug fixes from the wider KDE Community. This led to a situation where our openSUSE KDE team felt they had no choice but to adopt Plasma 5 when they did as the alternative (continuing support for KDE 4) would have been way too much work for them to do on their own, especially when considering there are other parts of the operating system that are still moving forward and for good reason (eg. Kernel, udev, systemd for the enablement of new hardware and other pieces of software) I think it's also safe to say that in a good number of Projects, not just desktop orientated ones, there is a trend towards 'fixing things in new versions' and not expending too much effort ensuring that previous versions receive those same fixes. This is a story repeated throughout the open source world, but I believe it to be mostly a fact of life which people either have to accept, or pick up a text editor and get to work fixing it themselves, because the motivation of the current breed of open source software developers is unlikely to change Therefore, considering these factors, I actually think anyone who believes in the 'sticking to previous versions' approach is misguided. If it works for them, great, but the bulk of the collective open source worlds interest, attention, and new lines of code, are all being written for the 'current and next' versions of their software. That's where their interest lies, and focusing our collective efforts and attention on using and improving the quality of what is done there is the only way true progress is made. That said, there is a counter-weight to this situation Enterprise Linux distributions have enterprise customers who are prepared to pay for the stability/reliability they require, which enables companies like SUSE to pay salaries to dedicated maintainers to do that maintenance work that they otherwise would be unlikely to be self-motivated to do But Enterprise distros are a very different beast as a result of this For example, Leap/Tumbleweed have approx 8000 packages in their official repos SLES has about 2500 - All that maintenance really costs a lot of time, effort, and money, so a very broad package selection is not possible. Leap/Tumbleweed has many different desktop environments, because we have a community that is able and willing to work on integrating them all together SLES, and every other Enterprise distribution, all only use GNOME. Because of their very 'rearward facing' approach, the problems they do find, the issues they do fix, are rarely relevant to the upstream projects they are using, as those projects are often months, if not years ahead. It helps their users, and that's the point, their users are willing to pay for it. And so, considering all of this, what does this mean for openSUSE? Well we have Tumbleweed, which fully embraces the idea that you can make a reliable linux distribution even when doing 5 releases a week containing several hundred packags including new kernels. Everything done there is easy to feedback to every other upstream open source project, so not only does it help openSUSE but everyone else. Wishing for the open source world to be slower is unlikely to provide any noticeable result, so there is something to be said about just rolling up ones sleeves, hopping on the boat, and trying to help steer it as part of a crew, rather than trying to go it alone which is a heck of a lot more work. And we have Leap, which takes that very stable, professionally and extensively maintained enterprise codebase and then expands upon it with those community packages. that's 2500 packages less for them to worry about, so they can focus more on maintaining the remainder. But it is still volunteer work, and that work is still heavily impacted upon by decisions by various upstreams. It's not easy, it's not fun, and it's often not that rewarding either. And always, we could do with more help So, maybe if Leap or Tumbleweed isn't hitting your sweet spot, the answer is to start learning how to help maintain those parts of the software stack that matter to you? Join those mailinglists and IRC channels, ask the current maintainers questions. Offer to help. File bug reports. Learn how to file better bug reports. Come to the openSUSE Conference in June and talk to everyone involved. If packages are missing from our distributions, we have published guides on how to get them into our distributions, help them get in. If you can't do it yourself, then find someone to do it *with* you, so you can learn to do it in the future. Adding unsupported repos, or staying with previous versions after they are no longer supported and hoping for things to change isn't going to help things change, and I worry that the people doing that will just find themselves dissapointed in a long run. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 07/02/2016 22:23, John Andersen a écrit :

Who among us couldn't afford $25 (or more) a year automatic pay-pale if the system prompted us on some anniversary date, with a don't show me this again button?

yes we could build a "supporters of opensuse" non profit association, with as goal to sponsor openSUSE jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen wrote:

jdd wrote:

...

Le 07/02/2016 22:23, John Andersen a écrit :

...

Who among us couldn't afford $25 (or more) a year automatic pay-pale if the system prompted us on some anniversary date, with a don't show me this again button?

yes

we could build a "supporters of opensuse" non profit association, with as goal to sponsor openSUSE

I'd be happy to establish and run a "Friends of openSUSE Verein" here in Switzerland, but as long as there is no openSUSE entity to receive the sponsoring, it would be pointless.

Other opensource organisations could be supported obviously - KDE eV, Apache Foundation etc. Per -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Richard Brown wrote:

On 7 February 2016 at 22:58, Per Jessen wrote:

...

...

I'd be happy to establish and run a "Friends of openSUSE Verein" here in Switzerland, but as long as there is no openSUSE entity to receive the sponsoring, it would be pointless.

Other opensource organisations could be supported obviously - KDE eV, Apache Foundation etc.

And what would that achieve? KDE eV, GNOME Foundation, etc, do not hire developers.

Quite so, just as openSUSE does not/cannot. /Per -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 8 February 2016 at 18:38, John Andersen wrote:

...

And what would that achieve? KDE eV, GNOME Foundation, etc, do not hire developers.

And that's precisely the problem, as you pointed out in your longer posting up-thread.

There are already ways to contribute to KDE complete with paypal button, and I've done so at least once a year.

But, if that money is not going to KDE developers (and I do not believe it does), then it doesn't resolve the issues your suggesting your money would solve if it was instead going to openSUSE

The Opensuse site accepts code and hardware. And believe me they wouldn't want the hardware I cast off.

But no way to contribute to Opensuse for paying developers, or maintainers to fix and maintain older stuff, or even tackle bug reports. Opensuse has no "visible means of support" which means its existence is probably subject to the whim of the ownership of Suse, which have seemed progressively less and less likely to be interested with each change of hands.

Opensuse has historically been a testbed for SLES/SLED, but now, with Leap, it seems less so, and more like a Remora, hitching a ride on a shark, and as such dead-weight as viewed by Suse ownership, and the current ownership of Suse has proven themselves a pretty mercenary bunch over the last 20 years that I have had dealings with them. I suspect if the comptroller of Microfocus catches a cold, Opensuse could find itself a fatality.

I really don't like responding to these conspiracy theories, because it provides nonsense like this a credibility it doesn't deserve But for the record, Leap has the full backing of SUSE. It's origins started with an idea that originated within SUSE R&D before being presented to the community, which evolved the concept from that point, but (luckily for SUSE) kept the core concepts which SUSE were hoping to see There is a video recording where I presented this idea at oSC15 - https://www.youtube.com/watch?v=BH99TSrfvq0 To boil the whole thing down to a very crude (and incomplete) picture Leap is a distribution which helps SUSE develop their next service packs (ie. SLE 12 SP2 will be learning lessons from Leap 42.1, while we simultaneously develop SLE 12 SP2 and Leap 42.2 at the same time). Leap is also a perfect platform for SUSE to target the development of their new technologies on, it's shared heritage with SLE enabling it to help their Enterprise orientated development while also contributing directly to openSUSE Tumbleweed is the distribution which helps SUSE develop their next SLE releases (ie. SLE 13 will be based on a snapshot of Tumbleweed some day in the future) So there should be absolutely no question regarding the importance of openSUSE to SUSE.

Side Issue: Why does no one produce a derivative distro based on Opensuse? Yet Arch, arguably a much smaller organization, has dozens of derivatives, some of them rather impressive (Manjaro). Is Opensuse just so good that there is no room for improvement? Does someone actively work to prevent this?

There are openSUSE derivatives. Ignoring the thousands on SUSE Studio the examples that spring to mind are: GeckoLinux - https://geckolinux.github.io/ InvisServer - http://www.invis-server.org/ Paragon OS - http://www.paragonos.net/ No one actively works to prevent derivatives of openSUSE, but I can share one funny story that I think goes some way to explain why openSUSE doesn't have a huge pile of derivatives There once was a distribution called Fuduntu, a fedora based distro that tried to provide a very user focused experience (ala Ubuntu) They decided to discontinue their distribution and instead rebase as a derivative on openSUSE They approached us, asked us a bunch of questions, met a bunch of contributors, all of whom were very welcoming and friendly to this new group of developers who had a very clear vision of what they wanted to do In fact, we were so welcoming, that the developers decided that it wasn't worth the effort of having their own distribution, and they became openSUSE contributors And we're very happy to still have them :) We're the kind of project that does our best to accept as many changes as we can from as many different people as we can, without only a sensible, common sense approach to shared standards, quality, policies, procedures, etc. If we had many derivatives, I'd be worrying that we were doing something wrong - we should be the kind of project that people can influence in the direction they want by contributing to, not by making their own. - Rich -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 02/07/2016 01:54 PM, Per Jessen wrote:

jdd wrote:

...

Le 07/02/2016 22:23, John Andersen a écrit :

...

Who among us couldn't afford $25 (or more) a year automatic pay-pale if the system prompted us on some anniversary date, with a don't show me this again button?

yes

we could build a "supporters of opensuse" non profit association, with as goal to sponsor openSUSE I'd be happy to establish and run a "Friends of openSUSE Verein" here in Switzerland, but as long as there is no openSUSE entity to receive the sponsoring, it would be pointless.

Back when one could purchase SuSE boxed sets with docs, I would buy a dozen at a time and hand them out at work. This served to reward SuSE for a good product and to help spread the Linux gospel. I certainly wouldn't mind donating to development efforts if the funding would really help. I have no idea how this could be done now. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2016-02-08 11:05, jdd wrote:

Le 07/02/2016 22:54, Per Jessen a écrit :

Right now it's only an idea.

what do the readers of this thread think of it? Is it simply worth discussing? if yes we have to open an other thread on project-

Maybe... -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 02/08/2016 08:12 AM, Richard Brown wrote:

I think it's worth pointing out that if you consider the salary, insurance, social services and other expenses of a single developer, it's very easy to reach costs in excess of €100,000 per person

Seems a bit high, unless you are calculating in office space or very high salaries. http://www.bls.gov/news.release/pdf/ecec.pdf Are there not other ways? A laptop here, a NAS there, replace joe's broken monitor, conference travel, -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2016-02-08 19:22, Per Jessen wrote:

John Andersen wrote:

...

On 02/08/2016 08:12 AM, Richard Brown wrote:

...

I think it's worth pointing out that if you consider the salary, insurance, social services and other expenses of a single developer, it's very easy to reach costs in excess of €100,000 per person

Seems a bit high,

It's all relative - in CHF, I would say Richard's estimate is pretty accurate, possibly even a little low.

Then do it on cheaper countries :-P (note: I'm (half) joking) ... as many big enterprises do. Not that I like it... -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On Sunday 07 February 2016 12:35:46 Per Jessen wrote:

Oliver Kurz wrote:

...

On Sunday 07 February 2016 10:03:28 Per Jessen wrote:

...

Do you know where one can go to see what's being tested?

TL;DR: Yes, Greg already described it, read again :-) Greg just posted a very nice introduction of how you can get it from openQA but I will try again to explain that maybe from a slightly different perspective even though this would be a more appropriate topic for "opensuse- factory". […] Thanks for the explanation and the pointers Oliver - I have occasionally been playing with the idea of creating some test cases, but I've not really tried hard enough.

I don't say starting is easy but the people on opensuse-factory are very helpful and it is very rewarding to see "own testcases" being executed by openQA over and over again :-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

John Andersen wrote:

Thing break, you file bug reports. (Although this is often not very effective as the vast majority of bug reports languish until a new release comes out and they they are marked wontfix because they are for an older release, even when the problem persists in the new release.)

I agree although I think it's always worth updating the version and reopening with "problem persists". -- Per Jessen, Zürich (9.4°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org