February 2017 - openSUSE Factory - openSUSE Mailing Lists

[opensuse-factory] acpid requires systemd?
by Felix Miata 25 Apr '24

25 Apr '24

Can this be true? If so, why? Zypper won't let me upgrade acpid without breakage unless systemd is installed too. I have systemd locked out, as I'd rather test things I can understand in Factory, not major overhaul stuff. -- "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 For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

4 3

[opensuse-factory] receiving files via bluetooth fails
by Olaf Hering 24 Sep '17

24 Sep '17

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 5

[opensuse-factory] Leap 42.3 status update and roadmap proposal
by Ludwig Nussel 22 Jun '17

22 Jun '17

Hi, As announced in December¹, Leap 42.3 is already open for submissions. We shouldn't expect big updates in 42.3, nevertheless some went in already, like texlive 2016. Also, some packages that we already know SLE will take from Factory also got updated like e.g. YaST. So far the current state looks quite good in openQA² so the adventurous may already zypper dup. What's missing still is a roadmap for the release. SLE12SP3 aims for a release in September. Due to the holiday season in August where many developers are likely unavailable anyways development is expected to be finished before. So my proposal would be to also finish with Leap before and aim for a release at the last Wednesday of July. With regard to the release model I'd like to try something new. Rather than having fixed milestones with fixed submission deadlines every few weeks let's try to adopt a model similar to Tumbleweed's. Ie have snapshots released automatically based on openQA results. Nevertheless the closer we get to the release the stricter the rules for updating packages have to be. cu Ludwig [1] https://lists.opensuse.org/opensuse-factory/2016-12/msg00165.html [2] https://openqa.opensuse.org/group_overview/28 -- (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

10 18

[opensuse-factory] new package: akonadi-ews
by Michal Hlavac 24 Apr '17

24 Apr '17

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

6 12

[opensuse-factory] openSUSE:Leap:42.3 started
by Ludwig Nussel 05 Apr '17

05 Apr '17

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

7 14

[opensuse-factory] RFC: new system user handling
by Thorsten Kukuk 01 Apr '17

01 Apr '17

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 5

[opensuse-factory] Spec-cleaner as format_spec_file replacement round 2
by Tomas Chvatal 20 Mar '17

20 Mar '17

Hello guys, as already discussed here on mailinglist I would like to replace the default formatting solution for the incoming spec-files to be the spec- cleaner instead of the obs-service-format_spec_file. This time we integrated another bunch of fixes for the minimal mode and as a most prominent features/fixes are following two: 1) Possibility to disable the cleaner run [1] which is quite obvious. 2) Codeblock detection to keep relevant things together in preamble [2] With this I also tried to parse all possible kind of approaches we already have in Factory and wrote testcase which covers hopefully all the possible variants [3]. I would love to ask you all to check if your packages are fine and report bugs [4] if any problematic behaviour occurs. To switch between the implementations simply install 'spec-cleaner- format_spec_file' or run 'spec-cleaner -i -m package.spec'. TIA Tom [1] https://github.com/openSUSE/spec-cleaner/issues/148 [2] https://github.com/openSUSE/spec-cleaner/issues/88 [3] https://github.com/openSUSE/spec-cleaner/blob/master/tests/out/code block.spec [4] https://github.com/openSUSE/spec-cleaner/issues

5 8

[opensuse-factory] why is tumbleweed still using cron?
by nicholas 08 Mar '17

08 Mar '17

it seems we have 2 systems for default timed events - systemd and cron - why? - 2 systems is 2X things to learn, 2X things to monitor, 2X things to go wrong - systemd has a (very) nice interface/overview "systemctl list-timers --all" - from limited experience cron bugs/problems can be quite opaque so why is everything not moved to systemd? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

34 195

[opensuse-factory] What pattern(s) install functional Xorg?
by Andrei Borzenkov 06 Mar '17

06 Mar '17

In reminiscence of recent discussion about desktop selection and "but it is easy to add whatever you like using pattern" ... I installed TW using "Text server" option (which resulted in whooping 2.5GB; I remember minimal server was around 600MB in not so distant past, but well, that's different topic). Now I want to add XFCE. I did "zypper in -t pattern --no-recommends xfce". According to "zypper se -t pattern" both XFCE and x11 patterns are installed. But runing "init 5" does nothing. Nor do I even have Xorg available. Looking at pattern names the only pattern mentioning X11 is the one I already have. What gives? How users are supposed to transition from text to GUI after installation? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

10 29

[opensuse-factory] Leap 42.2 in 32bit?
by Mathias Homann 02 Mar '17

02 Mar '17

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

6 5