openSUSE Factory December 2016

factory@lists.opensuse.org

118 participants
95 discussions

[opensuse-factory] receiving files via bluetooth fails

by Olaf Hering

Some months ago it was possible to receive files via bluetooth with TW. But since some weeks that fails for me. I waited for GNOME 3.20 and the new bluez in the hope it will fix itself, but the failure remains: Apr 05 18:01:28 probook obexd[3042]: CONNECT(0x0), (null)(0xffffffff) Apr 05 18:01:28 probook obexd[3042]: CONNECT(0x0), (null)(0x0) Apr 05 18:01:32 probook obexd[3042]: PUT(0x2), (null)(0xffffffff) Apr 05 18:01:32 probook obexd[3042]: open(/home/olaf/.cache/obexd/GSIBFY): No such file or directory (2) Apr 05 18:01:32 probook obexd[3042]: PUT(0x2), NOT_FOUND(0x44) Apr 05 18:01:32 probook obexd[3042]: DISCONNECT(0x1), (null)(0xffffffff) Apr 05 18:01:32 probook obexd[3042]: DISCONNECT(0x1), SUCCESS(0x20) Apr 05 18:01:32 probook bluetoothd[1520]: Unable to get io data for Object Push: getpeername: Transport endpoint is not connected (107) Apr 05 18:01:32 probook obexd[3042]: disconnected: Transport got disconnected Apr 05 18:02:42 probook obexd[3042]: CONNECT(0x0), (null)(0xffffffff) Apr 05 18:02:42 probook obexd[3042]: CONNECT(0x0), (null)(0x0) Apr 05 18:02:42 probook obexd[3042]: PUT(0x2), (null)(0xffffffff) Apr 05 18:02:42 probook obexd[3042]: open(/home/olaf/.cache/obexd/1OLQFY): Operation not permitted (1) Apr 05 18:02:42 probook obexd[3042]: PUT(0x2), FORBIDDEN(0x43) Apr 05 18:02:42 probook obexd[3042]: DISCONNECT(0x1), (null)(0xffffffff) Apr 05 18:02:42 probook obexd[3042]: DISCONNECT(0x1), SUCCESS(0x20) Apr 05 18:02:42 probook bluetoothd[1520]: Unable to get io data for Object Push: getpeername: Transport endpoint is not connected (107) Apr 05 18:02:42 probook obexd[3042]: disconnected: Transport got disconnected First I tried to remove /home/olaf/.cache/obexd, but nothing seems to feel responsible to create this dir as seen with the first error. Then I created it with mkdir -m07777, and that just gives the EPERM error as before. strace shows that it gets some "forbidden" from dbus. Is receiving files working for anyone else? Also the rfkill thing does not work reliable. NetworkManager finds the device according to syslog, but the GNOME bluetooth thing finds nothing. Something softblocks it: root@probook:~ # hciconfig -a hci0 reset Can't init device hci0: Operation not possible due to RF-kill (132) root@probook:~ # rfkill list all 0: hp-wifi: Wireless LAN Soft blocked: no Hard blocked: yes 1: hp-bluetooth: Bluetooth Soft blocked: no Hard blocked: no 2: phy0: Wireless LAN Soft blocked: no Hard blocked: no 4: hci0: Bluetooth Soft blocked: yes Hard blocked: no Need to run 'rfkill unblock 4' manually to get it going. Once that it done its appearently possible to use the UMTS, and sending a file works as well. Olaf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 years, 7 months

[opensuse-factory] new package: akonadi-ews

by Michal Hlavac

Hi, I've built new package for openSUSE Tumbleweed. Akonadi resource agent for Microsoft Exchange using Exchange Web Services (EWS) protocol. It's my first package so any test or help is appreciated. https://build.opensuse.org/package/show/home:hlavki/akonadi-ews thanks, m. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

5 years

[opensuse-factory] openSUSE:Leap:42.3 started

by Ludwig Nussel

Hi, 42.2 is out of the door, time to relax and wait for the Christmas holidays, right? Well, far from that. We have to prepare for the next release. So for the Leap 42 line that means 42.3 based on SLE12 SP3. In anticipation of that OBS already has openSUSE:Leap:42.3 set up as copy of 42.2. It already accepts submissions. Right now mostly to directly integrate 42.2 maintenance updates. With regard to the schedule SUSE plans to release SLE12 SP3 earlier than the usual November date. It's beneficial for Leap if we get the changes we need into SLE and therefore are able to share sources. So I think it makes sense to follow suit and have our development phase with SP3 too, ie move the release date earlier as well. Due to the shortened development time I don't expect big changes in the base system. 42.3 should keep the promise of continuing an LTS line and mostly collect all 42.2 maintenance updates until then plus even more packages and selected updates from Tumbleweed. I'll propose a more concrete schedule when I know more about SP3. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (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

5 years, 1 month

[opensuse-factory] Leap 42.2 in 32bit?

by Mathias Homann

Hi, on OBS a lot of projects are building for Leap 42.2 in both i586 and X86_64, does this mean Leap 42.2 will be available in 32bit? Cheers MH -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

5 years, 2 months

[opensuse-factory] add pam_faillock for factory, 42.2, SLES 12 SP2

by Jason Newton

I'd consider adding it as an update, too, to 42.1 and SP1, at least in aux repositories - preferably to updates :-). I've spoken with the author of pam_faillock and I believe it to be superior to pam_tally2, particularly concerning handling of screensaver handling. pam_faillock is part of the recommended RHEL configuration for secured computers and holding out for pam_tally2 also presents a nasty non-uniformity for nearly the same functionality (although, weaker). I've asked the author, Tomas Mraz, to make the patch available standalone - which he has provided here: http://people.redhat.com/tmraz/pam_faillock/ I would've have submitted my branch against factory pam incorporating the patch - but unfortunately I seem to be having some automake/libtool issues in the build that I cannot figure out - so I'm going to have to leave that effort to someone who knows those build tools better than I. I also intend to poke upstream to ask them to reconsider adding that patch into master. -Jason -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

5 years, 3 months

[opensuse-factory] nouveau xorg.conf.d

by mh＠mike.franken.de

Hi *, I'm still trying to switch somehow automatically between the nvidia and the nouveau driver, but I ran into a quite annoying problem on both openSuSE Leap 42.2 (even with the latest kernel from the kernel stable repository) and also with the latest Tumbleweed snapshot. I don't have problems, running the nouveau driver if I don't have an xorg.conf.d structure at all, but even with a very tiny structure the X server won't start anymore, and I can't figure out, what I might be missing here. There are three scenarios: 1. No xorg.conf.d structure at all -> nouveau gets loaded, X is starting. Same behaviour with Leap 42.2 ad with Tumbleweed. 2. Tiny xorg.conf.d structure as shown below with a driver entry for nouveau, i.e. Driver "nouveau" -> X server is not starting with an entry "Unknown chipset: NV117" at the end of Xorg.0.log. Same behaviour with Leap 42.2 ad with Tumbleweed. 3. Tiny xorg.conf.d structure as shown below without a driver entry for nouveau -> X server is starting and one can logon via sddm, but a few program starts later, the nouveau driver is crashing with errors like "nouveau 0000:01:00.0: fifo: PBDMA0: 00040000 [PBENTRY] ch 15 [007e351000 X[1413]] subc 0 mthd 0000 data 00000000". This happens with Leap 42.2 only, not with Tumbleweed - with the exact same modules from kernel 4.8.9-1. This is my xorg.conf.d structure: # 00-keyboard.conf: # ................. Section "InputClass" Identifier "system-keyboard" MatchIsKeyboard "on" Option "XkbLayout" "de" Option "XkbModel" "pc105" Option "XkbOptions" "terminate:ctrl_alt_bksp" EndSection # ----------------------------- # 50-device.conf: # ............... Section "Device" Identifier "NVidia_GTX750" Driver "nouveau" EndSection # ----------------------------- # 50-module.conf: # ............... Section "Module" # Disable "glx" EndSection # ----------------------------- # 50-monitor.conf: # ................ Section "Monitor" Identifier "DELL_U2715H" EndSection # ----------------------------- # 50-screen.conf: # ............... Section "Screen" Identifier "Screen_0" Device "NVidia_GTX750" Monitor "DELL_U2715H" EndSection # ----------------------------- # 99-serverlayout.conf: # ..................... Section "ServerLayout" Identifier "SingleHead_Layout" Screen "Screen_0" EndSection # ----------------------------- Any idea, what might be going on here? Thx! Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

5 years, 4 months

[opensuse-factory] Dropping of gstreamer-0_10 from Factory

by Atri Bhattacharya

Dear Tumbleweed users, For the last few months, several people have worked on porting packages dependent on gstreamer v0.10 to updated gstreamer 1.x, and we are left with only a few (unmaintained by upstream?) packages in Factory which are still dependent on the old version and are not portable in a straightforward way. These are (apart from gstreamer-0_10 plugins): * freqtweak * ignuit * kde3-kaffeine * kdemultimedia3 * libucil * moodbar * morituri * pgadmin3 * psi+-plugins-psimediaplugin * python-gstreamer-0_10 * sffview * wxWidgets * wxWidgets-ansi * wxWidgets-wxcontainer * xfce4-mixer * xfce4-volumed I would like to now (in a couple of days) file drop requests for the entire gstreamer-0_10 stack for openSUSE:Factory. This is a consequence of the lack of upstream support for gstreamer < 1.0 (GStreamer 1.0 was released on September 24, 2012), which makes, for instance, security issues such as [1] difficult to track and fix. Having this in the Tumbleweed distro is therefore ill-advised. For Leap starting with 42.3 and beyond, we are, of course, dependent on SUSE for decisions relating to the dropping of gst 0.10, and I understand that it is expected to be maintained at least for the life- times of 42.x releases (please correct me if I am wrong). To summarise, the gstreamer version 0.10.x stack (zypper se gstreamer- 0_10*) will soon be dropped from Factory, which will thereafter only carry upstream maintained stable releases of gstreamer 1.x. If you are a maintainer of any of the above pkgs, please consider patching your app to work with gstreamer 1.x to prevent them from becoming "unresolvable" soon. Thanks for bearing with my long email, and wish everyone a very happy holiday season. Have a lot of fun! [1] https://build.opensuse.org/request/show/447173 -- Atri Bhattacharya Sun 25 Dec 16:49:47 IST 2016 Sent from openSUSE Tumbleweed on my laptop. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

5 years, 4 months

[opensuse-factory] updating tumbleweed - best practices

by nicholas

from experience and looking around forums, how to update tumbleweed correctly is not obvious, and not clearly presented. The lack of guidence is causing confusion and problems. The rest of this post is based on my ASSUMPTION that 'sudo zypper dup --no- allow-vendor-change' is best practice. Forums are filled with confusion over the update process e.g. https://forums.opensuse.org/showthread.php/517451-Differnce-between-zypper-… I have seen other suggestions of (including by forum global moderator) 'zypper up' mostly, 'zypper dup' occasionally, this is without clarfying to disable extra repos. https://forums.opensuse.org/showthread.php/504212-I-get-no-updates-to-Tumbl… there are also MANY implicit postings of problems suggesting the OP is not even aware of the issues. The current update process would appear: non-evident (not communicated, ambiguous (when to up/dup?), non deterministic (its ok to get out of sync sometimes?), error prone (new user forgets to disable extra repos), time consuming mess. in fact, do zypper up/dup really make sense conceptually or functionally to a rolling distribution? The question, IF the 'no allow vendor change' is best practice, should we make a more accessible command for updating out of the box (i.e. zypper tup/or other) and should best practices not be better communicated to new users? - I have 'alias tup=sudo zypper dup --no-allow-vendor-change' in .bashrc - Is the dup default of allow-vendor-change really required for leap upgrade? [my own learning curve was quite painful, you should not underestimate the conceptual overhead to new user of understanding all the zypper ins and outs regarding 'packages not being updated', 'changing vendor' etc -> your basically expecting the noob to learn *everything* in order to get a working and reliable system within the first few months] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

5 years, 4 months

[opensuse-factory] What happened to the usr merge?

by Ruediger Meier

Hi, some years ago we've had big discussions about it... But know the direcories are still not merged and we still have hundreds of duplicate links in /bin and /usr/bin. Some binaries are still only available in /bin. Still many horrible looking spec files. So lazy usr-merge supporters, please finish your job and cleanup the mess. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

5 years, 4 months

[opensuse-factory] Re: [opensuse] btrfs problem - how to run btrfsck on boot

by nicholas

On Saturday, 31 December 2016 11:16:14 CET Lew Wolfgang wrote: > On 12/31/2016 10:33 AM, nicholas wrote: > > comparisons to ext thus far seem to be on the scope of ext etc, not on the > > extra features of btrfs. ext will always be easier to use. btrfs can never > > win based on the metrics you assume. > > > > placed into to*context* of cost vs benefits, i would be extremly > > surprised if the cost of root/update screwups etc is not greater than > > problems with btrfs to the typical user. > > > > btrfs itself and opensuse defaults have improved rapidly this year. > > > > not sure anecdotal review and pointing to a minor problem with recent > > quotas is enough to condem the system. facebook dont seem to think so. > > I'm skeptical about btrfs myself. What are the benefits that will > outweigh the complexity-induced risks? I tried btrfs a few years > ago on a large hardware RAID6 array and experienced filesystem > failures and loss of data when writing more than 16-TB. That experience > and the negative points we've been seeing here convinced me to > continue to use ext-4 on root and xfs everywhere else. I've never > experienced root/update screwups, so where is the value for me > at this point in time? Is it time for me to try it again? If so, why? > > Regards, > Lew My argument was to bring scope and perspective to the argument, my cheer- leading is aimed at the casual user (who are more likely to screw up and probably less able to get get a system up again even after relativly minor breakages - this is especially important on rolling release). your setup sounds more professional, so im not the one to ask! but from what you have written a few years is a long time (especially given first relase 2009). i believe raid 5/6 are still deemed experimental-only by the developers (for which a big fix is in the works). From literature benefits include rollbacks, diffs of new vs old files, (new atomic updates), no bitrot, add/remove space easily, etc... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

5 years, 4 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

openSUSE Factory December 2016