On Tue, Aug 21, 2012 at 8:29 PM, Arun Khan wrote:

With SuSE Studio (susestudio.com), you can build your own custom images from the official + update repos in several formats like ISO, USB, AWS compatible. You can also add other openSUSE compatible repos like packman + your own RPM files.

thanks for the pointers. now I wonder if the official opensuse releases are also coming from this susestudio (as its a novell site just as well) too? are there the vanilla opensuse projects to be found there anywhere? or am I misunderstanding this stuff? they speak about appliances and stuff, but I wonder if I can install to the harddisk the same way as from the official opensuse iso images? maybe these appliances from susestudio work differently from the way the vanilla releases of opensuse get built and constructed. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tue, 21 Aug 2012 14:22:41 -0700 John Andersen wrote:

There is also this matter of licenses, because some of the builds are based on SLES which is a paid product. Do these not get updates or is is possible to later register them (pay the money) and get the updates thru the normal channels?

Yes, SUSE Studio seems to have the latest updates present for your build and yes registering the system via YaST will enable all the online repositories and update channels. Also as a side note, SLE is a free download, you only pay for either access to online updates or updates/support.

Its a nice service, and seems to work very well. I'm trying it out as a virtual machine before running it for real.

-- Cheers Malcolm °¿° (Linux Counter #276890) SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 3.0.34-0.7-default up 2 days 1:07, 3 users, load average: 0.15, 0.21, 0.40 CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

ok thanks for all the replies, but this is leading me actually not really anywhere in this special term that I have described, I was giving an exact example, that for example darn bugs in perl bootloader scripts, grub or mkinitrd and kernels simply bring down whole stable systems especially when you upgrade them. as you guys have pointed out correctly, the isos never change with opensuse, so I must make a way to exchange crucial packages inside the original iso files from the opensuse project. So I guess I must iso edit them, or take a look at this kiwi stuff or whatever. I mean, logical reasoning would tell me, that if a vanilla release resulting in as iso was doing kinda fine, and patches in contained packes (rpms) were later sorted out, "simply" replacing lower versioned number (small version number increases/patches/fixes) inside the iso with the latest patched versions from the update repo, would still give me a stable iso as the updates and patches never jump that much as to lose functionality, or change fundamentally. after all they are called patches hotfixs and updates. To make this short, I really advocate for opensuse putting more weight onto absolutely delivering "bug-free" crucial packages which are needed for fundamental workings of a systems, so this would be to my limited knowledge, the kernel, the boot process and maybe a few crucial drivers and stacks. All the fancy stuff as with applications, sound doesnt work, or pixel junk (no hangs or crashes ofcourse) or some noncrucial libs missing or source trouble or locales or other stuff, isnt important according to my understanding, as those kind of packages can really be applied from within the basically running system just fine wia even remote access such as network, ssh, zypper and curl wget and whatnot. but when opensuse releases just give crazy output during install/upgrade such as grubdev2unixdev and kill your menu.lst, vlan tags suddenly not working any more in all network devices, or graphics drivers inside the kernel or whatever parts interacting with each other that simply dont bring up the system any more unless you manually need to apply some anti-kernelmodesettings commands in some config places, are completely lethal to my understanding. please opensuse project members, make fundamental packages most important and taken care of, and skip all the rest to later times when these elemental things are really working. greet. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

hello, On Wed, Aug 22, 2012 at 4:45 PM, Carlos E. R. wrote:

No, the method is to add the update repo while you are running the upgrade from DVD. It is not simple, on some releases the procedure does not work for one reason or other.

this sounds like an idea I already had. I normally upgrade my machines from one opensuse vanilla to the next, by inserting iso/cd/dvd media or recently via usb key and boot from those media and upgrade in offline mode. years back, when there was this pae-kernel incident, the upgrade process wouldnt select or something was bad with the kernel packages, or maybe I am mixing up bugs even, but back then I could download from my still working opensuse the latest .rpm for the kernel from the opensuse+1 release and then start the upgrade via cd media and apply the saved rpm before the mess even started. so is there an official way on how to make the install and upgrade process to recognize a locally held repo that would already be populated with crucial patches and stuff that eventually got/will have been released by the time I actually dare to do the upgrade? download all the opensuse+1/updates/ folder to my local disk still running from inside opensuse, then boot opensuse+1 media and then make the upgrade use this downloaded folder as well? any possibilities? its really a pest to suffer from bugs for which later patches might exist, but those still never will easy your pain, and the next opensuse+2 release comes with a whole new set of nightmares regarding the upgrade procedure. thanks for helping. p.s. testing the whole opensuse stuff is one thing, but when already having releases this situation needs to be tackled as well I think, its just no use of letting the users suffer. there should be an easy way to mitigate all the troubles that get found during the lifecycle of the current opensuse products, and people being late to the show and using "ancient" opensuse release media should not suffer from stuff that has been mitigated by patches but that will apparently never make it into official re-releases. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Me too. I don't normally add online repos because my internet connection is slow and it would take ages. But I tried sometimes to have packman enabled, and failed. This last time from 11.4 to 12.1 I haven't tried.

...

so is there an official way on how to make the install and upgrade process to recognize a locally held repo that would already be populated with crucial patches and stuff that eventually got/will have been released by the time I actually dare to do the upgrade? Interesting. It would work via local network, I think.

so seriously, the question is, can opensuse installation processes and applications make use of repositories (even local file/directories) DURING install/upgrade time? whenever I have upgraded an opensuse to opensuse+1, there is some repository summary screen that says all found repos (in the config files) have been disabled for this update/install time. was it ever considered in the workflow and algorithms of zypper, yast and rpm and whatever other parts are taking parts in this installation and upgrade procedures, that it can check its own packages packages inside the iso media AND check an additional repository area if there are any NEWER packages there and use those then instead? this somehow still fails if there is actually an rpm, yast, zypper or such tools affected which are the currently running utilities from the locked down iso image. please do elaborate how I make use of a repo WHILE upgrading/installing from the iso image (dvd/usbkey) itself. also I have many systems that dont use mere ethernet connections to some outside world that could actually fetch a remote repository live on the fly while installing or upgrading, but which are doing xdsl connections directly from this opensuse system itself, and needing the whole networkstack and pppoe or even vlan and combination of these things as a prerequisite to do any network stuff. and I have never so far observed that the installer and upgrader of opensuse would actually use and activate the network into these depths of configuration. maybe the installer and upgrader can use normal eth devices and even do dhcp or fixed lan address or so, but I doubt it can use the configuration stored inside the to-be-upgraded system and bootup its pppoe devices and stuff like that. thanks for helping. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-08-22 07:47, Jim Henderson wrote:

On Tue, 21 Aug 2012 19:22:37 -0500, Rajko wrote:

Nobody seems to be volunteering to even look at taking this on. I'm just hearing "it'd be nice if there were more frequent releases" with what appears to be little to no thought as to what the resource requirements are for actually doing that.

No, this would not be a release. It would be the same distro with updates from the update repo applied already. Same basic version. Applying more updates would be too dangerous. There is a slight danger that something would break in an untested manner, so both dvds would have to be in offer, and this might be a problem with mirrors. But it would be nice to have. Recently I updated my system from 11.4 to 12.1. After doing the upgrade with the DVD, I still had to apply two big updates, one of them 1.7 gigabytes and the other a bit less. Almost a dvd. - -- Cheers / Saludos, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA07/sACgkQIvFNjefEBxqwtQCfVYRhTDxSwdVBl+fqcbXMtS7O BqwAn2h/Afhg3iU/mrP4Za//Vx3taI4B =5W/d -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-08-22 17:23, Jim Henderson wrote:

On Wed, 22 Aug 2012 16:43:07 +0200, Carlos E. R. wrote:

It would still require testing, or there would be the chance that something went wrong in the mastering process and the ISO wouldn't boot or work properly.

And of course, sometimes updates introduce regressions, so you'd need to make sure no regressions were introduced that made things worse.

Which is why I said that both DVDs should be in offer, and the other offered as an "minor" or experimental alternative. The people installing that would do the testing and reporting :-) I understand that that susestudio does this updating automatically when it generates the iso, perhaps it is not that difficult to generate that ISO. It is the ensuring that it is correct and the mirrorring that has issues. - -- Cheers / Saludos, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA1BgkACgkQIvFNjefEBxpungCeNqQ/pKMvlwmwGf43kR0+DG9o k8YAoLs3b/PMx8yHzkeESUdkJ9/m4n5u =5rfT -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-08-22 18:31, Jim Henderson wrote:

On Wed, 22 Aug 2012 18:17:13 +0200, Carlos E. R. wrote:

The point of the exercise, though, was stated to be to reduce the frustration new users have when downloading the original GM media.

Now if this "experimental" idea results in more frustration because it doesn't work, then isn't that going to result in people giving up? If they have to download the ISO twice to get something that works for them.

Better to catch those problems during the actual release beta cycle, isn't it?

That is never going to happen. The real testing phase is the first month after the release, and that is a fact. A release becomes usable after two months of release, when the devs have cured the problems discovered in the first month. And those updates are tested a lot, too. - -- Cheers / Saludos, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA1Fn8ACgkQIvFNjefEBxrHBQCglLoSKQJy2gXUX+4qPVjbGr+4 BpEAn3S4XvkfQdt9i3KQQ8S51VZOZuN+ =meaj -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-08-22 19:45, Jim Henderson wrote:

On Wed, 22 Aug 2012 19:27:27 +0200, Carlos E. R. wrote:

...

...

Better to catch those problems during the actual release beta cycle, isn't it?

That is never going to happen.

It sure seems like in general it /has/ happened. We haven't really had any serious issues with not being able to install on most hardware. ISTR one release that had that happen (11.3, maybe?).

I mean bugs with packages, most are found later.

...

The real testing phase is the first month after the release, and that is a fact. A release becomes usable after two months of release, when the devs have cured the problems discovered in the first month.

And those updates are tested a lot, too.

They're not tested on install media, which is kinda my point.

I know, but I prefer to guess that issues would be few and worth a try. Maybe one sub-release at midterm. - -- Cheers / Saludos, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA1HYIACgkQIvFNjefEBxoKmACgw020+ih/gAHXJ2t34FdI4oRy Ci8AnibJpph6/oFGif1g1RGUM/UoLT/P =Doyc -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-08-22 22:09, Jim Henderson wrote:

Which again requires more than just the idea that "maybe someone should do this", but someone to actually step up and say "hey, I'm willing to give this a try". Or for that matter, for someone to say "I'd be happy to put together an unofficial updated interim release to see if this could work."

Yes. - -- Cheers / Saludos, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA1PzAACgkQIvFNjefEBxrokwCcDVo/x4xy8kScCjLMthodMfJ4 KqIAn1nCwuuJAPtqMD2vIylQDTmLDHHW =gn91 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, 22 Aug 2012 20:53:21 -0500, Rajko wrote:

One guy, after long discussion like this, actually created updated iso using SUSE Studio, and iso worked as expected, but interest was not so great.

The problem is a trust.

In other words common wisdom that one should go and do it, doesn't work without trust relationship.

It comes back then to a question of allocating a resource or otherwise solving that trust issue. It's not just a question of "hey, someone in the project should do this". Resources are finite, and until it becomes either a high enough priority that something else loses the resource *or* an additional resource is added to manage this, it ain't gonna happen. So how do you propose actually solving the problem? Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org