openSUSE Factory October 2013

factory@lists.opensuse.org

132 participants
144 discussions

[opensuse-factory] release notes 13.1 review
by Ludwig Nussel 06 Nov '13

06 Nov '13

Hi, I just had a quick look at the CHECKIT items in http://doc.opensuse.org/release-notes/x86_64/openSUSE/13.1/ and I think the following items should be removed: 2.2. No Network after Installation 2.3. The proprietary NVIDIA driver requires users to have access to /dev/nvidia* devices 3.1. openSUSE Documentation 3.4. Enable Secure Boot in YaST Not Enabled by Default When in Secure Boot Mode 3.5. Wrong Bootloader When Installing from a Live Medium in a UEFI Environment 3.6. Crypted LVM in UEFI Mode Needs /boot Partition 4.1. systemd: Activating NetworkManager with a network.service Alias Link The following items still apply 3.3. UEFI—Unified Extensible Firmware Interface 4.2. SYSLOG_DAEMON Variable Removed 5.2. Configuring Postfix I'm unsure about 5.1. Initializing Graphics with KMS (Kernel Mode Setting) -> It refers to 11.3 so maybe time to remove? 5.3. GNOME: Workaround to Set Shift or Ctrl+Shift as Shortcut Keys for Input Source Selection -> someone from the gnome team may be able to comment here cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

15 34

Re: [opensuse-factory] SOLVED: postfix does not run
by Christian Boltz 06 Nov '13

06 Nov '13

Hello, Am Freitag, 22. März 2013 schrieb Patrick Shanahan: > /etc/postfix/main.cf had @_some-parameter_@ setting for every > "xxxxxxx_directory =" line. > > After correcting "xxxxxxxx_directory =" settings per my Tumbleweed > machine, postfix appears working correctly. > > This mess probably occurred on installing/upgrading postfix: > postfix-2.9.6-2.1.x86_64 Sun Mar 10 11:14:39 2013 > but the rpm main.cf does not contain "@.............@". This sounds like https://bugzilla.novell.com/show_bug.cgi?id=796162 which should be fixed since some time. I'd guess some older postfix package broke your main.cf. Nevertheless, if you want to be really sure, uninstall postfix, move away /etc/postfix and re-install the postfix package. Regards, Christian Boltz -- Argh, ich wollte heute doch gar nicht mehr siggen! [Michael Hoffmann in dag°] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 1

[opensuse-factory] [opensuse-packaging] Re: Some Python questions (Was: Re: devel:language:python3)
by Yamaban 06 Nov '13

06 Nov '13

On Mon, 28 Oct 2013 09:17, Sascha Peilicke <speilicke@...> wrote: > On Thursday 24 October 2013 15:07:49 Adam Spiers wrote: >> Sascha Peilicke (speilicke(a)suse.com) wrote: >>> On Saturday 12 October 2013 14:19:57 you wrote: >>>> Hi Sascha ! >>>> >>>> Is there any possibility we (all python maintainers) discuss our goals >>>> both python2 and python3 ? >>> >>> sure, since Juergen joined recently too, I CC'ed everyone. I dunno how you >>> guys prefer it, we could have an IRC meeting at some point but I guess >>> it's >>> easier to stay with mails just now. Therefore I added opensuse-packaging@ >>> because that's really where we should discuss things. >>> >>>> We receive requests sometimes update and/or >>>> new packages which are Python3 compatible. >>> [snip] >>> In the long run, py3k will gradually replace py2k in openSUSE, that means >>> if the critical mass is reached and most upstreams moved on, py2k pkgs >>> will slowly fade from Factory. Meanwhile, some pkg upstreams already >>> stopped caring for py2k, so their pkgs simply stay with the last working >>> version. Currently it's more manual work, I agree. >> >> Just saw this interesting data-point - Fedora is going to switch to >> Python 3 by default: >> >> http://lwn.net/Articles/571528/ > > Jupp. I guess it's more obvious for Fedora than us since they always want to > be bleeding edge. But what does that mean in reality? They're not likely going > to ditch py2 any time soon. there's just far too much software out there that > needs it. Since RH did a wise choice in standardizing on Python for most of > their tooling, I'd bet they would have to port a whole lot of stuff first. So > in the end it boils down to what /usr/bin/python points too. On openSUSE, it's > the same as /usr/bin/python-2.7. I thought about changing this and we > discussed this in length. Finally, we decided against it [0]. Others than > that, py3k is in very good shape inside 13.1 and will get more packages during > the next dev cycle. > > [0] http://lists.opensuse.org/opensuse-packaging/2013-08/msg00089.html IMHO, we need the first step: separate - the (very) Good (python ver does not matter) - the nice (need either py2 or py3 and be honest about) - the bad (work only with one special python version) - the ugly (need either py2 or py3 and tell not, or lie about) The Good is what we want to prefere, they can point to /usr/bin/python . The nice need to point to either /usr/bin/python2 or /usr/bin/python3 . The bad will have to point to a more specific version, e.g. /usr/bin/python2.7 and need to have a special cared for spec file. Goal would be to get them to the nice point. The ugly, well they will need work, no matter what. The more cleanly defined the needs of a package are the easier it will be to handle it in the long run. We will need a time with a (peacefull) coexistence of python 2 and 3 . Having the programs point to either python2 or python3 is a step in the right direction, and helps to keep the hassle down. Some packages (e.g. calibre) will need special care, no matter what. Our goal should be raising sensitivity upstream. Having them in the know and care about this lowers the problem for all distros. The trouble will be getting some of upstream to care about this. Thats my 2ct on this. - Yamaban. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 2

[opensuse-factory] user@.service was unmasked after zypper dup
by Andrey Borzenkov 04 Nov '13

04 Nov '13

I masked user@.service after update to RC1 because it was reliably causing long delay on shutdown (https://bugzilla.novell.com/show_bug.cgi?id=841544). After zypper dup recently I observed the same delay and was surprised to see user(a)0.service running again. Is not "systemctl mask" presumed to be persistent? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 1

[opensuse-factory] [13.1 RC1] During a yast update, DNS solving was lost.
by Carlos E. R. 04 Nov '13

04 Nov '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, During a yast update (about 200 packages), DNS solving was lost. Machine can no longer solve names, and yast can not continue the update. /etc/resolv.conf contains no DNS IP. File has been modified at 23:15, now it is 23;25. I had to tell network manager to disconnect from wifi, and connect again. Things work again. Bug somewhere? - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlJlnDUACgkQtTMYHG2NR9WTGQCeMTCxyQ0RoWYLski7+3n4YaDA YiUAn1kRryFsZ5vaGjXASQw5Wn9yd5JU =uqwM -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

16 46

[opensuse-factory] brcms oops after tethering WLAN connection
by s131 03 Nov '13

03 Nov '13

Hi, I'm following factory closely and since about more then one week it is no longer possible for me to use tethering my notebook with my Nexus 4 over WLAN: Actually setting up the connection with NetworkManager is no problem. But if I do a HTTP request with a browser, my notebook will immediately and reliably get a kernel Oops, leaving me at the terminal with a blinking keyboard LED and no interaction possible. With a normal WLAN connection I do not have this problem! The circumstances of the problem and the kernel backtrace I get are the same as described in https://lkml.org/lkml/2013/8/19/549: > brcms_c_compute_rtscts_dur > brcms_c_ampdu_finalize > ampdu_finalize > dma_txfast > brcms_c_txfifo > brcms_c_sendpkt_mac80211 > brcms_ops_tx Since the LKML post suggests that this problem may be fixed with 3.11-rc6, I waited until 3.11-rc6 appeared downstream on factory But the problem did not disappear. Unfortunately the LKML post does not mention a bugzilla entry. Can anyone reproduce this problem? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 1

[opensuse-factory] NFSv4 broken?
by Jos Poortvliet 03 Nov '13

03 Nov '13

Hi, I'm bumping into a NFSv4 bug that seems to be the same one as described in this thread: http://markmail.org/thread/lpgltrf5w7rsut7k#query:+page:1+mid:lpgltrf5w7rsu… However, I was running openSUSE 12.3 with the same kernel (from kernel.opensuse.org) so this seemed weird. After more googling and verifying that NFS3 worked fine, I found this: http://lists.opensuse.org/opensuse-bugs/2013-09/msg04062.html And indeed, adding the system on which NFS is running to /etc/hosts solves the problem. I know very little about networking so I'm happy it is working now - however, I can imagine others will bump into the same, upgrading their openSUSE 12.3 and discovering NFS4 won't work anymore in case they don't have the server in /etc/hosts or on their DNS. Should I file a new bug, or re-open https://bugzilla.novell.com/show_bug.cgi?id=842977 as this is on 'real' hardware and not on a VM... ? /J -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 1

[opensuse-factory] samba smb error after 12.3 to 13.1 upgrade
by lynn 01 Nov '13

01 Nov '13

Hi After a distro upgrade 12.3 to 13.1 samba file server we have these errors: No builtin backend found, trying to load plugin No builtin nor plugin backend for tdbsam found I've tried deleting the tdb's and rejoining the domain but nothing. Any ideas anyone? Thanks, Lynn [global] workgroup = HH3 realm = HH3.SITE security = ADS kerberos method = system keytab username map = /home/lynn/smbmap log level = 3 [users] path = /home/users read only = No [profiles] path = /home/profiles read only = No store dos attributes = Yes create mask = 0600 directory mask = 0700 browseable = No guest ok = No printable = No profile acls = Yes csc policy = disable -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 11

Re: [opensuse-factory] dracut tests
by Per Jessen 31 Oct '13

31 Oct '13

Cristian Rodríguez wrote: > On 07/12/2013 05:46 AM, Per Jessen wrote: > > --add-drivers="thermal_sys thermal processor fan scsi_dh scsi_dh_emc > scsi_dh_rdac scsi_dh_hp_sw scsi_dh_alua xgifb scsi_transport_iscsi > libiscsi libiscsi_tcp iscsi_tcp usb-common usbcore ohci-hcd uhci-hcd > ehci-hcd xhci-hcd usbhid hid-logitech-dj hid-generic af_packet e1000e > crc32c-intel" > > that does not make any sense, whatsoever. the needed drivers for your > system are automatically determined with the help of udev. > > Okay. I won't have time to try it out now, but I'm back beginning of > August. I got sidetracked, but this morning I've played some more with dracut - I'm still not getting a system that boots though. I have 'dracut', 'dracut-network' and 'dhcp-client' (seems to be required by the former) installed. Observations: Running "dracut -H <initrd>" produces an initrd slightly smaller that my current one. My system doesn't boot with this initrd. I don't feel convinced that network and iscsi features have been included, but I have not found a way (other than taking the initrd apart) of checking it. Adding '-v' (or multiple) does not increase verbosity except for three extra lines at the end of a run. Adding '-L 5' (or 6) does not increase logging. Adding '-M' produces: bash i18n kernel-modules Omitting driver i2o_scsi rootfs-block terminfo udev-rules Skipping udev rule: 91-permissions.rules systemd base fs-lib shutdown suse Without '-M' I get: *** Including module: bash *** *** Including module: i18n *** *** Including module: kernel-modules *** Omitting driver i2o_scsi *** Including module: rootfs-block *** *** Including module: terminfo *** *** Including module: udev-rules *** Skipping udev rule: 91-permissions.rules *** Including module: systemd *** *** Including module: base *** *** Including module: fs-lib *** *** Including module: shutdown *** *** Including module: suse *** -- Per Jessen, Zürich (11.0°C) http://www.hostsuisse.com/ - virtual server hosting in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 10

[opensuse-factory] beaten path install
by Robert Schweikert 31 Oct '13

31 Oct '13

No issues found with the beaten path install of RC2 -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead Public Cloud Architect rjschwei(a)suse.com rschweik(a)ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0

Jump to page:

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

openSUSE Factory October 2013