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,
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
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
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
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
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
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