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
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
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
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
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
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
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
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
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
Hi
I am unable to boot from any snapshot. After selecting the option to boot from a read-only snapshot, and then selecting a snapshot, I see a message that says something like "if OK, run snapper rollback and reboot" but I can't do anything from there. Pressing enter refreshes the screen and I see the same message. I can enter the GRUB menu and such, I just can't actually boot.
Obviously this is quite alarming as I'd always thought I can rely on Snapper and is one of the reasons I'm happy to use Tumbleweed. Any suggestions?
Kind regards,
Huw
