[Bug 2177238] New: [abrt] gnome-calendar: _gtk_widget_is_sensitive(): gnome-calendar killed by SIGSEGV
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2177238
Bug ID: 2177238
Summary: [abrt] gnome-calendar: _gtk_widget_is_sensitive():
gnome-calendar killed by SIGSEGV
Product: Fedora
Version: 38
Hardware: x86_64
Status: NEW
Whiteboard: abrt_hash:a5a4a621fe947a1a3c2837111fa5d4fd6f4c165d;VAR
IANT_ID=workstation;
Component: gnome-calendar
Assignee: gnome-sig(a)lists.fedoraproject.org
Reporter: kparal(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: epel-packagers-sig(a)lists.fedoraproject.org,
gnome-sig(a)lists.fedoraproject.org,
igor.raits(a)gmail.com, klember(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
I edited an event and typed "Prague" into the Location field, then hit Save,
and it crashed.
Version-Release number of selected component:
gnome-calendar-44~rc-1.fc38
Additional info:
reporter: libreport-2.17.8
type: CCpp
reason: gnome-calendar killed by SIGSEGV
journald_cursor:
s=f14ac85b1ea64de087f79c5fe57e0ea5;i=182149;b=dea6d4e9b8bd44e39c68387c509e0aff;m=415c9dd48;t=5f68c5f902a76;x=50a38c7ce484216f
executable: /usr/bin/gnome-calendar
cmdline: /usr/bin/gnome-calendar --gapplication-service
cgroup:
0::/user.slice/user-1000.slice/user@1000.service/app.slice/dbus-:1.2-org.gnome.Calendar@0.service
rootdir: /
uid: 1000
kernel: 6.2.2-301.fc38.x86_64
package: gnome-calendar-44~rc-1.fc38
runlevel: N 5
dso_list: /usr/bin/gnome-calendar gnome-calendar-44~rc-1.fc38.x86_64
(Fedora Project) 1678436218
backtrace_rating: 4
crash_function: _gtk_widget_is_sensitive
comment: I edited an event and typed "Prague" into the Location field,
then hit Save, and it crashed.
Truncated backtrace:
Thread no. 1 (16 frames)
#0 _gtk_widget_is_sensitive at ../gtk/gtkwidgetprivate.h:482
#1 gtk_propagate_event_internal.isra.0 at ../gtk/gtkmain.c:1918
#2 gtk_main_do_event at ../gtk/gtkmain.c:1703
#3 surface_event at ../gtk/gtkwindow.c:4747
#4 _gdk_marshal_BOOLEAN__POINTERv at gdk/gdkmarshalers.c:302
#5 gdk_surface_event_marshallerv at ../gdk/gdksurface.c:463
#6 _g_closure_invoke_va at ../gobject/gclosure.c:895
#9 gdk_surface_handle_event.isra.0 at ../gdk/gdksurface.c:2956
#10 gdk_surface_ensure_motion at ../gdk/gdksurface.c:2473
#11 gdk_surface_flush_events at ../gdk/gdksurface.c:2484
#13 signal_emit_unlocked_R.isra.0 at ../gobject/gsignal.c:3802
#16 _gdk_frame_clock_emit_flush_events at ../gdk/gdkframeclock.c:668
#17 gdk_frame_clock_flush_idle at ../gdk/gdkframeclockidle.c:369
#21 g_main_context_iterate.isra.0 at ../glib/gmain.c:4276
#22 g_main_context_iteration at ../glib/gmain.c:4343
#23 g_application_run at ../gio/gapplication.c:2573
Potential duplicate: bug {crossver_id}
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2177238
5 days, 4 hours
[Bug 2120537] New: 'bodhi updates new' does not report error/warning when setting karma limit below minimal value for package in critical path
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2120537
Bug ID: 2120537
Summary: 'bodhi updates new' does not report error/warning when
setting karma limit below minimal value for package in
critical path
Product: Fedora
Version: rawhide
Status: NEW
Component: bodhi-client
Assignee: thrcka(a)redhat.com
Reporter: zdohnal(a)redhat.com
CC: aurelien(a)bompard.org,
epel-packagers-sig(a)lists.fedoraproject.org,
lenka(a)sepu.cz, thrcka(a)redhat.com
Target Milestone: ---
Classification: Fedora
Hi,
I was surprised why my bodhi update (
https://bodhi.fedoraproject.org/updates/FEDORA-2022-6f5e420e52 ) doesn't show
an option for pushing into stable or why the update is not in stable already,
because the positive karma limit (1) is reached.
On #fedora-devel IRC channel kalev answered:
(09:34:34 AM) zdohnal: Hi all, do you have an idea what blocks this update
https://bodhi.fedoraproject.org/updates/FEDORA-2022-6f5e420e52 from being
pushed to the stable?
(09:38:32 AM) kalev: zdohnal: looks like it's marked as critical path and
because of that, it needs minimum of +2 karma to be pushed to stable
(09:40:19 AM) GrannyGoose left the room (quit: Quit: Going offline, see ya!
(www.adiirc.com)).
(09:41:00 AM) zdohnal: kalev: aha - good to know. However bodhi-client should
give me error when I set karma below this limit...
According to the conversation, there is karma limit for components in critical
path and it is higher - 2 - than the limit set by me - 1, which causes
confusion.
I use 'bodhi updates new' CLI command for creating updates, and I didn't see
any error/warning regarding setting the karma limit too low.
IMHO CLI command has to fail if user tries to set the limit too low, and bodhi
web UI should handle this in some way as well.
Would you mind looking into it?
Version-Release number of selected component (if applicable):
bodhi-client-6.0.1-4.fc37
How reproducible:
always
Steps to Reproduce:
1. $ bodhi updates new --type bugfix --close-bugs --request testing --autokarma
--autotime --stable-karma 1 --unstable-karma -1 --notes "Update for component
in critical path" <critical-component-1.2.3-1.fc37>
Actual results:
No error or warning, bodhi web ui shows user defined limit and the update has
karma to fulfill the limit, but the update is not pushed into stable.
Expected results:
Give error (in both interfaces - CLI and Web UI) if user wants to set lower
karma limit than it is required on the package.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2120537
5 days, 4 hours
[Bug 2093731] New: zbarimg does not read a Code 128 barcode
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2093731
Bug ID: 2093731
Summary: zbarimg does not read a Code 128 barcode
Product: Fedora
Version: 36
Status: NEW
Component: zbar
Severity: high
Assignee: gwync(a)protonmail.com
Reporter: cristian.ciupitu(a)yahoo.com
QA Contact: extras-qa(a)fedoraproject.org
CC: dougsland(a)redhat.com,
epel-packagers-sig(a)lists.fedoraproject.org,
gwync(a)protonmail.com, mchehab(a)infradead.org,
mr.marcelo.barbosa(a)gmail.com, negativo17(a)gmail.com
Target Milestone: ---
Classification: Fedora
Created attachment 1886898
--> https://bugzilla.redhat.com/attachment.cgi?id=1886898&action=edit
Code 128 barcode
Description of problem:
zbarimg does not read a Code 128 barcode
Version-Release number of selected component (if applicable):
zbar-0.23.90-1.fc36.x86_64
How reproducible:
Every time
Steps to Reproduce:
1. zbarimg barcode.png
Actual results:
scanned 0 barcode symbols from 1 images in 0 seconds
WARNING: barcode data was not detected in some image(s)
Things to check:
- is the barcode type supported? Currently supported symbologies are:
. EAN/UPC (EAN-13, EAN-8, EAN-2, EAN-5, UPC-A, UPC-E, ISBN-10, ISBN-13)
. DataBar, DataBar Expanded
. Code 128
. Code 93
. Code 39
. Codabar
. Interleaved 2 of 5
. QR code
. SQ code
. PDF 417
- is the barcode large enough in the image?
- is the barcode mostly in focus?
- is there sufficient contrast/illumination?
- If the symbol is split in several barcodes, are they combined in one image?
- Did you enable the barcode type?
some EAN/UPC codes are disabled by default. To enable all, use:
$ zbarimg -S*.enable <files>
Please also notice that some variants take precedence over others.
Due to that, if you want, for example, ISBN-10, you should do:
$ zbarimg -Sisbn10.enable <files>
Expected results:
(Code 128) 755897201062022179.73
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2093731
5 days, 4 hours
[Bug 2259429] New: ImageMagick-7.1.1.27 is available
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2259429
Bug ID: 2259429
Summary: ImageMagick-7.1.1.27 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: ImageMagick
Keywords: FutureFeature, Triaged
Assignee: luya_tfz(a)thefinalzone.net
Reporter: upstream-release-monitoring(a)fedoraproject.org
QA Contact: extras-qa(a)fedoraproject.org
CC: blaise(a)gmail.com, davide(a)cavalca.name,
epel-packagers-sig(a)lists.fedoraproject.org,
fedora(a)famillecollet.com, luya_tfz(a)thefinalzone.net,
michel(a)michel-slm.name, ngompa13(a)gmail.com,
pampelmuse(a)gmx.at, sergio(a)serjux.com
Target Milestone: ---
Classification: Fedora
Releases retrieved: 7.1.1.27
Upstream release that is considered latest: 7.1.1.27
Current version/release in rawhide: 7.1.1.26-2.fc40
URL: https://imagemagick.org
Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/
More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release...
Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.
Based on the information from Anitya:
https://release-monitoring.org/project/328484/
To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/ImageMagick
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2259429
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-...
1 week
[Bug 2225757] New: diskimage-builder: FTBFS in Fedora rawhide/f39
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2225757
Bug ID: 2225757
Summary: diskimage-builder: FTBFS in Fedora rawhide/f39
Product: Fedora
Version: rawhide
Status: NEW
Component: diskimage-builder
Assignee: amoralej(a)redhat.com
Reporter: releng(a)fedoraproject.org
QA Contact: extras-qa(a)fedoraproject.org
CC: amoralej(a)redhat.com, apevec(a)redhat.com,
bnemec(a)redhat.com, davide(a)cavalca.name,
epel-packagers-sig(a)lists.fedoraproject.org,
jslagle(a)redhat.com, mburns(a)redhat.com,
openstack-sig(a)lists.fedoraproject.org
Blocks: 2168842 (F39FTBFS,RAWHIDEFTBFS)
Target Milestone: ---
Classification: Fedora
diskimage-builder failed to build from source in Fedora rawhide/f39
https://koji.fedoraproject.org/koji/taskinfo?taskID=103568042
For details on the mass rebuild see:
https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
Please fix diskimage-builder at your earliest convenience and set the bug's
status to
ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks,
diskimage-builder will be orphaned. Before branching of Fedora 40,
diskimage-builder will be retired, if it still fails to build.
For more details on the FTBFS policy, please visit:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fai...
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=2168842
[Bug 2168842] Fedora 39 FTBFS Tracker
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2225757
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-...
1 week
[Bug 2253406] New: [abrt] lirc-core: main(): lircd-setup:37:main:AttributeError: module 'configparser' has no attribute 'SafeConfigParser'. Did you mean: 'RawConfigParser'?
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2253406
Bug ID: 2253406
Summary: [abrt] lirc-core: main():
lircd-setup:37:main:AttributeError: module
'configparser' has no attribute 'SafeConfigParser'.
Did you mean: 'RawConfigParser'?
Product: Fedora
Version: 39
Hardware: x86_64
Status: NEW
Whiteboard: abrt_hash:6d2dfe5acadf98aebb748f349d9160f72fa8764a;VAR
IANT_ID=workstation;
Component: lirc
Assignee: leamas.alec(a)gmail.com
Reporter: nigel.jewell(a)grufty.co.uk
QA Contact: extras-qa(a)fedoraproject.org
CC: epel-packagers-sig(a)lists.fedoraproject.org,
hobbes1069(a)gmail.com, jarod(a)redhat.com,
leamas.alec(a)gmail.com, sean(a)mess.org
Target Milestone: ---
Classification: Fedora
Description of problem:
This occurs when the service tries to start from systemd. It looks like this
has been fixed upstream, adding a condition to call
configparser.SafeConfigParser or configparser.ConfigParser based upon python
version.
Version-Release number of selected component:
lirc-core-0.10.0-40.fc39
Additional info:
reporter: libreport-2.17.11
exception_type: AttributeError
interpreter: python3-3.12.0-1.fc39.x86_64
cgroup: 0::/system.slice/lircd-setup.service
cmdline: /usr/bin/python3 /usr/sbin/lircd-setup
type: Python3
reason: lircd-setup:37:main:AttributeError: module 'configparser' has
no attribute 'SafeConfigParser'. Did you mean: 'RawConfigParser'?
kernel: 6.6.2-201.fc39.x86_64
comment: This occurs when the service tries to start from systemd. It
looks like this has been fixed upstream, adding a condition to call
configparser.SafeConfigParser or configparser.ConfigParser based upon python
version.
crash_function: main
package: lirc-core-0.10.0-40.fc39
runlevel: unknown
executable: /usr/sbin/lircd-setup
uid: 0
Truncated backtrace:
lircd-setup:37:main:AttributeError: module 'configparser' has no attribute
'SafeConfigParser'. Did you mean: 'RawConfigParser'?
Traceback (most recent call last):
File "/usr/sbin/lircd-setup", line 51, in <module>
main()
File "/usr/sbin/lircd-setup", line 37, in main
parser = configparser.SafeConfigParser()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: module 'configparser' has no attribute 'SafeConfigParser'. Did
you mean: 'RawConfigParser'?
Local variables in innermost frame:
path: '/etc/lirc/lirc_options.conf'
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2253406
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-...
1 week, 1 day
[Bug 2251779] New: python-zope-testrunner fails to build with Python 3.13: ImportError: cannot import name '_start_new_thread' from 'threading'
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2251779
Bug ID: 2251779
Summary: python-zope-testrunner fails to build with Python
3.13: ImportError: cannot import name
'_start_new_thread' from 'threading'
Product: Fedora
Version: rawhide
Status: NEW
Component: python-zope-testrunner
Assignee: loganjerry(a)gmail.com
Reporter: ksurma(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: aurelien(a)bompard.org,
epel-packagers-sig(a)lists.fedoraproject.org,
infra-sig(a)lists.fedoraproject.org, ksurma(a)redhat.com,
loganjerry(a)gmail.com, mhroncok(a)redhat.com,
michel(a)michel-slm.name
Blocks: 2244836 (PYTHON3.13)
Target Milestone: ---
Classification: Fedora
python-zope-testrunner fails to build with Python 3.13.0a1.
This report is automated and not very verbose, but we'll try to get back here
with details.
+ python3 -m unittest discover -s zope/testrunner -t .
.........................................E
======================================================================
ERROR: zope.testrunner.tests.test_threadsupport
(unittest.loader._FailedTest.zope.testrunner.tests.test_threadsupport)
----------------------------------------------------------------------
ImportError: Failed to import test module:
zope.testrunner.tests.test_threadsupport
Traceback (most recent call last):
File "/usr/lib64/python3.13/unittest/loader.py", line 394, in _find_test_path
module = self._get_module_from_name(name)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.13/unittest/loader.py", line 337, in
_get_module_from_name
__import__(name)
File
"/builddir/build/BUILDROOT/python-zope-testrunner-6.2-1.fc40.x86_64/usr/lib/python3.13/site-packages/zope/testrunner/tests/test_threadsupport.py",
line 16, in <module>
from threading import _start_new_thread
ImportError: cannot import name '_start_new_thread' from 'threading'
(/usr/lib64/python3.13/threading.py). Did you mean: '_start_joinable_thread'?
----------------------------------------------------------------------
Ran 42 tests in 0.014s
https://docs.python.org/3.13/whatsnew/3.13.html
For the build logs, see:
https://copr-be.cloud.fedoraproject.org/results/@python/python3.13/fedora...
For all our attempts to build python-zope-testrunner with Python 3.13, see:
https://copr.fedorainfracloud.org/coprs/g/python/python3.13/package/pytho...
Testing and mass rebuild of packages is happening in copr.
You can follow these instructions to test locally in mock if your package
builds with Python 3.13:
https://copr.fedorainfracloud.org/coprs/g/python/python3.13/
Let us know here if you have any questions.
Python 3.13 is planned to be included in Fedora 41.
To make that update smoother, we're building Fedora packages with all
pre-releases of Python 3.13.
A build failure prevents us from testing all dependent packages (transitive
[Build]Requires),
so if this package is required a lot, it's important for us to get it fixed
soon.
We'd appreciate help from the people who know this package best,
but if you don't want to work on this now, let us know so we can try to work
around it on our side.
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=2244836
[Bug 2244836] Python 3.13
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2251779
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-...
1 week, 3 days
[Bug 2259368] New: blender package has no content in the blender man page
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2259368
Bug ID: 2259368
Summary: blender package has no content in the blender man page
Product: Fedora
Version: 39
Hardware: x86_64
OS: Linux
Status: NEW
Component: blender
Keywords: Documentation
Severity: medium
Assignee: luya_tfz(a)thefinalzone.net
Reporter: moschleg(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: code(a)musicinmybrain.net,
design-devel(a)lists.fedoraproject.org,
epel-packagers-sig(a)lists.fedoraproject.org,
kwizart(a)gmail.com, luya_tfz(a)thefinalzone.net,
negativo17(a)gmail.com
Target Milestone: ---
Classification: Fedora
The 'blender' package blender-4.0.2-1.fc39.x86_64 was installed and the man
page was attempted to be read:
$ man blender
Manual page blender(1) byte 0/0 (END) (press h for help or q to quit)
but the man page was empty. The package was checked and it was apparent the
package man page is empty:
$ rpm -qlv blender | grep /man/
-rw-r--r-- 1 root root 20 Dec 9 19:00
/usr/share/man/man1/blender.1.gz
The -qlv shows the man page is 20 bytes which is the size of an 0 byte file
that's been gzipped. Directly checking by ungzipping to stdout also showed
it's empty:
$ gzip -dc /usr/share/man/man1/blender.1.gz | wc -c
0
Reproducible: Always
Steps to Reproduce:
1. Install blender rpm package for 4.0.2-1.fc39
2. run "man blender"
Actual Results:
Man page for blender has no contents
Expected Results:
Packages should not include empty man pages or 'blender' man page should have
the usual type of content expected in man pages like instructions on usage and
so on.
Either not included the blender.1.gz file at all if there's no such manual file
or included related Blender content in the file.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2259368
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-...
1 week, 4 days