January 2014 - openSUSE Factory - openSUSE Mailing Lists

[opensuse-factory] package request: lldb for llvm
by Jason Newton 23 Jan '14

23 Jan '14

Hi Folks, I'm writing in for some help on bringing lldb to opensuse users. I've tried my hands at building it a number of times and I just can't get the darn thing to compile, it always errors out on it's python module in a cmake step that doesn't take into consideration oS's specific paths.... I've tried fixing that but it still hasn't worked out and I don't see what the ubuntu guys did to make it work. I'm hoping one of the LLVM maintainers reads factory and can manage to work out the build issues and add it to the llvm builds in devel:tools:compiler. By the way, for packages like llvm, which take over 45 minutes to compile on recent workstations, is there any recipe to "continue" building packages when using OBS local builds? You know, to speed up most of the build->fail->attempt fix->rebuild cycle? I tear up when I think of all those wasted CPU cycles. -Jason -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 3

[opensuse-factory] LVM2 package in Base:System is causing stability issues related to grub and systemd
by Raymond Wooninck 23 Jan '14

23 Jan '14

Dear Listmates, For quite some time I am using the lvm2 package from Base:System. It's already quite some time ago and I don't remember why I switched it. But the last few days I saw stability issues where issuing the os-prober command from grub was hanging on detecting filesystems and also shutting the system down caused a hang situation. Due to this I lost a couple of time already the KDE configuration as that I had to do a hard reset. Together with Hrovje (shumski) and Luca (einar77), I managed to find the package that was responsible for this misery. Tracing the os-prober command and the shutdown process, it seemed that both were hanging as soon as a lvm2 command was issues. Killing that lvm2 command, made the system behave correctly again. I reverted back to the lvm2 version in Factory and the system is functioning normally again. Therefore I would like to ask the maintainer of lvm2, to validate the latest changes to make sure that his changes are working properly together with grub and systemd. Until that time it would be good not to submit or accept the current version that is in Base:System. For those that are using this version, I would recommend to revert back to the version in Factory. Regards Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 3

[opensuse-factory] wicked and network configs
by Sid Boyce 22 Jan '14

22 Jan '14

After on zypper dup and during another networking was lost. Network interfaces deconfigured. From dmesg:- [83889.988963] br1: port 1(eth1) entered disabled state [83889.992691] br0: port 1(eth0) entered disabled state [83889.992730] br0: topology change detected, propagating [83890.022425] device eth1 left promiscuous mode [83890.022507] br1: port 1(eth1) entered disabled state [83890.025398] device eth0 left promiscuous mode [83890.025455] br0: port 1(eth0) entered disabled state [83890.069753] wickedd (750) used greatest stack depth: 3304 bytes left [83890.131542] device eth1 entered promiscuous mode [83890.137569] device eth0 entered promiscuous mode [83890.297438] IPv6: ADDRCONF(NETDEV_UP): enp0s19f2u4u4u4: link is not ready [83890.304990] br1: port 1(eth1) entered listening state [83890.305020] br1: port 1(eth1) entered listening state [83890.305114] IPv6: ADDRCONF(NETDEV_UP): br1: link is not ready [83890.308101] br0: port 1(eth0) entered listening state [83890.308129] br0: port 1(eth0) entered listening state [83890.308228] IPv6: ADDRCONF(NETDEV_UP): br0: link is not ready [83900.954449] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s19f2u4u4u4: link becomes ready So far I have set them up manually with e.g "ifconfig br0 192.168.10.2" "route add default gw 192.168.10.103" The devices all still showed with ifconfig but weren't configured as per /etc/sysconfig/network/ifcfg-br0. Bug #859801 submitted Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0

[opensuse-factory] MC - Shifted Fn inconsistency between run in X and run on tty
by Felix Miata 21 Jan '14

21 Jan '14

All my installations are en_US. Any support any of them may have for anything else escaped my notice and intent. For many years, regardless of distro or version, shifted function keys running MC have usually varied according to whether it is running in X, or on tty[1-6]. In every case of unshifted, F5 is copy and F6 is Move, with both assuming *to* opposing pane. Always when shift is applied to F5/F6, and MC is running in X, instead of assuming copy/move *to* opposite pane, the current filename is presented for editing. On tty[1-6], the most common behavior has always been that copy/move with name for editing is found with Shift-F3/Shift-F4 instead of Shift-F5/Shift-F6. Occasionally I've run across behavior on tty[1-6] being Shift-F3=view, Shift-F4=edit, Shift-F5=copy to editname, and Shift-F6=move to editname. Now on one 13.2 installation (host gx280) I've again stumbled onto a case of the latter behavior. Because of the activity in thread "box characters not used by ncurses" I looked here at output from locale and found LC_CTYPE unset (everything else either null or "POSIX"), unlike on most openSUSE installations here where LC_CTYPE=en_US.UTF-8. On most of my non-openSUSE installations, all locale output is either en_US.UTF-8 or null, while on most of my openSUSE installations, most locale output is "POSIX", with one or more entries null, and LC_CTYPE=en_US.UTF-8. What's going on here in openSUSE using POSIX for most but not all, and occasionally leaving LC_CTYPE unset, while other times LC_CTYPE=en_US.UTF-8? Where does LC_CTYPE ever get set? What does one need to do to keep MC keystrokes same on ttys as in X? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0

[opensuse-factory] obs web interface going crazy
by Cristian Rodríguez 18 Jan '14

18 Jan '14

Hi: There seems to be a caching issue in the OBS web interface, on every page reload you appear logged in as a different user.. in my case as "lrupp, cpansubmitter, Superpeppo89, etc" Will be cool if someone can take a look -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0

[opensuse-factory] Lord of the Rings IV: staging projects
by Stephan Kulow 17 Jan '14

17 Jan '14

Hi, I used the silent nights on OBS over Christmas to get serious about the ring projects and made sure that :Build and :Core are 100% succeeding and :MainDesktops actually can build live cds. As this was a lot of work, I want to preserve that and added now a little reviewer that makes sure updates to :Build and :Core go over my desk. I'm adding them to one of the staging projects on a "roll a dice" base to verify that adding updates is not adding any red to my beloved project monitor. https://build.opensuse.org/project/subprojects/openSUSE:Factory:Staging is my "dashboard" for the time being. It's a very manual process, but I'm refining my preferences of what's the best process daily - so bear with me. I just wanted to let you know about the change. It will delay updates to base packages, but for a good reason I hope you'll agree. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 5

[opensuse-factory] Re: /etc/sysconfig/kernel vs. /etc/dracut.conf
by Linda Walsh 17 Jan '14

17 Jan '14

Felix Miata wrote: > > Does your Dell BIOS boot config menu allow to include addin devices? ---- The built-in INTEL Sata has a port out the back for eSATA. That can either be enabled or disabled. Unlike the 3 internal SATA ports (mostly used for optical drives), if it is enabled and no cable is present, no error message is displayed on boot (vs. enabled-internal SATA + disconnected power or cable => bios boot displays error and waits for a key to continue). The order of the other, SAS controller and any addin-cards can also be specified in the bios. Then it scans those cards on boot -- from that point you can choose which drives are boot drives and which order to try them in. (Precision 7600; PowerEdge T610 has similar setup -- but no eSATA port -- it does let me choose the boot drives to try and their order. I have an external-SAS port card (LSI) that gets scanned for drives 1st so it comes up with sda+sdb. sdc & sdd are internal drives -- w/boot and OS on sdc. > Dells are really persnickity about having HDs added or removed. I don't > remember ever seeing one's BIOS present any option to allow a HD > connected to an eSATA addin card as an explicit boot choice to be > preferred to the 4 more or less standard options, floppy, OM, HD, > network/PXE. Even if they were, I wouldn't be wanting them even as an > option, much less preferred to internally installed options. ---- It's "like" the optical disc, -- if there is no bootable media in it, then it gets ignored, but if there is, it will boot from it. Can config USB similarly, I believe, but I've never done it. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0

[opensuse-factory] dracut mkinitrd doesn't see modules Bug #858378 submitted
by Sid Boyce 16 Jan '14

16 Jan '14

Built 3.13-rc7 on 3 boxes where dracut had replaced mkinitrd. zypper dup installed dracut. I spotted the problem on 2 systems and installed module-init-tools. On a third system I forgot to install module-init-tools and reboot failed with no access to usb or wired keyboard, network or anything else that needed modules were started. I had to do a fresh install, "zypper in module-init-tools", built and installed vanilla 3.13-rc7 and rebooted successfully. I did play around with booting from CD, mounting /dev/sda2 as /tmp/2, chroot /tmp/2 and mounting /dev/sda1 as /boot but that didn't allow zypper in module-init-tools to work. Reproducible: Always Steps to Reproduce: 1.#!/bin/sh cp arch/x86/boot/bzImage /boot/vmlinuz-$1;cp System.map /boot/System.map-$1 rm /boot/System.map;ln -s /boot/System.map-$1 /boot/System.map cp .config /boot/config-$1 cd /boot;mkinitrd /boot/initrd-$1 $1 grub2-mkconfig -o /boot/grub2/grub.cfg 2. 3. Actual Results: mkinitrd complained it couldn't find modules for 3.13.0-rc7 although they were present and worked when module-init-tools were installed on the other 2 boxes. Expected Results: Modules should have been picked up by mkinitrd. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 3

[opensuse-factory] Changes in Factory
by Jos Poortvliet 16 Jan '14

16 Jan '14

Hi all, We have digested most of your input on our proposed changes to the factory development workflow. Based on that, we'll be making some more concrete plans on what to hack on first to get there, like the openQA integration and staging projects. Next week our team has a meeting in Nuremberg and we'll have a more concrete plan after that. Feedback and offers for help continue to be welcome! The openSUSE Team

1 0

[opensuse-factory] new package: mozjs24
by Wolfgang Rosenauer 16 Jan '14

16 Jan '14

Hi, I've just created a submitrequest to Factory for the source package mozjs24 (Mozilla JS engine version 24). This is basically an update for mozjs17 and not a real new package. mozjs17 has to stay though until all consumers have been changed to use mozjs24. mozjs17 is unmaintained from a security perspective so depending projects should look into migrating to use mozjs24 instead. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 6