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