September 2016 - openSUSE Factory - openSUSE Mailing Lists

[opensuse-factory] RFC - pattern console still requires wodim
by Dave Plater 05 Sep '16

05 Sep '16

Leap:42.2 is about to go beta and the console pattern still requires wodim which causes cdrtools to be uninstalled. This has caused many problems with the recording of dvds by k3b in the past. This requirement remains due to kiwi having a specific requirement for genisoimage. This requirement is removed in kiwi versions 8x but apparently there are some python packages that can't be accepted. Regards Dave Plater -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

10 25

[opensuse-factory] What method is used to fix a Leap:42.2 package
by Dave Plater 05 Sep '16

05 Sep '16

I wish to help fixing the 32 build failures in Leap:42.2 but when I branched and fixed a package in the past it was rejected with the comment "Use source project openSUSE:Factory" in that case. The first package I picked is gnuradio sourced from 42.1 where it does build. I looked at updating it from Factory but that requires python-Sphinx and python-Pygments updates and I've stopped at a boost update which might lead to other failures. What method shall I use? Thanks Dave Plater -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 2

[opensuse-factory] Cannot find fstrim.timer in util-linux
by Roman Bysh 04 Sep '16

04 Sep '16

Hi, I just installed openSUSE 13.2 (yes I know) on a Crucial MX300 550 GB drive. I'm editing fstab by adding discard and noatime. I have read that continuous trim is not recommended but periodic trim. Hence, the need for fstrim.timer. I also read somewhere about adding an entry to udev rules for non-rotating devices but I cannot find it again. Read the article about setting up an SSD with openSUSE. I have three other drives. 2nd drive is for /data 3rd drive is for Tumbleweed and 42.2 Beta 1 4th has Yosemite However, I still need some help. -- Cheers! Roman IRC: 551368250 ============== -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 1

[opensuse-factory] openSUSE Tumbleweed – Review of the Weeks 2016/35
by Dominique Leuenberger / DimStar 04 Sep '16

04 Sep '16

Dear Tumbleweed users and hackers, Week 35 has ended with a QtCon/Akademy/VideoLAN Dev Days in Berlin and, as was to be expected, a lot of good discussions happened there. But not everybody is in Berlin and some people make sure that Tumbleweed keeps on rolling. As such, we were provided 5 snapshots this week (0825, 0826, 0828, 0830 and 0831). The updates included * KDE Plasma 5.7.4 * KDE Framework 5.25.0 * KDE Applications 16.08.0 * ModemManager 1.6.0 * FFmpeg 3, parallel to FFmpeg 2.8.7 * VirtualBox 5.1.4 And as usual, a bunch of things are queued up for you: * GNOME 3.22 is appearing on the horizon * glibc 2.24 * gcc 6.2 Have a fun time ahead, Dominique

1 0

[opensuse-factory] btrfs incremental backup -- ERROR: cannot find parent subvolume
by Florian Koch 04 Sep '16

04 Sep '16

Hi list, i try to make incremental snapshots from my btrfs datastore: this is my structure: /mnt/datastore <-- btrfs root /mnt/datastore/.snapshot <-- for snapshots (no subvolume) /mnt/datastore_BACKUP <-- Backup btrfs fs first i create a read only snapshot (this works) btrfs subvolume snapshot -r /mnt/datastore /mnt/datastore/.snapshot/$(date +%y%m%d) then i make an initial full send receive (this works) btrfs send /mnt/datastore/.snapshot/160903 | btrfs receive /mnt/datastore_BACKUP/ now i have /mnt/datastore/.snapshot/160903 /mnt/datastore_BACKUP/160903 i create another read only snapshot (on another day) btrfs subvolume snapshot -r /mnt/datastore /mnt/datastore/.snapshot/$(date +%y%m%d) now i have /mnt/datastore/.snapshot/160903 /mnt/datastore/.snapshot/160904 /mnt/datastore_BACKUP/160903 If i try a incremental send receive i got an error btrfs send -p /mnt/datastore/.snapshot/160903 /mnt/datastore/.snapshot/160904 | btrfs receive /mnt/datastore_BACKUP/ At subvol .snapshot/160904 At snapshot 160904 ERROR: cannot find parent subvolume what is wrong with my attempt? cat /etc/os-release NAME="openSUSE Tumbleweed" # VERSION="20160831" ID=opensuse ID_LIKE="suse" VERSION_ID="20160831" PRETTY_NAME="openSUSE Tumbleweed" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:opensuse:tumbleweed:20160831" BUG_REPORT_URL="https://bugs.opensuse.org" HOME_URL="https://www.opensuse.org/" regards flo -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0

[opensuse-factory]
by Chris Murphy 03 Sep '16

03 Sep '16

On Fri, Sep 2, 2016 at 8:27 PM, Jeff Mahoney <jeffm(a)suse.com> wrote: > On 9/1/16 7:39 PM, Chris Murphy wrote: >> On Thu, Sep 1, 2016 at 5:25 PM, Simon Lees <sflees(a)suse.de> wrote: >>> >>> >>> On 09/02/2016 07:47 AM, Chris Murphy wrote: >>>> >>>> So please elucidate the list on exactly what code base you guys are >>>> using for quotas. If you're saying the warnings don't apply to your >>>> implementation then you guys are using something remarkably different >>>> and you need to tell us what that is or you do not get to sit there >>>> and claim this is a community project. >>>> >>> >>> Given that the right people are probably sleeping or close too now, i'll >>> remind you that you can look at openSUSE's kernel source code in the >>> following locations. >>> >>> https://build.opensuse.org/package/show/openSUSE:Leap:42.2/kernel-default >>> https://github.com/openSUSE/kernel >>> https://github.com/openSUSE/kernel-source >>> >>> (Make sure you get the right branches for the git based one). >> >> No, I'm not going to do that and it's inappropriate to even suggest >> it. The people who actually understand the code need to answer the >> question. They are the ones claiming their quota code is stable and >> production ready, the burden is on them to prove it, not for me to >> prove a negative. I'm not spending 1 f'n hour, let alone the likely 20 >> hours it would take me to look over hundreds to thousands of backports >> to find out what you guys have done, that compels you to claim your >> stuff is stable when upstream code is not there yet. > > No, it's not. We publish the code for every single one of our kernels > both in patch series and expanded tree form. Every maintenance update > is tagged and even if they weren't, the last commit that was included in > the RPM is included in the RPM metadata. We also have a very > longstanding, public policy regarding code going upstream and a outsize > percentage of our kernel teams in upstream maintainer roles. So you can > imagine that when someone suggests that we're not being good community > members with our kernels, it ruffles a few feathers. You're the one > leveling an accusation (using typically incorrect assumptions). You > bring the proof. 1. On the Btrfs mailing list, most every time anyone has a quota problem, they're informed if they need stable quota support to use XFS or ext4. And not a single Btrfs developer ever contradicts that advice in the slightest way. And this most recent non-contradicted advice happened just a few weeks ago. The very first time I have ever read anywhere, by any Btrfs developer, that enabling quotas is considered stable, was on this list. 2. https://github.com/kdave/btrfs-progs/commit/637c005ac881a7def923e3f56c9f928… Upstream has performance and stability concerns in the current code. That commit is two weeks old. 3. There have been two attempts at quotas on Btrfs, which caused users all sorts of problems and were ultimately abandoned in favor of the current code base. Therefore my concern about quotas is not unfounded, is not unreasonable, and I'm not alone in that concern. I have explicitly invited having my assumptions contradicted, most notably at the very top of this email, and that was not the first time. Matthias, Richard, and some of your comments, while circumspect, can be inferred to mean your quota code substantially differs from the current stable kernel, and that's why you consider it stable. But then just yesterday you say "the only [Btrfs] patches we have applied to the 4.4-based SLE12-SP2/Leap kernel are backports and patches we've submitted upstream". I see that as an incongrucency with 1, 2, and 3. I cannot rectify the inconsistency with the available information. There are patches you've applied, that are not applied upstream, that wipe away the performance and stability concern in a barely two week old commit? OK... -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0

[opensuse-factory] HEADS UP synaptic touchpad users
by Florian Koch 03 Sep '16

03 Sep '16

Hi, all synaptics touchpad users should be aware of this bug: https://bugzilla.opensuse.org/show_bug.cgi?id=981924 regards flo -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0

[opensuse-factory] slow libreoffice
by Michal Hlavac 03 Sep '16

03 Sep '16

hi, using latest tumbleweed snapshot (nvidia driver 367.27) and libreoffice is very slow (e.g. switch between sheets in oocalc is about 2 - 3 seconds). And it looks like problem with UI drawing. And also I noticed that main menu is blinking when mouse moves over it. thanks, miso -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 4

[opensuse-factory] amdgpu MULLINS (R5) experimental support and xf86-video-amdgpu
by Malcolm 03 Sep '16

03 Sep '16

Hi Following on from the enabling of experimental support for Sea Island cards (Ref: <https://lists.opensuse.org/opensuse-kernel/2016-08/msg00010.html> ) I have a MULLINS card, which if I build the amdgpu kernel module and add the missing line to support (Ref: <http://kernel.opensuse.org/cgit/kernel/commit/?h=stable&id=ac9a015a9094695e…> ) The kernel module loads up fine on Tumbleweed 4.7.0-2-default adding the amdgpu.exp_hw_support=1 in the kernel options, however the present xf86-video-amdgpu driver is missing the PCI ID's for the Mullins devices, so I patched and re-generated the relevant files (for my card) and rebuilt the driver, added a 20-amdgpu.conf file and all works fine now. So, is it possible to get this implemented for Tumbleweed, do I branch and submit for openSUSE only? Or do I need to go upstream, since there are more pci ids for other variants and get upstream to add? As a side note, I've also tested on SLED 12 SP2 RC1 4.4 kernel and it works there as well. -- Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890) openSUSE Leap 42.1|GNOME 3.16.2|4.1.27-27-default up 5 days 12:03, 5 users, load average: 0.26, 0.20, 0.23 CPU AMD Athlon(tm) II X4 635 @ 2.90GHz | GPU Nvidia GeForce 8800 GT -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 3

Re: [opensuse-factory] btrfs quotas enabled by default
by Chris Murphy 03 Sep '16

03 Sep '16

On Thu, Sep 1, 2016 at 3:21 PM, Matthias G. Eckermann <mge(a)suse.com> wrote: > Chris, > > I think, you are mixing two things, as also Richard > pointed out: > > 1. SLE 12 SP2 / LEAP 42.2 versus upstream/Tumbleweed. > > SLE 12 SP2 / LEAP 42.2 have a hardened (and less > feature rich) btrfs implementation. Stop being coy and tell me exactly what quota code base you guys are using in the 4.4 kernel you're shipping for Leap. Are you using upstream backports up to and including 4.7? Or 4.8? Or are you using something else and if so what is it? Because that matters. Right now the upstream code is not ready for production use, the upstream position has been it's ready for testing. If your policy is to subject your Leap users to testing substantially changing code (I've lost count how many quota patches have even come in the last month), you're obligated to tell them. Not silently opt them in. > > SUSE is actively participating in making subvolume > quotas more robust for use by snapper. And that's very generous but it doesn't make either the snapper defaults, or silently enabling quota support appropriate. And you don't even need quota support to do what you want with snapper. For a while now there's been a btrfs ioctl to do pretty much what "btrfs fi du" does to show what is unique and what is shared, per subvolume so you can figure out from that what space is being used or is available rather than enabling quotas. > > 2. Depending where you go the manpage from, it is either > from and for upstream (and thus true) or you found a > bug in the manpage for LEAP 42.2 / SLE 12 SP2. In > that case, please open a bug report. Well the only way you get away with that is if you're using an out of tree branch of code for quotas. *shrug* Because the two previous attempts are dead upstream code. And the current code, as I said, is too new and not ready for production and comes with the warnings I've copied from upstream. So just taking out the warnings doesn't make it stable, you know? So please elucidate the list on exactly what code base you guys are using for quotas. If you're saying the warnings don't apply to your implementation then you guys are using something remarkably different and you need to tell us what that is or you do not get to sit there and claim this is a community project. -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 5