Design Suite November 2017

design-devel@lists.fedoraproject.org

1 participants
16 discussions

[Bug 1384180] New: Cannot add movies to Blender
by Red Hat Bugzilla 03 Dec '18

03 Dec '18

https://bugzilla.redhat.com/show_bug.cgi?id=1384180 Bug ID: 1384180 Summary: Cannot add movies to Blender Product: Fedora Version: 24 Component: blender Assignee: luya_tfz(a)thefinalzone.net Reporter: yajo.sk8(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: design-devel(a)lists.fedoraproject.org, hobbes1069(a)gmail.com, jochen(a)herr-schmitt.de, kwizart(a)gmail.com, luya_tfz(a)thefinalzone.net, promac(a)gmail.com Description of problem: Using its built-in Video Sequence Editor, I cannot input any video file. Version-Release number of selected component (if applicable): blender-2.77a-1.fc24.x86_64 How reproducible: Always Steps to Reproduce: 1. Open Blender. 2. Open its Video Sequence Editor. 3. Press Shift+A. 4. Choose "Video". 5. Choose a video file. Actual results: UI says: File /home/yajo/Vídeos/GOPR4948-20161012-194939.webm could not be loaded Console logs say: not an anim: /home/yajo/Vídeos/GOPR4948-20161012-194939.webm Expected results: File loaded. Additional info: I only tried with MP4 and webm files. This thread seems related: http://blender.stackexchange.com/questions/28839/cannot-load-movie-files-on… It suggests to add ffmpeg support at compile time. I hope that's possible. I have ffmpeg installed from RPMFusion, with no luck. -- You are receiving this mail because: You are on the CC list for the bug.

2 22

[Bug 1513797] New: Does not want to start
by bugzilla＠redhat.com 28 Nov '18

28 Nov '18

https://bugzilla.redhat.com/show_bug.cgi?id=1513797 Bug ID: 1513797 Summary: Does not want to start Product: Fedora Version: 27 Component: swatchbooker Assignee: luya_tfz(a)thefinalzone.net Reporter: harlequin78(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: design-devel(a)lists.fedoraproject.org, luya_tfz(a)thefinalzone.net, negativo17(a)gmail.com Swatchbooker 0.8-0.3.20170131gitc5c8b02.fc27 вoes not want to start on fresh install: Traceback (most recent call last): File "/usr/share/swatchbooker/swatchbooker.pyw", line 25, in <module> from PIL import ImageQt ImportError: cannot import name ImageQt -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1435423] New: Need to fix wallpaper / background packaging situation
by bugzilla＠redhat.com 27 Nov '18

27 Nov '18

https://bugzilla.redhat.com/show_bug.cgi?id=1435423 Bug ID: 1435423 Summary: Need to fix wallpaper / background packaging situation Product: Fedora Version: rawhide Component: f26-backgrounds Severity: high Assignee: luya_tfz(a)thefinalzone.net Reporter: duffy(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: design-devel(a)lists.fedoraproject.org, luya_tfz(a)thefinalzone.net Description of problem: The packaging bits for providing the default desktop background are overcomplicated and cause issues every release. On top of that, there is a new source package every release, so every release we need to do a new package review. Once the new package is in, we have to adjust stuff in comps/spin-kickstarts. Just using one package with subpackages could save a lot of pain. There is legitimate complexity here, but someone should sit down and think about how this works and come up with a better approach - it should be possible but it's never on anybody's priority list until we get into another situation with wallpapers blocking the release. Going to no alphas in favor of rawhide serving as alpha, we need to change how it works anyway. Roshi offered to write a script to autogenerate a placeholder wallpaper that could be used until draft artwork was ready. Idea from today's F26 alpha go/no-go meeting: 1) After branch you make that have the current release stuff and move the previous one to desktop-backgrounds-f25 subpackage 2) maybe just one source package is OK, it'd have a lot of subpackages but you could just keep them around for as long as you want and the subpackages should have virtual provides 3) when we get to final, we push it to N+1 and at that point it never is an issue again Another idea: 1) the real problem we have here is a) there's far too much unnecessary work to do each cycle to actually meet the requirements and b) no-one seems to have taken responsibility for making sure all that work gets done every cycle, even though it's completely predictable and plannable-for and it should be someone's job as soon as possible after branching to put in the 'real' wallpaper for the release 2) the placeholder wallpaper should just always be in rawhide 3) when we branch the package is updated to the new one 4) the neat thing about doing it that way is that as long as the real wallpaper gets in *some time* before release, we're good, because then all pre-release builds would kinda 'automatically' have different wallpaper from all final releases 5) the placeholder wallpaper can always stay the same or just be changed when someone gets bored of it. it doesn't really matter so long as it's never the same as any final release wallpaper Nirik has volunteered to look into this. CCing adamw, sgallagh, and nb based on their participation / interest. -- You are receiving this mail because: You are on the CC list for the bug.

1 13

[Bug 1435753] New: cant emerge blender in RHEL 7
by bugzilla＠redhat.com 27 Jun '18

27 Jun '18

https://bugzilla.redhat.com/show_bug.cgi?id=1435753 Bug ID: 1435753 Summary: cant emerge blender in RHEL 7 Product: Fedora EPEL Version: epel7 Component: blender Severity: medium Assignee: luya_tfz(a)thefinalzone.net Reporter: joroman(a)rand.org QA Contact: extras-qa(a)fedoraproject.org CC: design-devel(a)lists.fedoraproject.org, jochen(a)herr-schmitt.de, luya_tfz(a)thefinalzone.net, negativo17(a)gmail.com Description of problem: rhel7 wont emerge blender without a dependency problem Version-Release number of selected component (if applicable): How reproducible: very Steps to Reproduce: 1.yum install blender 2. 3. Actual results: fails Expected results: Additional info: [root@redacted]# yum install blender Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager Resolving Dependencies --> Running transaction check ---> Package blender.x86_64 1:2.68a-6.el7 will be installed --> Processing Dependency: blender-fonts = 1:2.68a-6.el7 for package: 1:blender-2.68a-6.el7.x86_64 --> Processing Dependency: google-droid-sans-fonts for package: 1:blender-2.68a-6.el7.x86_64 --> Processing Dependency: /usr/bin/python3 for package: 1:blender-2.68a-6.el7.x86_64 --> Processing Dependency: libspnav.so.0()(64bit) for package: 1:blender-2.68a-6.el7.x86_64 --> Processing Dependency: libpython3.4m.so.1.0()(64bit) for package: 1:blender-2.68a-6.el7.x86_64 --> Processing Dependency: libopenal.so.1()(64bit) for package: 1:blender-2.68a-6.el7.x86_64 --> Processing Dependency: libjemalloc.so.1()(64bit) for package: 1:blender-2.68a-6.el7.x86_64 --> Processing Dependency: libjack.so.0()(64bit) for package: 1:blender-2.68a-6.el7.x86_64 --> Processing Dependency: libboost_regex-mt.so.1.53.0()(64bit) for package: 1:blender-2.68a-6.el7.x86_64 --> Processing Dependency: libboost_locale-mt.so.1.53.0()(64bit) for package: 1:blender-2.68a-6.el7.x86_64 --> Processing Dependency: libboost_filesystem-mt.so.1.53.0()(64bit) for package: 1:blender-2.68a-6.el7.x86_64 --> Processing Dependency: libboost_date_time-mt.so.1.53.0()(64bit) for package: 1:blender-2.68a-6.el7.x86_64 --> Processing Dependency: libOpenImageIO.so.1.5()(64bit) for package: 1:blender-2.68a-6.el7.x86_64 --> Processing Dependency: libOpenColorIO.so.1()(64bit) for package: 1:blender-2.68a-6.el7.x86_64 --> Processing Dependency: libGLEW.so.1.10()(64bit) for package: 1:blender-2.68a-6.el7.x86_64 --> Running transaction check ---> Package OpenColorIO.x86_64 0:1.0.9-4.el7 will be installed --> Processing Dependency: libyaml-cpp.so.0.3()(64bit) for package: OpenColorIO-1.0.9-4.el7.x86_64 --> Processing Dependency: libtinyxml.so.0()(64bit) for package: OpenColorIO-1.0.9-4.el7.x86_64 ---> Package OpenImageIO.x86_64 0:1.5.24-3.el7.1 will be installed --> Processing Dependency: libpugixml.so.1()(64bit) for package: OpenImageIO-1.5.24-3.el7.1.x86_64 --> Processing Dependency: libopencv_highgui.so.2.4()(64bit) for package: OpenImageIO-1.5.24-3.el7.1.x86_64 --> Processing Dependency: libopencv_core.so.2.4()(64bit) for package: OpenImageIO-1.5.24-3.el7.1.x86_64 ---> Package blender.x86_64 1:2.68a-6.el7 will be installed --> Processing Dependency: google-droid-sans-fonts for package: 1:blender-2.68a-6.el7.x86_64 ---> Package blender-fonts.noarch 1:2.68a-6.el7 will be installed ---> Package boost-date-time.x86_64 0:1.53.0-26.el7 will be installed ---> Package boost-filesystem.x86_64 0:1.53.0-26.el7 will be installed ---> Package boost-locale.x86_64 0:1.53.0-26.el7 will be installed --> Processing Dependency: boost-chrono(x86-64) = 1.53.0-26.el7 for package: boost-locale-1.53.0-26.el7.x86_64 --> Processing Dependency: libboost_chrono-mt.so.1.53.0()(64bit) for package: boost-locale-1.53.0-26.el7.x86_64 ---> Package boost-regex.x86_64 0:1.53.0-26.el7 will be installed ---> Package jack-audio-connection-kit.x86_64 0:1.9.9.5-6.el7 will be installed --> Processing Dependency: libffado.so.2()(64bit) for package: jack-audio-connection-kit-1.9.9.5-6.el7.x86_64 ---> Package jemalloc.x86_64 0:3.6.0-1.el7 will be installed ---> Package libGLEW.x86_64 0:1.10.0-5.el7 will be installed ---> Package libspnav.x86_64 0:0.2.3-1.el7 will be installed ---> Package openal-soft.x86_64 0:1.16.0-3.el7 will be installed ---> Package python34.x86_64 0:3.4.5-3.el7 will be installed ---> Package python34-libs.x86_64 0:3.4.5-3.el7 will be installed --> Running transaction check ---> Package blender.x86_64 1:2.68a-6.el7 will be installed --> Processing Dependency: google-droid-sans-fonts for package: 1:blender-2.68a-6.el7.x86_64 ---> Package boost-chrono.x86_64 0:1.53.0-26.el7 will be installed ---> Package libffado.x86_64 0:2.1.0-4.el7 will be installed --> Processing Dependency: libxml++-2.6.so.2()(64bit) for package: libffado-2.1.0-4.el7.x86_64 ---> Package opencv.x86_64 0:2.4.5-3.el7 will be installed ---> Package opencv-core.x86_64 0:2.4.5-3.el7 will be installed ---> Package pugixml.x86_64 0:1.8-1.el7 will be installed ---> Package tinyxml.x86_64 0:2.6.2-3.el7 will be installed ---> Package yaml-cpp03.x86_64 0:0.3.0-4.el7 will be installed --> Running transaction check ---> Package blender.x86_64 1:2.68a-6.el7 will be installed --> Processing Dependency: google-droid-sans-fonts for package: 1:blender-2.68a-6.el7.x86_64 ---> Package libxml++.x86_64 0:2.37.1-1.el7 will be installed --> Finished Dependency Resolution --> Finding unneeded leftover dependencies Found and removing 0 unneeded dependencies Error: Package: 1:blender-2.68a-6.el7.x86_64 (epel) Requires: google-droid-sans-fonts ********************************************************************** yum can be configured to try to resolve such errors by temporarily enabling disabled repos and searching for missing dependencies. To enable this functionality please set 'notify_only=0' in /etc/yum/pluginconf.d/search-disabled-repos.conf ********************************************************************** Error: Package: 1:blender-2.68a-6.el7.x86_64 (epel) Requires: google-droid-sans-fonts You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1478536] New: Blender warnings " X server found. dri2 connection failed!"
by bugzilla＠redhat.com 29 May '18

29 May '18

https://bugzilla.redhat.com/show_bug.cgi?id=1478536 Bug ID: 1478536 Summary: Blender warnings "X server found. dri2 connection failed!" Product: Fedora Version: 26 Component: blender Severity: medium Assignee: luya_tfz(a)thefinalzone.net Reporter: alex(a)malexmedia.net QA Contact: extras-qa(a)fedoraproject.org CC: design-devel(a)lists.fedoraproject.org, hobbes1069(a)gmail.com, jochen(a)herr-schmitt.de, kwizart(a)gmail.com, luya_tfz(a)thefinalzone.net, negativo17(a)gmail.com, promac(a)gmail.com Description of problem: When launching Blender, after switching the rendering engine to "Cycles Render", the terminal displays a large number of errors and warnings: ---- SNIP ---- X server found. dri2 connection failed! DRM_IOCTL_I915_GEM_APERTURE failed: Invalid argument Assuming 131072kB available aperture size. May lead to reduced performance or incorrect rendering. get chip id failed: -1 [22] param: 4, val: 0 ---- SNIP ---- Version-Release number of selected component (if applicable): blender-2.78c-4.fc26.x86_64 How reproducible: Every time. Steps to Reproduce: 1. Launch /usr/bin/blender from within Terminal 2. Switch to "Cycles Render" in upper-right drop down. 3. Observe "dri2 connection failed" error messages repeated several times. Actual results: Blender complains over and over that it cannot connect to DRI. Expected results: Blender should be able to establish appropriate connections to DRI. Additional info: This issue is only reproducible within Wayland. Under Xorg, this issue is not present. -- You are receiving this mail because: You are on the CC list for the bug.

1 22

[Bug 1516972] New: [abrt] blender: ghash_keyhash(): blender killed by SIGSEGV
by bugzilla＠redhat.com 09 Apr '18

09 Apr '18

https://bugzilla.redhat.com/show_bug.cgi?id=1516972 Bug ID: 1516972 Summary: [abrt] blender: ghash_keyhash(): blender killed by SIGSEGV Product: Fedora Version: 27 Component: blender Assignee: luya_tfz(a)thefinalzone.net Reporter: donovancastillo(a)hotmail.com QA Contact: extras-qa(a)fedoraproject.org CC: design-devel(a)lists.fedoraproject.org, hobbes1069(a)gmail.com, kwizart(a)gmail.com, luya_tfz(a)thefinalzone.net, negativo17(a)gmail.com, promac(a)gmail.com Description of problem: I'm trying to render a scene with toon materials and freestyle and blender just turn off after rendering a few frames Version-Release number of selected component: blender-2.79-1.fc27 Additional info: reporter: libreport-2.9.3 backtrace_rating: 4 cmdline: blender crash_function: ghash_keyhash executable: /usr/bin/blender journald_cursor: s=96ffa5f0bff4406f845026613c1736c7;i=948f2;b=155909ae430646b8b521694e006af032;m=4fa1c63d3;t=55ea9b01efccd;x=4f9b4b494bafb3b1 kernel: 4.13.13-300.fc27.x86_64 rootdir: / runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #0 ghash_keyhash at /usr/src/debug/blender-2.79-1.fc27.x86_64/source/blender/blenlib/intern/BLI_ghash.c:146 #1 ghash_lookup_entry at /usr/src/debug/blender-2.79-1.fc27.x86_64/source/blender/blenlib/intern/BLI_ghash.c:427 #2 BLI_ghash_lookup at /usr/src/debug/blender-2.79-1.fc27.x86_64/source/blender/blenlib/intern/BLI_ghash.c:776 #3 id_release_weakref at /usr/src/debug/blender-2.79-1.fc27.x86_64/source/blender/python/intern/bpy_rna.c:278 #4 BPY_id_release at /usr/src/debug/blender-2.79-1.fc27.x86_64/source/blender/python/intern/bpy_rna.c:296 #5 BKE_libblock_free_ex at /usr/src/debug/blender-2.79-1.fc27.x86_64/source/blender/blenkernel/intern/library_remap.c:876 #6 BKE_libblock_free at /usr/src/debug/blender-2.79-1.fc27.x86_64/source/blender/blenkernel/intern/library_remap.c:908 #7 Freestyle::BlenderStrokeRenderer::~BlenderStrokeRenderer() at /usr/src/debug/blender-2.79-1.fc27.x86_64/source/blender/freestyle/intern/blender_interface/BlenderStrokeRenderer.cpp:180 #9 Freestyle::Controller::RenderStrokes(Render*, bool) at /usr/src/debug/blender-2.79-1.fc27.x86_64/source/blender/freestyle/intern/application/Controller.cpp:924 #10 FRS_do_stroke_rendering(Render*, SceneRenderLayer*, int) at /usr/src/debug/blender-2.79-1.fc27.x86_64/source/blender/freestyle/intern/blender_interface/FRS_freestyle.cpp:631 Potential duplicate: bug 1219326 -- You are receiving this mail because: You are on the CC list for the bug.

1 11

[Bug 1483629] Middle mouse button failed on Thinkpad T520/T530
by bugzilla＠redhat.com 15 Nov '17

15 Nov '17

https://bugzilla.redhat.com/show_bug.cgi?id=1483629 Peter Hutterer <peter.hutterer(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution|--- |NOTABUG Flags|needinfo?(ralf(a)linux-mips.o | |rg) | Last Closed| |2017-11-14 20:31:36 --- Comment #10 from Peter Hutterer <peter.hutterer(a)redhat.com> --- I'm pretty sure we've had this behaviour since f22 or so, libinput chose this default very early. Basically: the use-cases for middle-click + drag are few and far in between and mostly limited to 3d applications like blender. The use-case of using those applications with a trackpoint instead of a mouse is even smaller. OTOH, the use-case of needing scrolling with a trackpoint is a comparatively common one. This is just a default, we have to pick one and we went with the more common case. It's one of the cases where we can't make everyone happy which is why we have a configuration option in libinput, even if it hasn't trickled down into the GUI configuration programs yet. I'm closing this bug, Ralf's problem is almost certainly the same and if it's not he can re-open it :) -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1483629] Middle mouse button failed on Thinkpad T520/T530
by bugzilla＠redhat.com 15 Nov '17

15 Nov '17

https://bugzilla.redhat.com/show_bug.cgi?id=1483629 --- Comment #9 from Peter Rathlev <peter(a)rathlev.dk> --- Ah, sorry, I didn't really give due attention to what you wrote. I usually never touch the trackpoint and only in the context of this problem have I found out that the buttons I use technically belong there. You are right, it's the scroll method. I do see POINTER_AXIS events on manipulating the trackpoint with middle mouse button pressed. (And POINTER_MOTION without.) After issuing "xinput set-prop 'TPPS/2 IBM TrackPoint' 'libinput Scroll Method Enabled' 0 0 0" everything works as I expect them to. So I guess that means it's not a bug as such. I assume that the current default setting was chosen for a reason. (A change from Fedora 25 I guess.) I can accept that, though I will argue that having this scroll emulation enabled by default is less than optimal. The problem presents itself in a way that makes it very hard for people like Ralf and me to figure out what the cause is. It just looks like a middle mouse button that doesn't work. On the other hand, maybe Blender and Kerbal Space Program are among only few applications caught in this. In that case one could argue that it was easier to update documentation related to those applications to describe the problem and work arounds. I am on purpose not clearing the needinfo flag since it's probably best if Ralf posts a comment saying whether his problem actually is the same as mine. I hope I haven't just hijacked the bug. :-) -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1483629] Middle mouse button failed on Thinkpad T520/T530
by bugzilla＠redhat.com 14 Nov '17

14 Nov '17

1 0

[Bug 1483629] Middle mouse button failed on Thinkpad T520/T530
by bugzilla＠redhat.com 14 Nov '17

14 Nov '17

https://bugzilla.redhat.com/show_bug.cgi?id=1483629 --- Comment #7 from Peter Rathlev <peter(a)rathlev.dk> --- Thanks for the pointers! At least for me it is not related to any kind of scrolling. In Kerbal Space Program the pointer behaves exactly like the middle mouse button was never pressed, until release, at which point it very very briefly acts as if pressed. I tried "libinput debug-events" and it seems like libinput actually knows when the "pressed" event arrives, but it doesn't print the event to the terminal before the relase event has arrived. So the timestamp relative from process start in third column displays the correct time, but the output line saying this doesn't come until later. The following is an example where I press the mousebuttons 1, 2, 3 in turn, first doing a short-ish click and afterwards holding each button for a few seconds (newlines inserted for readability): # unbuffer libinput debug-events --device=/dev/input/event6 | ts '[%Y-%m-%d %H:%M:%.S]' [2017-11-14 21:40:12.359188] -event6 DEVICE_ADDED TPPS/2 IBM TrackPoint seat0 default group1 cap:p left scroll-nat scroll-button [2017-11-14 21:40:14.064402] event6 POINTER_BUTTON +1.71s BTN_LEFT (272) pressed, seat count: 1 [2017-11-14 21:40:14.173700] event6 POINTER_BUTTON +1.82s BTN_LEFT (272) released, seat count: 0 [2017-11-14 21:40:14.848094] event6 POINTER_BUTTON +2.39s BTN_MIDDLE (274) pressed, seat count: 1 [2017-11-14 21:40:14.848271] event6 POINTER_BUTTON +2.50s BTN_MIDDLE (274) released, seat count: 0 [2017-11-14 21:40:15.502475] event6 POINTER_BUTTON +3.15s BTN_RIGHT (273) pressed, seat count: 1 [2017-11-14 21:40:15.591440] event6 POINTER_BUTTON +3.24s BTN_RIGHT (273) released, seat count: 0 [2017-11-14 21:40:18.858315] event6 POINTER_BUTTON +6.51s BTN_LEFT (272) pressed, seat count: 1 [2017-11-14 21:40:21.432588] event6 POINTER_BUTTON +9.08s BTN_LEFT (272) released, seat count: 0 [2017-11-14 21:40:25.972962] event6 POINTER_BUTTON +10.82s BTN_MIDDLE (274) pressed, seat count: 1 [2017-11-14 21:40:25.973145] event6 POINTER_BUTTON +13.62s BTN_MIDDLE (274) released, seat count: 0 [2017-11-14 21:40:28.991058] event6 POINTER_BUTTON +16.64s BTN_RIGHT (273) pressed, seat count: 1 [2017-11-14 21:40:32.251229] event6 POINTER_BUTTON +19.90s BTN_RIGHT (273) released, seat count: 0 As you can see there are pressed/released events at +10.82s and +13.62s respectively, but the output lines (per ts stamp) appear practically simultaneously. So I wonder, why does libinput seem to hold on to the "pressed" event for the middle mouse button? My guess is that this is what makes both Blender and Kerbal Space Program seem like the button isn't working. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Design Suite November 2017