There is dash ( http://en.wikipedia.org/wiki/Debian_Almquist_shell ) and ash-static which - I believe - is the same thing. There is also, of course, busybox. It seems to me that having something like busybox or ash (static) as a shell-of-last-resort is not a horrible idea. On Mon, Apr 1, 2013 at 3:33 PM, Greg Freemyer wrote:

On Mon, Apr 1, 2013 at 4:08 PM, Linda Walsh wrote:

...

I had a problem a few weeks ago where I was having libc problems booting off a rescue disk -- used to be I could usually boot from a rescue disk, mount root on /mnt, chroot /mnt, mount the rest, and look at startup scripts 1-by-1.

Now that doesn't come close to working. But even when I got the paths set right (LDLLIBPATH) etc... BASH/DASH/SH/ were still having problems loading due to suse's adding OW's patches that make linked binaries incompat with standard libc/glibc I.e. -- instead of a dynamic load of OW, and giving reduced functionality, it was hardcoded in to prevent anything from working. Ok... so I thought -- AH

Standalone shell... it doesn't depend on anything.

SURPRISE -- it's now dynamically linked with a custom libc as well...so it wouldn't work either!

Um...

FAIL!!!!

SASH is called SASH because it is supposed to be Stand-Alone and need no libs to link as well as having builtin basic commands:

Manpage: DESCRIPTION The sash program is a stand-alone shell which is useful for recovering from certain types of system failures. In particular, it was created in order to cope with the problem of missing shared libraries or impor- tant executables. ^^^^^^^^^^^^^^^^^^^^^^^^

Um...HELLO... breaking basic functionality?

Had a bitch of a time recovering since xfsdump bumped it's version num to '3' to correct several kernel bugs. For some reason my xfsrestore's even from the disk kept saying '2'... Well it appears I couldn't run xfsrestore from any repair disk as they all had v2 of the libs (v3 appeared in mid Jan). But I couldn't link with the new versions on disk due to libc problems.

Finally was able to rebuild xfs from git running on the repair disk and install xfsrestore onto the repair disk where the libc wasn't corrupted with a non-standard OW extension.

But, that was an aside. Um...main beef .. NOT EVEN SASH?!?! statically linked?

system recovery tools like xfsrestore likely should be too (as an afterthough/aside)...

Linda,

Can't say I've ever worked with sash, but per the changes file it has to dynamically link with libc:

== Wed May 6 15:44:12 CEST 2009 - crrodriguez@suse.de

- while using static libz will work, using static libc wont, due to the use of getgrgid, getgrnam, getpwnam and getpwuid. ==

That's from 4 years ago, so maybe upstream has a fix for that by now. I checked and Fedora doesn't have sash package, so maybe they dropped it since it doesn't build statically anymore.

The home page for the project is http://members.tip.net.au/~dbell/

It doesn't look like there has been an update in 6 years or so. As it stands, I don't see a value in the project, so it seems someone needs to either fix it to be static or drop it.

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

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

El 01/04/13 17:50, Jon Nelson escribió:

...

It doesn't look like there has been an update in 6 years or so. As it stands, I don't see a value in the project, so it seems someone needs to either fix it to be static or drop it.

I think a drop request has to be filled in this case, there is dash/ash as replacement for a minimal shell. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Cristian Rodríguez wrote:

El 01/04/13 17:50, Jon Nelson escribió:

...

There is dash ( http://en.wikipedia.org/wiki/Debian_Almquist_shell ) and ash-static which - I believe - is the same thing. There is also, of course, busybox. It seems to me that having something like busybox or ash (static) as a shell-of-last-resort is not a horrible idea.

Not really, people should just jump into the initrd.

If libc is broken nothing will work, your are screwed and that 's the end of the story.

Wow... I guess I never recovered. My libc wasn't broken --- all the suse binaries were. I had the standard libc from gnu... latest and greatest -- with complete backwards compat -- just like I told was needed/provided with it... Of course none of the SuSE apps are backwards compat with libc... but hey...can't have everything right? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Greg Freemyer wrote:

Linda,

Can't say I've ever worked with sash, but per the changes file it has to dynamically link with libc:

--- I hadn't either -- much, but remembered it was supposed to be a last-resort tool... my surprise...

Wed May 6 15:44:12 CEST 2009 - crrodriguez@suse.de

- while using static libz will work, using static libc wont, due to the use of getgrgid, getgrnam, getpwnam and getpwuid. ==

---- Great... if I could reached the CHANGES file (on an unmountable partition due to libc being out of commission)...that would have helped... NOT! Why do getgrgid geeetgrnam getpwnam and getpwuid not build static? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El lun 01 abr 2013 18:56:56 CLST, Cristian Rodríguez escribió:

El 01/04/13 18:23, Linda Walsh escribió:

...

Why do getgrgid geeetgrnam getpwnam and getpwuid not build static?

This is by design, it is intended that way.

see http://www.akkadia.org/drepper/no_static_linking.html bullet points 4 and 5 but I suggest you to read the whole article. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 01/04/13 19:29, Linda Walsh escribió:

Show me a reliable source. Not some ranting page.

That's a reliable source, that page was written by Ulrich Drepper, that is the guy who wrote most of actual glibc code. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 01/04/13 19:48, Yamaban escribió:

On Tue, 2 Apr 2013 00:33, Cristian Rodríguez wrote:

...

El 01/04/13 19:29, Linda Walsh escribió:

...

Show me a reliable source. Not some ranting page.

That's a reliable source, that page was written by Ulrich Drepper, that is the guy who wrote most of actual glibc code.

I know Ulrich since around 1997. He can rant, and he has done so.

To be fair, that page was originally written when there was a fad of statically linking nearly ever thing.

For a up and running system, with out the "super SUSE special" add-ins, he is still right.

Recovery tools are an whole other beast.

Every system should have ONE fully static shell for this case.

I don't think so, for rescue, the boot process should stop and switch root into the initrd, where you can find a working shell. if the initrd is the broken piece, then you will have to boot with a live cd/dvd/usb to fix the system. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 2013-04-02 01:14, Yamaban wrote:

Remember how the initrd is build: broken system, broken initrd.

Murphy will really be your bossom friend with such thinking.

If your libc is broken, you probably won't even get to generate a faulty initrd, hence the original one prevails. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 01/04/13 20:50, Jan Engelhardt escribió:

On Tuesday 2013-04-02 00:48, Yamaban wrote:

...

Every system should have ONE fully static shell for this case.

What's the point of having a working shell if you can't call (m)any programs?

that's exactly right, to do almost any kind of meaningful repair you need to execute binaries that are dynamically linked, not only to libc but to other different libraries. (libz, lzma, crypto and long etc..) A modern linux system just does not work in the old-fashioned way that having a shell around was a get-out-of-jail card for mistakes. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 01/04/13 23:59, Linda Walsh escribió:

By modern, you mean any that are ~ suse 12.2 or later, or about a year old?

Likely something made in the past 5 years..

Or, um yeah.. moving any and all recovery tools off of root to 2ndary partition...

Or not having a clue why glibc can't be build statically for files in /bin or /sbin (or some of them anyway?)...

It can link statically.. but dynamic linking is required for certain functionality, this is a design decision, it is the same in all distributions.

Or not having a systemd that supports booting --

Systemd is not a bootloader, however it does interface with UEFI bootloader "gummiboot". only loading

system services? (and shoving the rest into hiding in a ramdisk that people are expected/required to use)....

Yes, an initrd is required, this is also on purpose, a design decision to make maintenance and development of the distribution easier, developer time and resources are limited.

Can anyone name the benefits of putting the files that used to be in /bin in /usr/bin and replacing them with symlinks? Same for /sbin and /lib64 that couldn't have been solved by putting the originals in the root dirs and symlinks in /usr?

http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge

Still haven't seen a good reason for requiring dynamic linking of the libc routines getXXX when the network is down and services aren't running.

So you did not really read anything on the link I sent to you, or most likely you dont want to listen. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, Apr 01, 2013 at 11:07:17PM -0700, Linda Walsh wrote:

Cristian Rodríguez wrote:

...

It can link statically.. but dynamic linking is required for certain functionality, this is a design decision, it is the same in all distributions.

---

1) What functionality? What functionality is needed BEFORE the network is turned on, or Before the the disks are mounted?

The NSS (nameservice switch) modules are configurable via configuration files and so are loaded dynamically. man nsswitch.conf Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Claudio Freire wrote:

...

Worse, I'm not even allowed to upgrade from suse packages from different versions!... (or so some, including you have told me).

Yes you can. That you don't know how to isn't something to be bitching about.

Oh, You and Christian need to get on the same page. Try upgrading libperl from 5.16.0 -> 5.16.1, .2 or .3 They are ALL binary API compat -- str8 from the perldev's mouth. Even the major versions, for many purposes, OFTEN have been -- **BUT**, a simple cpan -r or cpan upgrade has never failed to bring modules in sync with the current perl for any of my modules.

You can't build just any version of the libs, you've been told that, although it's pretty well known. You need a binary-compatible replacement,

The above ARE binary compat, but Suse has version checks in the products like gvim to disable their functioning if your version is off. As for libc - the only reason I tried building that myself initially, was to get a version that was 'the latest' that would support 14, 15, 16 the next (17). So I wouldn't have to worry about libc compat if I wanted to switch up in versions. and for that you may want to start by applying

openSuse-specific patches.

Like the ones that break normal functionality applied to BASH or break parallel sorting?

If your libs don't work without the patches, it means the patches are needed for binary compatibility. You don't want the patches? Tough luck.

It's not the patches that are needed but symbols that are needed -- If I don't use features you have bound in, the code doesn't travel those paths. It's like in gvim when configured correctly, -- if I don't use python, it doesn't load it -- so the binary version doesn't matter. If the OWL extensions had been put in their own lib and dlloaded at run time, I wouldn't have to worry about patching them or including them.

Since you seem to love building your own stuff so much it's a wonder why you're not using Gentoo. Really. I don't use Gentoo because I don't want to spend my life building stuff, but you are, so... why not? It's not an attempt to get rid of you, it's just puzzling and I'd like to know. -- I don't take it as an attempt to get rid of me.

I don't like building EVERYTHING. I have a few things I care about and use in my development or to run my system. I've used shell and perl scripts to automate and run most of the stuff I do on my system Shell for simple, perl for more complex. I generally rebuild my kernel for efficiency and trying out new features.

In any case, binary compatibility is a delicate beast.

Only when it is built in a fragile manner. I didn't have anywhere near these problems the farther back we go. 11.x didn't have so many troublesome interlocks. 10.x and 9.x I remember as being generally golden. 8.x -- 7.x -- 6.x, getting too far back to remember. the details. But never the problems I've had in the 12.X series..

So... you broke it. It's no wonder, it's easy to break.

It wasn't so easy if you just a we bit careful and willing to clean up after yourself back in the 11.x and before series. Now, everything is booby trapped -- no more looking under the hood. You seem to always start from

pristine upstream tarballs, configure && make,

Actually, the only things I have done that for were the kernel, and perl. First exception was when suse released transmission with certain features disabled. Latest version I'm running from a modified rpm. I've got other things I want to be doing than to to do than maintain my computers 24/7, but if they aren't working right, it's hard to do many of the things I like doing.

that's not the way to get binary-compatible replacements for a whole distro installation. You want to start with RPM sources. You want to read the SPEC file, and follow it.

I usually do, but the specs have been a source of problem when they say: req: prod (version=x) Not req prod or rec prod (version>=x), but locking them together. As to return to the title of this email -- IT WASN'T ME who broke binary compatibility --- christian said it was suse that did it by design -- intentionally based on the advice of a 2 year old webpage. If suse can't keep binary compatibility in keeping the Stand Alone Shell, stand alone, why would you lecture *ME* on keeping it? Note -- the SASH isn't standalone just because of linking -- it had many of the basic core util functions built in -- that's what made it stand alone. I.e. replacing it with dash would be entirely inappropriate. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Apr 2, 2013 at 4:57 AM, Linda Walsh wrote:

...

If your libs don't work without the patches, it means the patches are needed for binary compatibility. You don't want the patches? Tough luck.

---

It's not the patches that are needed but symbols that are needed -- If I don't use features you have bound in, the code doesn't travel those paths. It's like in gvim when configured correctly, -- if I don't use python, it doesn't load it -- so the binary version doesn't matter.

If the OWL extensions had been put in their own lib and dlloaded at run time, I wouldn't have to worry about patching them or including them.

No, you're completely wrong there. Take it from someone that actually does some coding for his livelihood, any kind of patch has the potential to break binary compatibility. You'd have to know how C works pretty well to be able to decide whether one in particular does or does not. It's not just about the symbols. If you want to remove patches, remove them one by one and test thoroughly afterwards. Especially patches touching C code. On Tue, Apr 2, 2013 at 4:57 AM, Linda Walsh wrote:

and for that you may want to start by applying

...

openSuse-specific patches.

---

Like the ones that break normal functionality applied to BASH or break parallel sorting?

All the ones you don't need to remove, keep them. They're quite likely modifying the lib's ABI, so you have to keep them.

...

In any case, binary compatibility is a delicate beast.

---

Only when it is built in a fragile manner.

No, it's been pretty much the same ever since K&R. Well, it worsened a bit with C++, but it's gotten easier since then thanks to versioned symbols. What you see is the effect of increased systems complexity making stuff less predictable to mere mortals. A compiler knows best, and there's the value of a distribution and automated build systems.

...

that's not the way to get binary-compatible replacements for a whole distro installation. You want to start with RPM sources. You want to read the SPEC file, and follow it.

---

I usually do, but the specs have been a source of problem when they say: req: prod (version=x)

I'm mostly referring to build/install scripts and the patches, not so much about the requirements (though you probably should pay attention to them, just not that specifically).

Not req prod or rec prod (version>=x), but locking them together.

There's probably a reason though. The package's ABI must be especially unstable, and backwards compatibility especially unreliable for the packager to do that. I know I've had to do that for some subpackages because they're tightly coupled with the main package.

As to return to the title of this email -- IT WASN'T ME who broke binary compatibility ---

Yes, it was you. You installed a broken libc, if I read the OP correctly. Broken by you by not building it to openSuse specs. Distros don't promise any kind of binary compatibility, not to upstream and not to other distros, except on LSB components, and, IIRC, there's a separate libc for LSB.

christian said it was suse that did it by design -- intentionally based on the advice of a 2 year old webpage.

OpenSuse broke compatibility with upstream, but that's not breakage of any kind, just a design decision, because libc works just fine within openSuse with openSuse pacakges. So in conext "you broke binary compatibility" means "you built a libc that didn't match opensuse's libc's ABI". It's you the one that has to conform to openSuse's ABI now, when you try to replace an openSuse component, and not the other way around. If that bothers you, really, you need another distro. Not sure there's any distro that will satisfy your wish of upstream-compatible ABIs. I'd wager those would be immature distros, but it's up to you. In any case, you'd be wise to test this not by installing a modified libc on your system, but by mangling LD_LIBRARY_PATH or chrooting or something of the sort. Just saying. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Claudio Freire wrote:

On Tue, Apr 2, 2013 at 4:57 AM, Linda Walsh wrote:

...

...

If your libs don't work without the patches, it means the patches are needed for binary compatibility. You don't want the patches? Tough luck.

---

It's not the patches that are needed but symbols that are needed -- If I don't use features you have bound in, the code doesn't travel those paths. It's like in gvim when configured correctly, -- if I don't use python, it doesn't load it -- so the binary version doesn't matter.

If the OWL extensions had been put in their own lib and dlloaded at run time, I wouldn't have to worry about patching them or including them.

No, you're completely wrong there. Take it from someone that actually does some coding for his livelihood, any kind of patch has the potential to break binary compatibility.

In this case, you are wrong. The same patch went into glib 2.14, 15, 16 and 17. The patch hasn't changed. That means since glibc17 includes binary compat for glib2.14, if suse had put it into a separate library and not modified the standard glibc, there never would have been a problem. You'd have to know how C

works pretty well to be able to decide whether one in particular does or does not. It's not just about the symbols.

I know C pretty well. I've kernel code, compiler code interpreter & graphics code, networking (before TCP/IP). Worked in 8080/8085/x86 assembler as well as I worked at intel in their compiler group. My degree is in computer science -- so I had an engineering degree background to back up my job experience -- not something alot of people writing code today can say. I owned and programmed a and worked on a 4.77MHz PC, original IBM, got through an Intel price break. I have a passable to mediocre knowledge of much of the computer science field. People outside the computer industry consider me an expert, but I wouldn't call myself that. There's way too much to know to be an expert except in very narrow knowledge areas -- and my interests are spread way to widely to become an expert in any of them. In the specific example, suse created unnecessary binary incompatibility between the standard libc and theirs. If they had put it in a separate library, that could be run-time loaded, Perhaps via modification of the LD_LIBPATH, then they could have had the binary compatibility with glibc that vendors would like. But so many utils wouldn't load because they couldn't find a symbol "OWL_1.0" - a 3rd party crypto addition. Most of those utils had no need for encryption. So I maintain that bundling such things is a major headache for users who try to support 3rd party tools (or write them).

...

Like the ones that break normal functionality applied to BASH or break parallel sorting?

All the ones you don't need to remove, keep them. They're quite likely modifying the lib's ABI, so you have to keep them.

Nope they were both bugs that disabled standard functionality.

There's probably a reason though. The package's ABI must be especially unstable, and backwards compatibility especially unreliable for the packager to do that.

Except that it's not. The ABI is guaranteed stable over the minor releases in perl, for example, yet suse locks many products into minor versions requiring upgrading an entire distro to upgrade your perl.

Yes, it was you. You installed a broken libc, if I read the OP correctly. Broken by you by not building it to openSuse specs.

By having 'cat', cp, ls all require a crypto lib, suse is breaking things unnecessarily. You can claim I broke it because I didn't add crypto into a lib for cp or cat or whatever... BUT those things don't use crypto and I don't use the crypto in that lib! Suse broke it first by force all utils to be dependent on mandatory crypto symbols bundled into libc. They are NOT depedant on the crypto CODE, they are only dependent on the extra added symbols added at link time. That's deliberate breakage of 100's of programs that don't need to be broken. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt wrote:

It's time to cut the crap.

Yes, it is.

Three packages ... pam... How many packages and libs depend on PAM and will fail to load because the sym isn't there:

the pam one is due to pam_unix2.so

afs5log chage chfn chsh cimmof cimmofl cimprovider cimsub crontab kdm libCIMQueryCapabilitiesProvider.so libCIMQueryCapabilitiesProvider.so.1 libCIMxmlIndicationHandler.so libCIMxmlIndicationHandler.so.1 libCertificateProvider.so libCertificateProvider.so.1 libConfigSettingProvider.so libConfigSettingProvider.so.1 libDefaultProviderManager.so libDefaultProviderManager.so.1 libNamespaceProvider.so libNamespaceProvider.so.1 libProviderRegistrationProvider.so libProviderRegistrationProvider.so.1 libUserAuthProvider.so libUserAuthProvider.so.1 libpam.so libpam.so.0 libpam.so.0.83.1 libpam_misc.so libpam_misc.so.0 libpam_misc.so.0.82.0 libpamc.so libpamc.so.0 libpamc.so.0.82.1 libsnmpIndicationHandler.so libsnmpIndicationHandler.so.1 libuniconf.so libuniconf.so.4.4 libwvstreams.so libwvstreams.so.4.4 libwvutils.so libwvutils.so.4.4 lxdm osinfo passwd pkexec ssh-keyconverter su uni vtysh wbemexec wvdial wvdialconf xdm (55) How many of those are libs? 33... if 1 lib's fail prevents loading of 22 progs and 33 libs, how many more will the rest block? libpam by itself is bad enough -- that affects a much larger number of programs ssh --- However, note, I DID say this happened a few weeks ago when I was still mostly in 12.1 w/a few 12.2 packages to support the virt-machines (kvm?) that was used in every security util before 12.3. 12.3 replaced it with pam_unix... I went through the rpmsaves/rpmnews to fix all of them. with pam_unix2 linked into every security relevant prog, you are pretty well screwed. I count 76 progs in /etc/pam.d... without those progs you are VERY screwed because you are locked out of the system. So um... tell me about this crap you are cutting? If you can't run any prog to do with UID/GID, accounts, authorization or session validation, What can you run? You think I was exaggerating? It was seriously screwed.

$ rpm -e glibc --test 2>&1 | grep OW_ libcrypt.so.1(OW_CRYPT_1.0)(64bit) is needed by (installed) whois-5.0.11-12.1.1.x86_64 libcrypt.so.1(OW_CRYPT_1.0)(64bit) is needed by (installed) pam-modules-12.1-16.1.1.x86_64 libcrypt.so.1(OW_CRYPT_1.0)(64bit) is needed by (installed) yast2-core-2.23.4-2.1.1.x86_64

But you have to put int a special symbol in the heart of your security and sysadmin (yast) to make it incompat with a standard glibc. PERFECTLY SUSE'S right -- but it is a HUGE Gotcha when one is told glibc is upward compat -- and you hope to try loading a glibc that will be 'compat for all'... The OW_CRYPT stuff really can't be in its own lib?

You can blame perl for that, because its default search path contains the exact version only (e.g. "5.16.2" in case of openSUSE_12.3) rather than a generic "5.16".

The **default** build of perl includes all the dirs of the previous release. Suse strips those out. **** So no -- that's SQUARELY a suse thing**** binding libs of perl/python and ruby in w/your system's text editor--- all suse. I even did the legwork for you you and posted the patch in the bug report -- but it's short enough to include here... cleaned up a few bad dependencies while I was at it... diff vim.spec vim.spec.dyn 42d41 < BuildRequires: systemd 57,58c56 < # Explicitly require versioned perl for libperl.so < %define perl_requires perl = %(rpm -q --qf '%{VERSION}' perl) ---

%define perl_requires perl 318,320c316,318 < --enable-perlinterp \ < --enable-pythoninterp \ < --enable-rubyinterp \

--enable-perlinterp=dynamic \ --enable-pythoninterp=dynamic \ --enable-rubyinterp=dynamic \

-------------- gvim didn't not fail due to a directories problem. It specifically looked for an exact version at install and at RUN time.... it was broken by design (it was designed to break if the user tampered with their system perl). You even have a dep on systemd?!?!?? WTF? gvim doesn't require systemd anymore than it required the sysVinit scripts -- but someone was very determined to make systemd required... just try to do an install w/it banned, and watch the 100's of conflicts that run fine w/o it installed! But lets pretend for a moment that perl's default DIDN'T include the previous release's dirs (but it does)... Suse still knows well how to use symlinks: /usr/lib/perl5> ll total 8 lrwxrwxrwx 1 6 Mar 14 11:03 5.16.0 -> 5.16.2/ lrwxrwxrwx 1 6 Apr 2 22:25 5.16.1 -> 5.16.2/ drwxr-xr-x 61 4096 Mar 26 17:21 5.16.2/ drwxr-xr-x 4 76 Apr 2 22:25 site_perl/ drwxr-xr-x 6 117 Apr 2 22:25 vendor_perl/ Have we cut the crap yet? Would you like cheese on that? I'm citing facts here -- I don't care how these things got this way -- but I know they don't have be deliberately broken. and Christian said to 'do' something? I'm submitting bug reports and patches. I'm telling you how it can be done to get what you want and preserve compat... all I get is a HUGE amount of grief. ;^/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 04/02/2013 03:07 AM, Linda Walsh wrote:

Cristian Rodríguez wrote:

...

It can link statically.. but dynamic linking is required for certain functionality, this is a design decision, it is the same in all distributions.

3) The functionality you want to provide could be provided in run-time loadable binaries -- so they only memory usage would be for those services the user actually is using!

That's exactly how it works.

That's nice for those wanting to convert to UEFI boot, however, for the majority of users *now*, you required a hack in order to boot.

There is no hack required, just a bootloader plus an initrd.

You required it because of the switch to systemd --

No, and initrd is required since long time before systemd..

This is so typical of suse -- switching to new techs and having to drop support for old techs that people use --

why you are still here then ?

I can't replace a DSO without 100 apps complaining that they need some 'SPECIAL' version of the DSO....

as expected and designed ! nothing wrong here.. what part you still dont understand ? You can replace a DSO with an updated/improved version of *THE SAME DSO* with a compatible ABI not with some arbitrary version.

None of the other stuff he wrote is important if you are in single user. Saving memory? It's running in 'S' or '1'. Security problems? I'm not connected to a network (yet).

exactly, because that not the point, the point is to make *OUR* job easier. as developers and maintaners of a HUGE codebase. That page is very Dated..... over 2 years old

(2.5 years).

Still relevant and applies today. If it was that great of a 'meme', why hasn't anyone else spoken up

in support showing further support?... a lone wolf posting in 2010....

the lone wolf wrote the current libc code almost by his goddamn self, kinda relevant to listen to the people that actually knows how things work.

The only reason I speak strongly about these things is I KNOW they can be better.

I dont give a rat's ass if you think you know things can be better, I only care if you MAKE thinks better. your baseless rants are not an step into making things better, and I stronly suggest you stop. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 04/02/2013 05:12 AM, Linda Walsh wrote:

Cristian Rodríguez wrote:

...

...

That's nice for those wanting to convert to UEFI boot, however, for the majority of users *now*, you required a hack in order to boot.

There is no hack required, just a bootloader plus an initrd.

---

bootloader yes -- initrd is a hack to allow 1 size fits all kernels. Now you've also turned it into a place to hide initial startup and boot -- things systemd -- the supposed replacement for sysvinit, can't handle - but sysVinit could... no change was *necessary

what ? sysvinit never handled any of that at all.

...

as expected and designed ! nothing wrong here.. what part you still dont understand ? You can replace a DSO with an updated/improved version of *THE SAME DSO* with a compatible ABI not with some arbitrary version.

---

It's not that they are not binary compat -- it's that they version check.

od dear, the version check *is* an ABI check.

...

exactly, because that not the point, the point is to make *OUR* job easier. as developers and maintaners of a HUGE codebase.

---

Just quit. If that's your reason for being doing these things -- quit.

If the reason is NOT to support the users you are in the wrong business or you are working for a corrupt business. The purpose of the distros was to serve users and customers. Not sit back and make their own life easier at the expense of users. That's not a moral or ethical distro.

99.9% of our users do not recompile core functionality such as libc, the kernel or perl. what happends here is, you belong to the 0.01%, that is, you are either not the target audience or dare a I say.. a troll. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Carlos E. R. wrote:

If there is broken functionality I want to know about it.

sashd no longer loads via it's own libc.

This is a distribution. Linda, if you want to demonstrate tool breakage, please do so on a system built using openSUSE standard code.

--- sudo -p broke because someone added a line to the config in pam. It's added in 12.3 and factory but wasn't in 12.2 or before. These are not uniq problems to my system.

Heck, I hate systemd. But I can not create my own sysinit scripts (I might), and then complain if they don't work. I may ask for help, of course, but not complain.

---- How does one start third party or their own services? I have at least 2 services I can think of off the top of my head that I run that suse doesn't provide run scripts for. transmission-daemon and an ipmi-hw daemon. Also my 3rd party HW monitory tools from Dell and LSI are currently broken due to the recent upgrades. The LSI tools worked in 12.2. The Dell... probably 11.4... It's NOT just my personal scripts, other companies can't jump and move as fast as suse twitches. They'll just drop support for suse and tell me I'm on my own. The VM system from oracle stopped functioning in 12.3 and is still out of commission in factory. It had about 3-4 startup scripts. Now they are a complete mess. Good thing I never got a chance to rely on them before I experienced this -- how will other users of VM like their stuff failing all over the place.. They just won't use suse. You want to agree to letting suse commit suicide, that's your business... I'll keep opening my mouth when I discover more *surprises*. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Dominique Leuenberger a.k.a. Dimstar wrote:

Quoting Linda Walsh :

...

I have at least 2 services I can think of off the top of my head that I run that suse doesn't provide run scripts for.

transmission-daemon and an ipmi-hw daemon.

Please check Factory again: there is a transmission-daemon package, which brings a systemd service file with it.

---- Hmm.... I see the file... I don't see it handling any configuration or what user it runs as... It references a config file, but the config file doesn't exist. Would it be useful / possible to use my startup script to start it? Mine reads the config file from the daemon and uses those arguments when restarting rather it allows hiding the password in separate location runs as it' own daemon and has support for running more than once instance -- (only tested once). I'll include it below and you can see why I might not want to give up the functionality. I haven't reviewed it for 'release', BUT i've been using it for 3 years... so it's likely in reasonable shape. There's some code to try to see if the user is in group 'torrent', and if so, allow them to run the script as a normal user... Has support for reading from sysconfig or ENV...as well as config files in torrent user dir (by instance if running multiple daemons)... The original is tab'ed @ 2 spaces, so I converted it to 2 spaces for below. to convert back to tabs in vim, set noet, just retab! 2, then the tabs will be set for the proper indentation and if you prefer 4 or 8, then reset your tabstop (ts=3/4/8...etc)... But the retab! with et/noet make it str8 forward to recover original tabbing. Anyway... this is a reasonably good example of a start/stop script...IMO..tried to make it as flexible as possible.... ---- #!/bin/bash # # /etc/rc.d/transmission.rc script by Astara at tlinx.org (c) 2010 # use, modify and derive from, as thou wilt. If you find this useful # that's great! If you want to mention me in credits, that a bonus! Enjoy! # Developed and tested on suse 11.2 - 12.2 # transmission[{XX}] [verb] [{XX}] -- where {XX} can be an an integer and # occur as part of filename or as a # parameter and indicates which instance # or copy to control # When {XX} is noted, for XX>0, home dir directs to 'child{XX}' under # the real home directory # ### BEGIN INIT INFO # Provides: tmd # Required-Start: $network, $local_fs, # Should-Start: upnp $remote_fs named # Required-Stop: # Should-Stop: et e Default-Start: 3 5 # Default-Stop: 0 1 2 6 # Short-Description: transmission-daemon: a file transfer daemon # Description: transmission-daemon is a file transfer daemon utilizing # the 'bit-torrent' protocol. This allow for transferring # large amounts of data by sharing the network bandwith # among downloaders. Note -- to make effective use of # this client, it is necessary to allow incoming and # outgoing traffic through a firewall. # Only 1 port needs to be open and this can be defined # statically -- so you can manually add rules to your # firewall. The daemon will use upnp to talk to a # compliant firewall to ask it to open a port for it, # allowing for port randomization on startup, if that # is desired. Software upnp programs, like 'linux-igd' # are freely available by searching on the web, will # function as a upnp gateway and will manage connections # through a linux or other firewall. ### END INIT INFO # ## support code & functions Id="$(type -p id)" Sed="$(type -p sed)" Sudo="$(type -p sudo)" unset Groups typeset -Ax Groups function _idparse { # parse output of id: # uid=##(name) gid=##(name) groups=##(name)[,##(name)]... # Note, names may be 'absent' (in which case there are no parens). # grouplist is *comma* separated! -- but only on output of 'id'; # I don't "idnames" can start with a number... (we'll assume not) # if group has no name, put it's number in as it's name # else you wouldn't see you are in those groups while read id ; do [[ $id =~ .?id= ]] && continue; #skip over uid/gid entries id="${id/\(/ }" id="${id/\)/}" gid="${id%% *}" name="${id#$gid}" name=${name##\ } [[ -z $name ]] && name="$gid" Groups[$name]="$gid" done < <($Id|$Sed -r ' s/\) gid/\)\ngid/ ; s/\) groups/\)\ngroups/ ; s/\\/\\\\/g ; s/\),([0-9])/)\n\1/g ; s/\b([0-9]+),/\1\n/g ; s/groups=//') } _idparse ## populate Groups Hash tmd_user=torrent tmd_home="$(eval echo ~$tmd_user)" tmd_base_home="$tmd_home" tmd_group="$(groups torrent 2>/dev/null |cut -d\ -f3)" tmd_child="" if (($EUID != 0)) ; then if [[ -n ${Groups[$tmd_group]:-} ]]; then if [[ -z ${TRIED_ROOT:-} ]]; then export TRIED_ROOT="yes" exec sudo -E -g "$tmd_group" $0 "$@" fi fi echo "Need Root privs to successully run this script..." exit -1 fi unset TRIED_ROOT >&/dev/null || ((0)) #no longer needed #presumably user is root-priv'ed now. #parse command instance prog="$(basename "$0")" core="$(echo $prog |sed -r 's/^.*transmission/trm/ ; s/^.*trm[0]*([1-9][0-9]+)/trm$1/')" [[ ${core:0:3} == trm && ${#core} -gt 3 ]] && tmd_child="${core:3}" [[ $# -gt 1 && $2 =~ ^[0-9]+$ ]] && tmd_child="$2" tmd_child="${tmd_child##0}" [[ $tmd_child ]] && tmd_home="$tmd_home/child$tmd_child" tmd_umask=2 etc_loglevel=error #default logging level #unset tmd_use_proxy # default # don't use these by default if [[ ! ${use_proxy:-} =~ ^y ]]; then unset -v http_proxy unset -v ftp_proxy unset -v https_proxy fi if [[ -r ${tmd_log_level_file:-""} ]]; then nlvl=$(<"$tmd_log_level_file") if [[ $nlvl == info || $nlvl == debug || $nlvl == error || $nlvl == none ]] ; then etc_loglevel=$nlvl fi fi # use prefix 'tmd' = instead of full program/service name; its just too long tmd_bin="/usr/bin/transmission-daemon" tmd_piddir="/var/run/transmission/" if [[ ! -d $tmd_piddir ]]; then mkdir -m 6775 "$tmd_piddir" && chown $tmd_user.$tmd_group $tmd_piddir fi tmd_pidfile="$tmd_piddir/transmission-daemon$tmd_child.pid" tmd_logdir="/var/log/transmission" tmd_log="$tmd_logdir/daemon$tmd_child.log" tmd_output_log="$tmd_logdir/output$tmd_child.log" tmd_nice=-3 tmd_ionicep="-c2 -n7" # best effort; lowest in class tmd_existing_config=$tmd_home/settings.json function read_json_config { local cfg="${1:-}" local fl="${2:-}" typeset -A $cfg perl -wE ' use 5.12.0; $|=1; my $cfg=shift @ARGV; open (my $cfgh, "<", $ARGV[0]) or die "error w/file $!\n"; my $outs="declare -A $cfg=("; while (<$cfgh>) { chomp; m{^\s+\"([^"]+)\":\s+\"?([^"]+)\"?,\s*$} and do { my ($n, $v) = ($1, $2); $n =~ s/-/_/g; $outs .= qq{[$n]=\"$v\" }; }; } print "$outs )\n"; ' "$cfg" "$fl" } if [[ $# -ge 2 ]]; then eval $(read_json_config "$1" "$2") fi eval $(read_json_config Config "$tmd_home/settings.json") ################################################################ # 'default' tmd_a_rgs: # #[[ ${Config[blocklist_enabled]} =~ true ]] && blocklist="--blocklist" [[ -n "${Config[download_dir]}" ]] && ddd="--download-dir ${Config[download_dir]}" tmda_config_dir="--config-dir $tmd_home" tmda_dht="--dht" tmda_encryption="--encryption-tolerated" tmda_foreground="-f" tmda_incomplete_dir="--incomplete-dir $tmd_home/data/Downloading/transmission$tmd_child" tmda_local_peer_discovery="--lpd" tmda_logfile="--logfile $tmd_log" tmda_loglevel="--log-error" if [[ -z "$etc_loglevel" || $etc_loglevel == none ]] ; then tmda_logfile="--logfile /dev/null" else tmda_loglevel="--log-$etc_loglevel" fi tmda_pidfile="--pid-file $tmd_pidfile" tmda_portmap="--no-portmap" tmda_peer_port="${tmda_peer_port_number:+"--peerport $tmda_peer_port_number"}" tmda_port="${tmda_port_number:+"--port $tmda_port_number"}" tmda_rpc_allowed_access="--allowed 192.168.4.*,192.168.3.*,127.0.0.1" tmda_seedratio_glob="--no-global-seedratio" tmda_watchdir="--no-watch-dir" tmd_args=" ${tmda_blocklist:-} ${tmda_complete_dir:-} ${tmda_config_dir:-} ${tmda_dht:-} ${tmda_encryption:-} ${tmda_foreground:-} ${tmda_incomplete_dir:-} ${tmda_local_peer_discovery:-} ${tmda_logfile:-} ${tmda_loglevel:-} ${tmda_peerlimit_glob:-} ${tmda_peerlimit_per_torrent:-} ${tmda_peerport:-} ${tmda_port:-} ${tmda_pidfile:-} ${tmda_portmap:-} ${tmda_rpc_allowed_access:-} ${tmda_rpc_user:-} ${tmda_rpc_userpw:-} ${tmda_rpc_auth:-} ${tmda_seedratio_glob:-} ${tmda_watchdir:-} " ulimit -Hn16384 ulimit -Sn16384 ulimit -n 16384 ionice_bin=/usr/bin/ionice if [[ ! -e $ionice_bin ]]; then ionice_bin=$(which ionice) fi # Check for existence of config files; # read system first test -r "${tmd_sys_config:-""}" && . "$tmd_sys_config" tmd_sys_config="/etc/sysconfig/transmission$tmd_child" # then read home-dir-config if present tmd_home_config="$tmd_home/etc/rc-config" test -r "$tmd_home_config" && . "$tmd_home_config" tmd_etc="${tmd_etc:-"$tmd_home/etc"}" tmd_log_level_file="${tmd_log_level_file:-"$tmd_etc/log_level"}" if [[ -z ${tmd_user:-} ]]; then echo "tmd_user not set!" exit -1 fi if [[ -z ${tmd_group:-} ]]; then echo "User \"$tmd_user\" has no group -- (no /etc/passwd?)" exit -1 fi if [[ -z ${tmd_home:-} ]]; then echo "Configuration error: user \"$tmd_user\" has no home dir " exit -1 fi # read env options... tmd_env="${tmd_env:-"$tmd_home/environ"}" if [[ -d $tmd_env ]]; then if [[ ! -r $tmd_env || ! -x $tmd_env ]]; then echo "Environment directory $tmd_env exists, but isn't readable" echo "Environment variables will be ignored" else cd $tmd_env; readarray vars <<<$(find . -type f -name '[^.]*' -print|tr ) if ((${#vars[*]}>0)); then for var in "${vars[@]}" ; do echo "var=$var" export $var=$(<"$var") done cd - >/dev/null fi fi fi # may be set by tmd_env tmd_secrets="${tmd_secrets:-"$tmd_home/.secrets"}" tmd_usr_file="$tmd_secrets/.tmd_user" tmd_upw_file="$tmd_secrets/.tmd_userpw" if [[ -r $tmd_usr_file ]]; then tmda_rpc_user="$(<$tmd_usr_file)" fi tmda_rpc_user="${tmda_rpc_user:+"--username $tmda_rpc_user"}" if [[ -r $tmd_upw_file ]]; then tmda_rpc_userpw="$(<$tmd_upw_file)" fi tmda_rpc_userpw="${tmda_rpc_userpw:+"--password $tmda_rpc_userpw"}" if [[ -n ${tmda_rpc_user:-""} && -n ${tmda_rpc_userpw:-""} ]]; then tmda_rpc_auth="--auth" fi # non configurable vars go after here... #startproc stprc="/sbin/startproc" [[ ! -e $stprc ]] && stprc=$(which startproc) [[ ! -e $stprc ]] && { echo "Fatal: startproc not found" >&2; exit 1 ; } #startproc's arg list.... startproc_args=" -l $tmd_output_log -p $tmd_pidfile -u $tmd_user -g $tmd_group -n $tmd_nice" test -x $tmd_bin || { echo "$tmd_bin not installed"; if [ "$1" = "stop" ]; then exit 0; else exit 5; fi; } sp_args="$startproc_args" # Shell functions sourced from /etc/rc.status: # rc_check check and set local and overall rc status # rc_status check and set local and overall rc status # rc_status -v be verbose in local rc status and clear it afterwards # rc_status -v -r ditto and clear both the local and overall rc status # rc_status -s display "skipped" and exit with status 3 # rc_status -u display "unused" and exit with status 3 # rc_failed set local and overall rc status to failed # rc_failed <num> set local and overall rc status to <num> # rc_reset clear both the local and overall rc status # rc_exit exit appropriate to overall rc status # rc_active checks whether a service is activated by symlinks set +e +u # rc.status has buggy code . /etc/rc.status #set # Reset status of this service rc_reset cd $tmd_home || { /bin/false rc_status -v rc_exit } running=0 if [[ $1 != status ]]; then /sbin/checkproc -p $tmd_pidfile $tmd_bin running=$? if [[ $running == 0 ]]; then running=1 else running=0 fi fi case "$1" in start) if (($running)) ; then echo -n "Transmission already running... " else echo -n "Starting transmissiond " ## Start daemon with startproc(8). If thikks fails ## the return value is set appropriately by startproc. if [[ -n "$tr_umask" ]]; then umask $tr_umask fi all_args="$startproc_args $tmd_bin $tmd_args" if [[ -x $ionice_bin && -n "${tmd_ionicep:-}" ]]; then $ionice_bin $tmd_ionicep $stprc $all_args else $stprc $all_args fi fi # Remember status and be verbose rc_status -v ;; stop) if ((!$running)) ; then echo -n "Transmission is already stopped... " else echo -n "Shutting down transmissiond " ## Stop daemon with killproc(8) and if this fails ## killproc sets the return value according to LSB. /sbin/killproc -t 10 -p $tmd_pidfile -TERM $tmd_bin || { echo -n "Sending Kill..." /sbin/killproc -p $tmd_pidfile -t 1 -KILL $tmd_bin } fi # Remember status and be verbose rc_status -v ;; try-restart|condrestart) ## Do a restart only if the service was active before. ## Note: try-restart is now part of LSB (as of 1.9). ## RH has a similar command named condrestart. if test "$1" = "condrestart"; then echo -n "${attn} Use try-restart ${done}(LSB)${attn} " echo "rather than condrestart ${warn}(RH)${norm}" fi $0 status if test $? = 0; then $0 restart else rc_reset # Not running is not a failure. fi # Remember status and be quiet rc_status ;; restart) ## Stop the service and regardless of whether it was ## running or not, start it again. $0 stop $0 start # Remember status and be quiet rc_status ;; status) echo -n "Checking for service transmission-daemon${tmd_child} " ## Check status with checkproc(8), if<F5><F5> process is running ## checkproc will return with exit status 0. # Return value is slightly different for the status command: # 0 - service up and running # 1 - service dead, but /var/run/ pid file exists # 2 - service dead, but /var/lock/ lock file exists # 3 - service not running (unused) # 4 - service status unknown :-( # 5--199 reserved (5--99 LSB, 100--149 distro, 150--199 appl.) # NOTE: checkproc returns LSB compliant status values. /sbin/checkproc -p $tmd_pidfile $tmd_bin # NOTE: rc_status knows that we called this init script with # "status" option and adapts its messages accordingly. rc_status -v ;; probe) ## Optional: Probe for the necessity of a reload, print out the ## argument to this init script which is required for a reload. ## Note: probe is not (yet) part of LSB (as of 1.9) if [[ $tmd_sys_config -nt $tmd_pidfile || $tmd_home_config -nt $tmd_pidfile ]]; then echo reload fi ;; *) echo "Usage: $0 {start|stop|status|try-restart|restart|probe}" exit 1 ;; esac rc_exit # vim: ts=2 sw=2 syntax=sh -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2013-04-02 at 14:34 -0700, Linda Walsh wrote:

Carlos E. R. wrote:

...

If there is broken functionality I want to know about it.

---

sashd no longer loads via it's own libc.

Yes.

...

This is a distribution. Linda, if you want to demonstrate tool breakage, please do so on a system built using openSUSE standard code.

---

sudo -p broke because someone added a line to the config in pam. It's added in 12.3 and factory but wasn't in 12.2 or before.

Yes, I saw you reported this in a bugzilla. But you have to show that these problems exist in a system using only packages as distributed by openSUSE. If you, for example, remove initrd, you can not complain that things do not work, you are on your own. You have to swim inside the current, as we try to do, and then cry out at the rocks for everybody to see. If you say that something does not work, and then we find out that you use an atypical boot system without initrd for your own reasons, well, after sometime people stop listening to you.

...

Heck, I hate systemd. But I can not create my own sysinit scripts (I might), and then complain if they don't work. I may ask for help, of course, but not complain.

---

How does one start third party or their own services?

I don't know. I'm using 12.1 with systemv or 11.4 evergreen, precissely because of this...

I have at least 2 services I can think of off the top of my head that I run that suse doesn't provide run scripts for.

transmission-daemon and an ipmi-hw daemon.

Yes, I know about transmission. Another I'm worried about is hylafax. And what to do about boot.crypto.

It's NOT just my personal scripts, other companies can't jump and move as fast as suse twitches. They'll just drop support for suse and tell me I'm on my own.

Yes, I'm afraid this is true.

The VM system from oracle stopped functioning in 12.3 and is still out of commission in factory.

I don't know about factory. AFAIK, recent Vmware Player works in 12.3.

You want to agree to letting suse commit suicide, that's your business... I'll keep opening my mouth when I discover more *surprises*.

Please do, but using openSUSE standards. If you don't, nobody will care or listen. - -- Cheers, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlFcH4EACgkQtTMYHG2NR9XD9wCglxQ6HY9Il+nNmg4X7C6h6fXz /lkAn17Z1xmVAk1m+i5AyGkSi/cUPBK3 =qHrk -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Apr 3, 2013 at 12:30 PM, Linda Walsh wrote:

...

Please do, but using openSUSE standards. If you don't, nobody will care or listen.

Sorry, Just because I don't where a susu hat & skirt, doesn't mean my reports are invalid.

The rpms are buggie as installed. No interaction with initrd comes into play.

He's probably talking about adding to glibc all the features required by the openSUSE distribution. If you remove OWL, you're not using openSUSE standards. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Apr 3, 2013 at 1:47 PM, Linda Walsh wrote:

Claudio Freire wrote:

...

He's probably talking about adding to glibc all the features required by the openSUSE distribution. If you remove OWL, you're not using openSUSE standards.

If you remove OWL, you won't be able to login and your system will be non-functional, so that's a rather moot point.

s/OWL/whatever feature you'd like to remove/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org