openSUSE Factory January 2017

factory@lists.opensuse.org

121 participants
91 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

3 years, 8 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

4 years, 1 month

[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

4 years, 2 months

[opensuse-factory] RFC: new system user handling

by Thorsten Kukuk

Hi, the current handling of system accounts on openSUSE is a little bit "chaotic". We have aaa_base creating a lot of standard users, but nobody knows if they are still needed at all. Same for groups. Additional, we have some accounts, which 99,99% of the users will never need (like uucp), but will always be created, including the home directories. And to make the chaos really perfect, we have systemd (/usr/lib/sysusers.d/basic.conf), which creates system users and groups, which partly are also part of aaa_base. That's very confusing and error prune. At end, we also have packages creating users via useradd (which itself is fine and which we don't want to change) and other packages requiring this packages, only because they need that user. Or they create the user a second time with sligthly incompatible data. That's why we thought the last months about a new way how the system account handling could look like. The idea behind this was, that it should always be possible to find out who requires a user and what the original data was, from which the account was created. RPMs, which need a system user or group, only add a (Pre)Requires to the spec file: Requires(pre): user(<name>) Requires(pre): group(<name>) To store the original data, we decided to use the sysusers.d(5) config files from systemd. The advantage is, it's already there, it's already used by the systemd package, and we don't need to re-invent the wheel. Mid-term we think we need some enhancements to the file format (like being able to specify the login shell), but for the start this works fine. To avoid problems with RPM (including the home directory in the filelist with the correct permissions and ownership), the users and groups needs to be created already in the Pre-Install section. But since the config file is only written to disk later, the data needs to be added to the %pre section, too. For this, we created some macros in a package "sysuser-tools". A spec file would contain the following lines: Source1: system-user-uucp.conf BuildRequires: sysuser-tools %package -n system-user-uucp Summary: System user and group uucp %sysusers_requires %build %sysusers_generate_pre %{SOURCE1} uucp %pre -n system-user-uucp -f uucp.pre %files -n system-user-uucp %defattr(-,root,root) %dir %attr(0750,uucp,uucp) %{_sysconfdir}/uucp A full example for many more users/groups and adjusted packages, including aaa_base and filesystem, can be found at: https://build.opensuse.org/project/show/home:kukuk:sysusers Not all system accounts are converted yet, but to start, we don't need to do that. This will be a moving target, but should be easy and quick doable for most system user. And how does this solve our problems? As long as there are packages, which require this user, the RPM creating the account will be pulled in automatically. If you think an account is no longer needed, you can try to deinstall the package creating the account. If this succeeds, you can manually remove the user (userdel -r ...). Should this replace all usages of useradd? We don't think so. There is no reason to do so, except one package creates an account a ot of other packages need, too. Your comments? Any ideas or code for improvement? If not, we will start in about two to three weeks to incorporate that in Factory. Thanks, Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 years, 2 months

[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

4 years, 3 months

[opensuse-factory] Shape of btrfs in openSUSE

by Jan Ritzerfeld

4 years, 3 months

Re: [opensuse-factory] s2disk = hibernate issues

by nicholas

On Wednesday, 25 January 2017 22:40:14 CET you wrote: > nicholas wrote: > > On Wednesday, 25 January 2017 22:03:22 CET you wrote: > >> Frankly I don't know what "early mode setting" is. > >> But I'm eager to learn about it. > >> > >> But I've tested using i915.semaphores=1 or not and it does not make a > >> difference (anymore). > > > > im not an expert in the twisted world of graphics but used it to solve tty > > font problem: > > in etc/default/grub add i915.modeset=1 to the end of > > GRUB_CMDLINE_LINUX_DEFAULT and remake > > Thanks for the hint. But i915.modeset=1 does not make a difference either. > > > can check which driver your using first with > > grep -P "(L|Unl)oading" /var/log/Xorg.0.log > > add see which one does not get unloaded > > # grep -P "(L|Unl)oading" /var/log/Xorg.0.log > [ 27.046] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so > [ 27.062] (II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so > [ 27.069] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so > [ 27.072] (II) Loading /usr/lib64/xorg/modules/drivers/fbdev_drv.so [ > 27.076] (II) Loading /usr/lib64/xorg/modules/drivers/vesa_drv.so [ > 27.096] (II) Loading sub module "fbdevhw" > [ 27.097] (II) Loading /usr/lib64/xorg/modules/libfbdevhw.so > [ 27.099] (II) Loading sub module "dri3" > [ 27.099] (II) Loading sub module "dri2" > [ 27.099] (II) Loading sub module "present" > [ 27.099] (II) Unloading modesetting > [ 27.099] (II) Unloading fbdev > [ 27.099] (II) Unloading fbdevhw > [ 27.099] (II) Unloading vesa > [ 27.319] (II) Loading /usr/lib64/xorg/modules/input/libinput_drv.so > [ 27.549] (II) Loading /usr/lib64/xorg/modules/input/synaptics_drv.so > > Ciao, Michael. looks to me like there is something wrong, since you specify modesetting and it is then unloaded. have you a config file e.g. in /usr/share/X11/xorg.conf.d/ which is contradicting? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 years, 4 months

[opensuse-factory] openSUSE reproducible build test results

by Bernhard M. Wiedemann

Hi, For https://reproducible-builds.org/ I just finished rebuilding all of openSUSE:Factory again. Using the common approach of double-build with variations in date+time+hostname implemented in my "rebuildmany" / rb4 script in the reproducibleopensuse repo. https://www.zq1.de/~bernhard/linux/reproducibleopensuse/compare.factory-201… contains all resulting diffs (after our build-compare filters) This was setting SOURCE_DATE_EPOCH and using 'osc build' that normalizes UID, umask, build path, locale, TZ etc my rbstats scripts summarized the results thus: total-packages: 9918 build-tried: 9918 build-failed: 1025 build-n-a: 63 build-succeeded: 8830 build-official-failed: 45 # also failed in OBS build-compare-failed: 598 build-compare-succeeded: 8232 bit-by-bit-identical: 0 so still plenty of work to do, even before we start reducing the filters in build-compare if you are maintaining a package in Factory, you can have a look at the diffs above and see if you can figure out how to avoid that diff or look at https://www.zq1.de/~bernhard/linux/reproducibleopensuse/compare.factory-201… to see if your package failed to build. For haskell packages I already filed https://bugzilla.opensuse.org/show_bug.cgi?id=1018895 and you can ignore the non-x86 packages like uboot* but there are still plenty others some of which fail their testsuite when running with chroot (instead of kvm like in OBS (which somehow is broken on my host)) Ciao -- Bernhard M. Wiedemann software engineer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 years, 4 months

[opensuse-factory] 1. KDE Applications 16.12 => 16.08 // 2. Only update to matured versions of KDE // trigger warning!

by AW

Hi! Since December 16th Akonadi and (at least) kmail for many users are close to unuseable due to bugs in the akonadi ecosystem, e.g. see here: https:// bugs.kde.org/show_bug.cgi?id=374734 . I'd like to suggest to go back to the last stable version of KDE Applications, which probably was 16.08.*. I'd really like get rid of this (16.12.*) akonadi version and we can't expect a patch soon, because if patching were easy, six weeks would have been enough to patch it. Then I've had a look into the bug list of kdepim here: https://mail.kde.org/pipermail/kdepim-bugs/2017-January/thread.html This is plainly alarming. So I had a look at earlier months' bug list, which didn't appear to have been much better. So much traffic about bugs for an basic application of the whole KDE system! To me it seems obvious that the development is in trouble and the monthly updates may any time break a working system. I can't and I won't blame anybody for the state of KDE. But from my point of view as a mere user, who'd like to have a more or less working computer, the poor condition of KDE Applications isn't compatible to a rolling release. So I'd like to suggest to change the way Tumbleweed provides KDE updates: Let's only have an update to a matured version, like KDE Applications 16.08.3 was and hopefully 16.12.3 or later will be. Same for KDE Plasma and KDE Frameworks. Sorry for my blunt words. If you, the community of openSuse, judge differently, no problem. I simply can go and install e.g. Leap. But I hope to be able to communicate my argument clearly, without offending someone: You can't call a distro a rolling release, while bugs render the email system close to unusable, for many users and many weeks. Regards, Alexander -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 years, 4 months

Re: [opensuse-factory] Next snapshot with updated systemd and plymouth

by Robby Engelmann

Ohh, there are more than that one. I remember, that I also commented on one of these: no graphical input, instead textmode input is shown. The question is, whether these are indeed related... This time, no imput is shown at all (here in approx. 20% of the reboots). Cheers, Robby. -- On Dienstag, 31. Januar 2017 15:55:56 CET Jeroen Mathon wrote: > Hey Robby, > > It seems that Chan Ju Ping also made a bug report in 2016. > > https://bugzilla.opensuse.org/show_bug.cgi?id=997200 > > Perhaps also worth looking at or marking as duplicate to avoid people > recreating the wheel. > > On 31-01-17 15:48, Robby Engelmann wrote: > > You may want to have a look here: > > https://bugzilla.novell.com/show_bug.cgi?id=1020283

4 years, 4 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

openSUSE Factory January 2017