Jan Engelhardt wrote:

On Saturday 2013-01-12 20:40, Linda Walsh wrote:

...

Starting with the 12.X series, it seems the problem has gotten significantly worse. Binaries from each of the 12.x versions are often mutually incompatible -- most often because each version has been hard-coded to accept only 1 version of GLIBC.

Nonsense.

This is not "exact" but "greater-than", because libraries never remove version symbols (like GLIBC_2.14) while the SONAME stays the same.

Ah...you are right... I remember the problem. Basic system functions and libs were moved into unmounted partitions -- the most heinous being *mount*. Without that I can't mount /usr to access the rest. Is there a reason why it can't be in /bin with a symlink in /usr/bin/? For that matter -- any of the files that are being moved from /{bin,sbin,lib,lib64} -> /usr, wouldn't it be possible to move them back to /being on "/" instead of under /usr? Then /usr can have symlinks -- because if /usr is there, then "/" will always be there, but the presence of "/" doesn't mean /usr has been mounted yet. I had to go back to glib2.14, or my system wouldn't boot. Then I kept getting lots of error messages like: `/usr/lib64/libvirt/virt-aa-helper: /lib64/libc.so.6: version `GLIBC_2.16' not found (required by /usr/lib64/libvirt/virt-aa-helper)' prelink: /usr/bin/virsh: Could not parse `/usr/bin/virsh: /lib64/libc.so.6: version `GLIBC_2.16' not found (required by /usr/lib64/libvirt.so.0)' prelink: /usr/bin/virt-viewer: Could not parse `/usr/bin/virt-viewer: /lib64/libc.so.6: version `GLIBC_2.16' not found (required by /usr/lib64/libvirt.so.0)' (except it was GLIBC_2.15... I used to be able to install higher level libraries and **usually** have them work just fine -- but with a hard-coded symbol in the binary, that's no longer possible. Are you saying ALL programs use the new GLIBC features, as that used to not be the case. Is this because the paths are hard coded into the libs and utilities (comment to that effect in GLIBC in finding nscd...)... doesn't seem to use PATH, but a hard coded value... So now with glibc-2.15, I won't be able to reboot my system w/out a rescue disk. What got worse in the 12.x series was the inclusion of the glibc version in the binaries. Before that wasn't the case, so I could try newer packages to see if they worked (always did with pre-reqs installed)...But requiring the symbol at link time creates a problem. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sunday 2013-01-13 05:32, Linda Walsh wrote:

Then I kept getting lots of error messages like: `/usr/lib64/libvirt/virt-aa-helper: /lib64/libc.so.6: version `GLIBC_2.16' not found (required by /usr/lib64/libvirt/virt-aa-helper)' prelink: /usr/bin/virsh: Could not parse `/usr/bin/virsh: /lib64/libc.so.6: version `GLIBC_2.16' not found (required by /usr/lib64/libvirt.so.0)' prelink: /usr/bin/virt-viewer: Could not parse `/usr/bin/virt-viewer: /lib64/libc.so.6: version `GLIBC_2.16' not found (required by /usr/lib64/libvirt.so.0)'

(except it was GLIBC_2.15... I used to be able to install higher level libraries and **usually** have them work just fine -- but with a hard-coded symbol in the binary, that's no longer possible.

Are you saying ALL programs use the new GLIBC features, as that used to not be the case.

All programs in openSUSE version xyz use the features of the particular glibc that is shipped in openSUSE xyz. Backwards compatibility means that binaries from xyz minus n, for any n, continue to work on xyz. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 13/01/13 16:30, Linda Walsh escribió:

Jan Engelhardt wrote:

...

All programs in openSUSE version xyz use the features of the particular glibc that is shipped in openSUSE xyz.

---

I find that hard to believe.

I would believe that some use new features, but sometimes, the difference between versions are bug fixes. I can't believe that all programs relied on the bug fix and would fail without it.

I think you confusion is due to semantics and wording, programs are not changed to use new glibc features, it simply means that when the software is compiled in target xyz and a new/improved/optimized libc routine is provided, dependencies are changed in order to ensure the binary is being run under the proper conditions. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 05/02/13 00:01, Linda Walsh escribió:

I get various programs that won't load because:

boot.msg:/usr/sbin/libvirtd: /lib64/libc.so.6: version `GLIBC_2.15' not found (required by /usr/lib64/libvirt.so.0) boot.msg:/usr/sbin/libvirtd: /lib64/libc.so.6: version `GLIBC_2.16' not found (required by /usr/lib64/libvirt.so.0) boot.msg:Starting minidlna /usr/sbin/minidlna: /lib64/libm.so.6: version `GLIBC_2.15' not found (required by /usr/lib64/libvorbis.so.0)

and you did not see it coming do ya ? the glibc build system will scream (warn is not the proper word for what it does) at you when you try to do this and clearly tell that you will break your system in the process...

now it so happens that in my /lib64, I DO have a libc-2.15.so, libc-2.16.so and libc-2.17.so.

It's just that the default pointed to by libc.so.6 is the latest.

is the linker cache up to date ?

What I was trying to say was that if a program was out there that NEEDED a specific version of libc-2.XY.so,

then shouldn't it *link* to libc-2.XY.SO instead of of libc.so.6?

NO. The linker already adds proper versioned NEEDED entries to the DSOs.

My SW can't keep up!...

Am I supposed to ??

You are supposed to use ONE C library in your system, and there is no need to recompile or relink any software whatsoever.

When I talked about instability in the libc-series... people said I was fear mongering... but 3 incompat versions in 6 months? That's reasonable?

The library is OK, is compatible and doing exactly what it should, what has *always* done.. is your understanding and approach to the problem that is totally broken. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sunday 2013-01-13 20:30, Linda Walsh wrote:

...

All programs in openSUSE version xyz use the features of the particular glibc that is shipped in openSUSE xyz.

I find that hard to believe. I would believe that some use new features, but sometimes, the difference between versions are bug fixes. I can't believe that all programs relied on the bug fix and would fail without it.

Yeah I was imprecise there. But consider this: #include #include int main(void) { printf("This libc knows about %d error codes\n", sys_nerr); return 0; } Glibc introduced a new "sys_nerr@GLIBC_2.12" (per `readelf -s`) for glibc-2.12 [shipped in openSUSE 12.1], so this 7-line example program, by way of the distro doing a recompile every distro release, suddenly starts requiring glibc-2.12 even though glibc-2.4 would have been fine as well.

Just to be clear. I realize that there is no guarantee taking a program from V.[v+n] and having it run on a V.v system, however, it was possible to ***try*** this in suse versions prior to 12.0 -- USUALLY with success if prereqs were met.

That was just luck. It all depends on when a symbol was last modified. Some are as old as fopen@GLIBC_2.2.5. Prior to glibc 2.12~2.14 [openSUSE 12.0 and earlier], glibc was considered a slower-moving target. https://lwn.net/Articles/488778/ https://lwn.net/Articles/492624/

So question -- if I build a binary on OBS -- can I specify what OS it is being built for? Or is it always going to build for factory?

Yes, <repository name="openSUSE_12.2"> <path project="openSUSE:12.2" repository="standard"/> <arch>x86_64</arch> <arch>i586</arch> </repository>

I.e. if I take the source rpm for "12.2/3 can I tell OBS to build it in a 12.1 environment?

Yes.

Example -- perl5.16 doesn't seem to build on 12.1.

Works for me. osc co devel:languags:perl/perl cd there osc build -bd openSUSE_12.2 x86_64 <success after a while> -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Monday 2013-01-14 03:47, Andrey Borzenkov wrote:

В Sun, 13 Jan 2013 22:58:07 +0100 (CET) Jan Engelhardt пишет:

...

...

Example -- perl5.16 doesn't seem to build on 12.1.

Works for me. osc co devel:languags:perl/perl cd there osc build -bd openSUSE_12.2 x86_64 <success after a while>

It is building for 12.2 that works for you, or do I misunderstand osc arguments?

I mistyped; this succeeded for 12.1. ... /var/tmp/jng/openSUSE_12.1-x86_64/home/abuild/rpmbuild/SRPMS/perl-5.16.0-0.src.rpm /var/tmp/jng/openSUSE_12.1-x86_64/home/abuild/rpmbuild/RPMS/noarch/perl-doc-5.16.0-0.noarch.rpm /var/tmp/jng/openSUSE_12.1-x86_64/home/abuild/rpmbuild/RPMS/x86_64/perl-base-debuginfo-5.16.0-0.x86_64.rpm /var/tmp/jng/openSUSE_12.1-x86_64/home/abuild/rpmbuild/RPMS/x86_64/perl-debuginfo-5.16.0-0.x86_64.rpm /var/tmp/jng/openSUSE_12.1-x86_64/home/abuild/rpmbuild/RPMS/x86_64/perl-base-5.16.0-0.x86_64.rpm /var/tmp/jng/openSUSE_12.1-x86_64/home/abuild/rpmbuild/RPMS/x86_64/perl-debugsource-5.16.0-0.x86_64.rpm /var/tmp/jng/openSUSE_12.1-x86_64/home/abuild/rpmbuild/RPMS/x86_64/perl-5.16.0-0.x86_64.rpm -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sun, 2013-01-13 at 20:28 -0800, Linda Walsh wrote:

Oh ****. Dissolution of steering committee for standard C library, replaced by whoever happens to be doing development on glibc at the time. Sounds like a recipe for total chaos. Sounds like an even better reason for static linking (personally I think all of the programs used for 'boot' (ones that used to live in a subdir of /), should be statically linked. Have had several times when statically linked progs saved my butt, and conversely, am increasingly having problems with dynamic libraries that are needed for boot being located on what was traditionally a separate partition (/usr)... The straw that broke my adaptability was making mount dependent on partitions that haven't been mounted yet. A perfectly good reason to make the mount on /sbin (or /bin) statically built.)...

I just deployed an app compiled on 12.1 to run on an 11.2 system. I thought I would need to statically link it since it was built 'in the future'. Oddly, this was not needed. Which was a surprise. As to statically linking, there are a few libraries that won't link statically. Unless I am mistaken, libc is one of them. The logic for that is that it is so closely tied to the kernel that things will be better if libc and the kernel match. Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, 2013-01-14 at 11:26 +0100, Jan Engelhardt wrote:

On Monday 2013-01-14 08:27, Roger Oberholtzer wrote:

...

I just deployed an app compiled on 12.1 to run on an 11.2 system. I thought I would need to statically link it since it was built 'in the future'. Oddly, this was not needed. Which was a surprise.

As to statically linking, there are a few libraries that won't link statically. Unless I am mistaken, libc is one of them.

It was libnss_* - these are always dlopened even if the code that issues the dlopen (getpwnam/etc. and libdl) is included in static form.

...

The logic for that is that it is so closely tied to the kernel that things will be better if libc and the kernel match.

This is nonsense.

No it is not. Something as 'simple' as the signal() call, which you would think is a simple wrapper over some kernel call, has lots of support code in glibc to make it work properly with the specific version of the kernel. glibc is compiled with the kernel headers. Not so long ago, updating the kernel required that you had a glibc version that was compatible. Otherwise, your system would function improperly Of course, one function of glibc is to hide these kernel differences from user programs. Unless you are setting up traps yourself, you access the kernel pretty much via glibc. So, theoretically, an application compiled with one version of glibc should pretty much work with another version of glibc. In fact, that was what I said. And the only way this works is if glibc is not statically linked in to the app. So, Linda's suggestion that all apps be statically linked does not resolve her glibc issue. Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, 2013-01-14 at 13:55 +0100, Andreas Schwab wrote:

Roger Oberholtzer writes:

...

Something as 'simple' as the signal() call, which you would think is a simple wrapper over some kernel call, has lots of support code in glibc to make it work properly with the specific version of the kernel.

Does it? The code in sysdeps/posix/signal.c is completely kernel independent.

Perhaps a bad example? Which I find surprising, as there are numerous glibc interfaces (signal(), sigaction()), but I would imagine only one kernel mechanism on which they are both built. Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt wrote:

On Monday 2013-01-14 05:28, Linda Walsh wrote:

...

Jan Engelhardt wrote:

...

Glibc introduced a new "sys_nerr@GLIBC_2.12" (per `readelf -s`) for glibc-2.12 [shipped in openSUSE 12.1], so this 7-line example program, by way of the distro doing a recompile every distro release, suddenly starts requiring glibc-2.12 even though glibc-2.4 would have been fine as well.

---

It sounds like you are saying that most of these changes, in this case come from upstream. Hmmm....

All changes come from upstream.

They maintain the rpm build scripts and decide what to put in the rpm packages and what to no longer distribute? I know upstream fixed parallel sort, but that wasn't adopted as the default in OS. Many times I find it easier to build the package as released by the maintainers than build the rpm. Case in point. I just downloaded the glibc distribution (2.17). It configured and built the first time -- while the srpms for 2.14 and 2.15 don't due to unpackaged files being left over in the build tree. Ever since Suse stopped building on their own machines and require a sterile environment, they get farther away from real systems -- but the distributions of the software is meant to be built in a variety of "hostile" environments ;-)....

...

Oh ****. Dissolution of steering committee for standard C library, replaced by whoever happens to be doing development on glibc at the time. Sounds like a recipe for total chaos.

What an uninformed claim. This is pure panic making.

Interesting that others made similar comments though a bit more low key on the 2nd of the pages you quoted.... It is a recipe for total chaos -- whether or not it will happen depends on the bakers involved. They might be very restrained. But as you note, there has been an uptick in changes during the time of the 12.x series, so is it that 'uninformed'? Note, I may be guilty of a bit of hyperbole at times, but sometimes, I'm guilty of understatement as well.. ;-/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Linda Walsh wrote:

Jan Engelhardt wrote:

I think you missed this question...

...

...

Example -- perl5.16 doesn't seem to build on 12.1.

Works for me. osc co devel:languags:perl/perl cd there osc build -bd openSUSE_12.2 x86_64

^^^^^^ That doesn't look like 12.1 to me... I know binaries are out there for 12.2 but it's 12.1 binaries for perl 5.16.2 (or any 5.16, that I don't find)...

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

Jan Engelhardt wrote:

On Tuesday 2013-01-15 03:01, Linda Walsh wrote:

...

Linda Walsh wrote:

...

Jan Engelhardt wrote: I think you missed this question...

I replied in a parallel thread;

...

...

...

Works for me. osc co devel:languags:perl/perl cd there osc build -bd openSUSE_12.2 x86_64 ^^^^^^ That doesn't look like 12.1 to me...

Typo in the mail. It does succeed for 12.1. Try it yourself and see.

osc co devel::languags:perl/perl Server returned an error: HTTP Error 404: Not Found Error getting meta for project 'devel::languags:perl' package 'perl' osc dists Server returned an error: HTTP Error 404: Not Found ---- I seem to remember having problems like this last time I tried it. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 15.01.13, schrieb Andreas Schwab :

Linda Walsh writes:

...

...

...

...

...

Works for me. osc co devel:languags:perl/perl [...] osc co devel::languags:perl/perl

Try typing exactly what Jan wrote.

In this case, not a good idea (languag_e_s), but come on, it is much do difficult to go to download.opensuse.org or to the OBS to check how a project/package is exactly named. Hey, that would require using ones brain, which is hardly possible if it is totally exhausted by ranting all the time ... Regards, Stefan --  Stefan Brüns  /  Bergstraße 21  /  52062 Aachen phone: +49 241 53809034     mobile: +49 151 50412019 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday 16 January 2013 11:47:45 Linda Walsh wrote:

"Stefan Br�����������������������������������" wrote:

...

In this case, not a good idea (languag_e_s), but come on, it is much do difficult to go to download.opensuse.org or to the OBS to check how a project/package is exactly named. Hey, that would require using ones brain, which is hardly possible if it is totally exhausted by ranting all the time ...

---

It might require that someone actually tried building it when they said they did, so a cut-paste from their terminal into email wouldn't end up with errors.

If nobody even knows the syntax or where it is located to try, then how is it that we know it works?

It is awfully exhausting for me to file a bug report on it not working, then be told it works, with the proof being something I can't replicate.

I never had a problem building packages when they were built on a normal suse system. Only since osc was added have I found things often don't build correctly on a normal system.

I guess it is the side effect of using a single clean build system like osc. It saves work - everyone builds against the exactly same, clean system. Less time is wasted finding bugs which depend on a specific system the package was build on. And less time is wasted making packages build in a variety of circumstances: only one matters (OBS). That means building outside of osc gets harder, yes. The work is basically shifted from all the packagers to those few who don't (want to) use osc. I'm not sure if this was intentional in any way but I'm quite certain it isn't going to change as the packagers aren't looking for more work, esp if it doesn't come with real benefits to openSUSE. I suggest for you to use osc...

When developers of packages ship their source, they don't ship rpm's built in a clean-room. They most often ship some configuration detection based make system that works across a number of platforms. Since the introduction of OSC, building has gotten very difficult.

One example of bad practice -- in core utils, they copy patches, on source install, into a patch dir -- but they don't clear out that dir first. The the build does a "for i in (patch/*.*);do..." Which causes failures if you have built 2 different versions of coreutils in a row.

Meanwhile, neither path to the perl package seems to work.

If it works on a clean system (like in OBS), it works - that seems to be the golden standard now, for good and bad. I suggest to spend time on https://news.opensuse.org/?p=14939 instead of being unhappy about things which won't change. Pizza has a positive influence on my mood, hope it helps you too ;-)

:-(

Andreas Schwab wrote:

Linda Walsh writes:

...

...

...

...

...

osc co devel:languags:perl/perl

[...]

...

osc co devel::languags:perl/perl Try typing exactly what Jan wrote. Andreas.

---- I did, I get:

osc -v co devel:languages:perl makeurl: https://build.opensuse.org ['source', 'devel:languages:perl', '_meta'] [] Server returned an error: HTTP Error 404: Not Found

osc bco devel:languages:perl defaulting to openSUSE:Factory/devel:languages:perl BuildService API error: unexpected response: <html> <body> <h1>File not found</h1> <p>404</p> </body> </html>

[general] # URL to access API server, e.g. https://api.opensuse.org # you also need a section [https://api.opensuse.org] with the credentials apiurl = https://build.opensuse.org # Downloaded packages are cached here. Must be writable by you. packagecachedir = /home/packages/OSbuild/packagecache # Wrapper to call build as root (sudo, su -, ...) su-wrapper = sudo # rootdir to setup the chroot environment # can contain %(repo)s, %(arch)s, %(project)s and %(package)s for replacement, e.g. # /srv/oscbuild/%(repo)s-%(arch)s or # /srv/oscbuild/%(repo)s-%(arch)s-%(project)s-%(package)s build-root = /home/packages/OSbuild/buildroot/ # compile with N jobs (default: "getconf _NPROCESSORS_ONLN") #build-jobs = 8 # build-type to use - values can be (depending on the capabilities of the 'build' script) # empty - chroot build # kvm - kvm VM build (needs build-device, build-swap, build-memory) # xen - xen VM build (needs build-device, build-swap, build-memory) # experimental: # qemu - qemu VM build # lxc - lxc build #build-type = # build-device is the disk-image file to use as root for VM builds # e.g. /var/tmp/FILE.root #build-device = /var/tmp/FILE.root # build-swap is the disk-image to use as swap for VM builds # e.g. /var/tmp/FILE.swap #build-swap = /var/tmp/FILE.swap # build-memory is the amount of memory used in the VM # value in MB - e.g. 512 #build-memory = 512 # build-vmdisk-rootsize is the size of the disk-image used as root in a VM build # values in MB - e.g. 4096 #build-vmdisk-rootsize = 4096 # build-vmdisk-swapsize is the size of the disk-image used as swap in a VM build # values in MB - e.g. 1024 #build-vmdisk-swapsize = 1024 # Numeric uid:gid to assign to the "abuild" user in the build-root # or "caller" to use the current users uid:gid # This is convenient when sharing the buildroot with ordinary userids # on the host. # This should not be 0 build-uid = caller # extra packages to install when building packages locally (osc build) # this corresponds to osc build's -x option and can be overridden with that # -x '' can also be given on the command line to override this setting, or # you can have an empty setting here. extra-pkgs = gvim vim gdb strace build-platform=x86_64 # build platform is used if the platform argument is omitted to osc build #build_repository = openSUSE_Factory # default project for getpac or bco #getpac_default_project = openSUSE:Factory # alternate filesystem layout: have multiple subdirs, where colons were. #checkout_no_colon = 1 # local files to ignore with status, addremove, .... #exclude_glob = .osc CVS .svn .* _linkerror *~ #*# *.orig *.bak *.changes.vctmp.* # keep passwords in plaintext. If you see this comment, your osc # already uses the encrypted password, and only keeps them in plain text # for backwards compatibility. Default will change to 0 in future releases. # You can remove the plaintext password without harm, if you do not need # backwards compatibility. plaintext_passwd = 0 # limit the age of requests shown with 'osc req list'. # this is a default only, can be overridden by 'osc req list -D NNN' # Use 0 for unlimted. #request_list_days = 0 # show info useful for debugging #debug = 1 # show HTTP traffic useful for debugging #http_debug = 1 # Skip signature verification of packages used for build. #no_verify = 1 # jump into the debugger in case of errors #post_mortem = 1 # print call traces in case of errors #traceback = 1 # use KDE/Gnome/MacOS/Windows keyring for credentials if available #use_keyring = 1 # check for unversioned/removed files before commit #check_filelist = 1 # check for pending requests after executing an action (e.g. checkout, update, commit) #check_for_request_on_action = 0 # what to do with the source package if the submitrequest has been accepted. If # nothing is specified the API default is used #submitrequest_on_accept_action = cleanup|update|noupdate # template for an accepted submitrequest #submitrequest_accepted_template = Hi %(who)s,\n # thanks for working on:\t%(dst_project)s/%(dst_package)s. # SR %(reqid)s has been accepted.\n\nYour maintainers # template for a declined submitrequest #submitrequest_declined_template = Hi %(who)s,\n # sorry your SR %(reqid)s (request type: %(type)s) for # %(dst_project)s/%(dst_package)s has been declined because... #review requests interactively (default: off) #request_show_review = 1 # Directory with executables to validate sources, esp before committing #source_validator_directory = /usr/lib/osc/source_validators [https://api.opensuse.org] user=LAwalsh passx=...[elided] # set aliases for this apiurl # aliases = foo, bar # email used in .changes, unless the one from osc meta prj <user> will be used # email = # additional headers to pass to a request, e.g. for special authentication #http_headers = Host: foofoobar, # User: mumblegack # Force using of keyring for this API #keyring = 1 [https://build.opensuse.org] user=LAWalsh passx=...[elided] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thursday 2013-01-17 02:16, Linda Walsh wrote:

Andreas Schwab wrote:

...

Linda Walsh writes:

...

...

...

...

> osc co devel:languags:perl/perl

[...]

...

osc co devel::languags:perl/perl Try typing exactly what Jan wrote. Andreas.

---- I did, I get:

...

osc -v co devel:languages:perl makeurl: https://build.opensuse.org ['source', 'devel:languages:perl', '_meta'] [] Server returned an error: HTTP Error 404: Not Found

You found a great way to break your osc. The apiurl is supposed to be api.opensuse.org, not build.opensuse.org. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt wrote: That doesn't look like 12.1 to me...

Typo in the mail. It does succeed for 12.1. Try it yourself and see.

---- FWIW, I do have an account, I just tried the PW on the website (where the tutorial is at), and it still works. I do have that information in my ~/.oscrc file... Seem to remember there being some bug if you first tried launch osc from the command line rather than a website. It was going to be fixed, but really have no idea if it left anything screwy in my remote 'home' dir or if that is even the problem. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-------- Original-Nachricht --------

Datum: Mon, 14 Jan 2013 08:57:27 +0100 Von: Michal Kubecek An: opensuse-factory@opensuse.org Betreff: Re: [opensuse-factory] How to use multiple versions of same library on 1 system?

On Sun, Jan 13, 2013 at 01:59:01AM +0100, Jan Engelhardt wrote:

...

Remember, libc.so.6 was introduced some umpteenth years ago when the world switched away from a.out to ELF. Since there is no replacement required for ELF at this time because the format is so extensible, it is unlikely that there will ever be a libc.so.7.

libc5 was already ELF, IIRC.

IIRC long ago ( back in the kernel 0.x days) linux-libc was forked from glibc. libc4 was the last aout version of linux-libc, libc5 the ELF version of linux-libc. With libc6 the fork was given up and linux uses original glibc again. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org