[Bug 1512193] perl-Unicode-Collate-1.23 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1512193

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Unicode-Collate-1.23-1 |perl-Unicode-Collate-1.23-1
   |.fc28   |.fc28
   ||perl-Unicode-Collate-1.25-1
   ||.fc27
 Resolution|--- |ERRATA
Last Closed||2017-12-10 00:05:18



--- Comment #9 from Fedora Update System  ---
perl-Unicode-Collate-1.25-1.fc27 has been pushed to the Fedora 27 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1515013] perl-Unicode-Collate-1.24 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1515013

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Unicode-Collate-1.24-1 |perl-Unicode-Collate-1.24-1
   |.fc28   |.fc28
   ||perl-Unicode-Collate-1.25-1
   ||.fc27
 Resolution|--- |ERRATA
Last Closed||2017-12-10 00:05:15



--- Comment #6 from Fedora Update System  ---
perl-Unicode-Collate-1.25-1.fc27 has been pushed to the Fedora 27 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1516068] perl-Gearman-2.004.010 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1516068



--- Comment #4 from Fedora Update System  ---
perl-Gearman-2.004.010-1.fc27 has been pushed to the Fedora 27 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1515805] perl-Module-CoreList-5.20171120 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1515805



--- Comment #9 from Fedora Update System  ---
perl-Module-CoreList-5.20171120-1.fc27 has been pushed to the Fedora 27 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1514629] perl-Locale-Codes-3.55 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1514629



--- Comment #4 from Fedora Update System  ---
perl-Locale-Codes-3.55-1.fc27 has been pushed to the Fedora 27 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1378895] 8-bpp TIFF images are broken in the resulting PDF document

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1378895



--- Comment #12 from Fedora Update System  ---
perl-PDF-API2-2.033-3.fc27 has been pushed to the Fedora 27 stable repository.
If problems still persist, please make note of it in this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1514432] perl-CGI-Fast-2.13 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1514432



--- Comment #7 from Fedora Update System  ---
perl-CGI-Fast-2.13-1.fc27 has been pushed to the Fedora 27 stable repository.
If problems still persist, please make note of it in this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1523427] perl-Iterator-Simple-0.07 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1523427



--- Comment #9 from Fedora Update System  ---
perl-Iterator-Simple-0.07-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-2c59d7248e

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1522696] Upgrade perl-Dist-Zilla-Plugin-Git-Contributors to 0.032

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1522696

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Dist-Zilla-Plugin-Git-Contributors-0.032-1.fc27 has been pushed to the
Fedora 27 testing repository. If problems still persist, please make note of it
in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-9d4213887b

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1522693] Upgrade perl-Dist-Zilla-Plugin-CheckChangesHasContent to 0.011

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1522693

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Dist-Zilla-Plugin-CheckChangesHasContent-0.011-1.fc27 has been pushed to
the Fedora 27 testing repository. If problems still persist, please make note
of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-ed13e7c1e4

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1522699] Upgrade perl-experimental to 0.019

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1522699



--- Comment #7 from Fedora Update System  ---
perl-experimental-0.019-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-bb7f68cfa7

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1522709] Upgrade perl-BibTeX-Parser to 1.01

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1522709



--- Comment #7 from Fedora Update System  ---
perl-BibTeX-Parser-1.01-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-101cddfd01

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1504429] perl-Term-Table-0.012 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1504429

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-Term-Table-0.012-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-2b421f97fa

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1522687] Upgrade perl-B-Debug to 1.26

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1522687

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-B-Debug-1.26-1.fc27 has been pushed to the Fedora 27 testing repository.
If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-1894771278

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1524078] New: perl-App-cpm-0.954 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1524078

Bug ID: 1524078
   Summary: perl-App-cpm-0.954 is available
   Product: Fedora
   Version: rawhide
 Component: perl-App-cpm
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 0.954
Current version/release in rawhide: 0.953-1.fc28
URL: http://search.cpan.org/dist/App-cpm/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

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/8399/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: gdb: No symbol table info available

[Ian Kent]

On 10/12/17 02:13, Richard Shaw wrote:
> I'm working on a segfault in the latest version of hedgewars and I can 
> reproduce the crash easy enough and I have installed both the debuginfo for 
> hedgewars and all the packages gdb suggested but the end of the log[1] still 
> says:

Getting all the debuginfo packages that are needed to analyze a core can be 
quite a
challenge.

Did you install all the dependent debuginfo packages?

debuginfo-install hedgewars

Even then there might have some missing.

Once all the dependent debuginfos are installed you could look at the core
to try and find out what's missing with (coredump is the core here):

eu-unstrip -n --core coredump |\
gawk '{TMP=$2; $1=$2=""; print "/usr/lib/debug/.build-id/" substr(TMP,0,2) 
"/" substr(TMP,3,38) $0}'

Using the output from above dnf can be used to work out what's missing
with somewhat less guess work than usual, eg.

dnf provides /usr/lib/debug/.build-id/be/b9dc6f92875b3faa920e09241e8ab98b0e7c27

etc.

> 
> No symbol table info available.
> 
> Any ideas?
> 
> Thanks
> Richard
> 
> [1] $ cat test.log 
> 
> Thread 1 (Thread 0x77fa7300 (LWP 13966)):
> #0  __GI__dl_catch_error (objname=0x28d6c30, errstring=0x28d6c38, 
> mallocedp=0x28d6c28, operate=0x765d4ff0 , args=0x2946aa0)
>     at dl-error-skeleton.c:187
>         errcode = 32767
>         c = {objname = 0x291f050, errstring = 0x291f670, malloced = 
> 0x28d6c28, errcode = 0x7fffd724, env = {{__jmpbuf = {281479271743488, 1, 
>                 281479271743489, 65537, 281479271743489, 140733193388033, 
> 281479271743489, 3340499160213259264}, __mask_was_saved = 65537, 
>               __saved_mask = {__val = {43280784, 0, 140737289327168, 
> 43280792, 45365184, 0, 3340499160213259264, 0, 43280272, 43280272, 
>                   140737289327168, 0, 140737488345416, 140737289324280, 
> 140737323254718, 0}
>         old = 0x2b437c0
> #1  0x765d56a5 in _dlerror_run (operate=operate@entry=0x765d4ff0 
> , args=0x2946aa0) at dlerror.c:163
>         result = 0x28d6c20
> #2  0x765d501f in __dlclose (handle=) at dlclose.c:46
> No locals.
> #3  0x74027bee in CleanupVendorNameEntry 
> (pEntry=pEntry@entry=0x2946790, unused=0x0) at libglxmapping.c:321
>         vendor = 0x2946790
> #4  0x7402a161 in __glXMappingTeardown (doReset=doReset@entry=0) at 
> libglxmapping.c:1061
>         cur__GLXvendorNameHash = 0x2946790
>         tmp__GLXvendorNameHash = 0x0
>         pEntry = 
>         tmp = 
> #5  0x74022dd7 in __glXFini () at libglx.c:2099
>         glas = 
> #6  0x77de74b3 in _dl_fini () at dl-fini.c:235
>         array = 0x742306f0
>         i = 
>         l = 0x28d7160
>         maps = 0x7fffd8a8
>         i = 
>         l = 
>         nmaps = 
>         nloaded = 
>         ns = 0
>         do_audit = 
>         __PRETTY_FUNCTION__ = "_dl_fini"
> #7  0x76239fc8 in __run_exit_handlers (status=0, listp=0x765ce5b8 
> <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, 
>     run_dtors=run_dtors@entry=true) at exit.c:83
>         atfct = 
>         onfct = 
>         cxafct = 
>         f = 
> #8  0x7623a01a in __GI_exit (status=) at exit.c:105
> No locals.
> #9  0x7621f891 in __libc_start_main (main=0x0, argc=0, argv=0x0, 
> init=, fini=, rtld_fini=, 
>     stack_end=0x0) at ../csu/libc-start.c:329
>         result = 
>         unwind_buf = {cancel_jmp_buf = {{jmp_buf = {4309931, 0, 4217114, 
> 140737488346352, 4210861, 140737322809482, 140737322809482, 
>                 140737300163376}, mask_was_saved = -8968}}, priv = {pad = 
> {0x2dd10, 0x404084 , 0x0, 0xb0bfd26695729445}, data = {
>               prev = 0x2dd10, cleanup = 0x404084 , canceltype 
> = 0}}}
>         not_first_call = 
> #10 0x in ?? ()
> No symbol table info available.
> 
> 
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1515805] perl-Module-CoreList-5.20171120 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1515805



--- Comment #8 from Fedora Update System  ---
perl-Module-CoreList-5.20171120-1.fc26 has been pushed to the Fedora 26 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1378895] 8-bpp TIFF images are broken in the resulting PDF document

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1378895
Bug 1378895 depends on bug 1476237, which changed state.

Bug 1476237 Summary: Review Request: perl-Graphics-TIFF - Perl extension for 
the LibTIFF library
https://bugzilla.redhat.com/show_bug.cgi?id=1476237

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1378895] 8-bpp TIFF images are broken in the resulting PDF document

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1378895

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-PDF-API2-2.033-3.fc28  |perl-PDF-API2-2.033-3.fc28
   ||perl-PDF-API2-2.033-2.fc26
 Resolution|--- |ERRATA
Last Closed||2017-12-09 17:24:16



--- Comment #11 from Fedora Update System  ---
perl-Graphics-TIFF-6-1.fc26, perl-PDF-API2-2.033-2.fc26 has been pushed to the
Fedora 26 stable repository. If problems still persist, please make note of it
in this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1514432] perl-CGI-Fast-2.13 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1514432



--- Comment #6 from Fedora Update System  ---
perl-CGI-Fast-2.13-1.fc26 has been pushed to the Fedora 26 stable repository.
If problems still persist, please make note of it in this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Philip Kovacs]

>I deeply believe that such maintainers and such packages as you
>describe must become a thing of a past.  For the moment, until your new world 
>order arrives, packages are maintained by people of all types volunteering 
>their time and effort.  These are people who will probably never even hear a 
>thank you from anyone for their efforts.  One important way to extend to them 
>respect and gratitude for that contribution is to notify them prior to 
>changing the files they spent time maintaining.   It's just simple human 
>courtesy. 

On Saturday, December 9, 2017 2:13 PM, Zbigniew Jędrzejewski-Szmek 
 wrote:
 

 On Sat, Dec 09, 2017 at 06:26:28PM +, Philip Kovacs wrote:
> s/do want/do NOT want 
> 
>    On Saturday, December 9, 2017 1:21 PM, Philip Kovacs  
>wrote:
>  
> 
>  I am opposed to allowing PP unfettered access to projects in which
>  the maintainer(s) are responsive.  It's common for developers to
>  have artistic (volatile) temperaments , like a painter who paints
>  on canvas owned by someone else.

It's possible that this it crux of the difference between different
sides in this thread.

I deeply believe that such maintainers and such packages as you
describe must become a thing of a past. Don't get me wrong — I have
been there, I have done that (über-complicated packages, spec files
full of custom code) — and I think was a waste of time. If a program
requires a complicated spec file, then usually something is wrong with
the program.

Look at the recent fedora-devel thread "Forge-hosted projects
packaging automation": all the valiant efforts by maintainers to
express their creativity by fighting with github and gitlab hosting and
commit hashes and git tags and tarballs are replaced by very-strictly
scripted approach where you just define a few fields and let the
tooling do the rest.

The same story happened with python packaging a while back: all the
ways to call setup.py are replaced by a very boring %py_build and
%py_install invocations.

Fedora as a distro is moving away from arcane setups where only one or
two people can make changes towards team maintenance and having
everything simplified to avoid mistakes and documented to make things
easy for newcomers. I'd say that this is a trend which is true for all
of the Linux ecosystem. People have realized that bus factors of one
or two are bad for long term sustainability. Eh, even the kernel now
has sphinx-based docs so you can actually read the stuff.

The reason why that is happening is that we have ever more packages,
released more often, with a smaller maintainer/package ratio then
ever. If you want to scale, you need to simplify and automate.
Essentially, expressing your creativity/spirit/style in how the
whitespace is organized and how macros are defined is passé.

Zbyszek


  Does the owner have the right to change the color jars?  Perhaps.  Does the  
owner have the right to look at the painting and say "I don't like the way you 
painted that tree.  I'm going to change it."  Absolutely not.
> Perhaps add a project setting that allows package maintainers to configure 
> how PP changes can be made, by direct commit, by pull request, etc.  That 
> would allow maintainerswho are more "involved" with their packages to have 
> more control.   It's a common management problem.  People who have taken on 
> responsibility must also have control to the extent to which system allows.  
> You certainly do want to drive good people away..  
> 
>    On Saturday, December 9, 2017 5:06 AM, Matthias Runge 
> wrote:
>  
> 
>  On Fri, Dec 08, 2017 at 08:30:20PM +0100, Matthias Runge wrote:
> > Now this has gone back and forth. The system worked more or less ok.
> > Maybe it is more about the changes (and communication) of a
> > specific provenpackager?
> 
> After sleeping a night over this, I should have put it in different
> words:
> 
> My questionis are here:
> - do we have an issue at all?
> - do we have an issue with a single provenpacker
> - do we have an issue of attitude or with a group of people?
> 
> The consensus of this long thread was: no, the system works mostly ok.
> That makes me believe, we don't have a generic issue.
> 
> It's not my intention to blame anyone here, I'm still assuming best
> intentions.
> 
> Nevertheless, since people are different, and not everybody can be
> friends with each other, maybe it's a good idea to make communication
> mandatory, in cases where proven packagers touch others packages? For
> mass changes, there is/should always be an announcement to the
> devel mailing list.
> 
> Matthias
> -- 
> Matthias Runge 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
> 
>    
> 
>    

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To 

[Bug 1510678] perl-Finance-Quote-1.44 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1510678

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c26 |c26
   |perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c27 |c27
   |perl-Finance-Quote-1.47-1.e |perl-Finance-Quote-1.47-1.e
   |l7  |l7
   |perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c25 |c25
   ||perl-Finance-Quote-1.47-1.e
   ||l6



--- Comment #42 from Fedora Update System  ---
perl-Finance-Quote-1.47-1.el6 has been pushed to the Fedora EPEL 6 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1512341] perl-Finance-Quote-1.47 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1512341

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c26 |c26
   |perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c27 |c27
   |perl-Finance-Quote-1.47-1.e |perl-Finance-Quote-1.47-1.e
   |l7  |l7
   |perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c25 |c25
   ||perl-Finance-Quote-1.47-1.e
   ||l6



--- Comment #24 from Fedora Update System  ---
perl-Finance-Quote-1.47-1.el6 has been pushed to the Fedora EPEL 6 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1511240] perl-Finance-Quote-1.45 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1511240

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c26 |c26
   |perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c27 |c27
   |perl-Finance-Quote-1.47-1.e |perl-Finance-Quote-1.47-1.e
   |l7  |l7
   |perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c25 |c25
   ||perl-Finance-Quote-1.47-1.e
   ||l6



--- Comment #32 from Fedora Update System  ---
perl-Finance-Quote-1.47-1.el6 has been pushed to the Fedora EPEL 6 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1509722] perl-Finance-Quote-1.40 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1509722

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Finance-Quote-1.41-1.f |perl-Finance-Quote-1.41-1.f
   |c28 |c28
   |perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c26 |c26
   |perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c27 |c27
   |perl-Finance-Quote-1.47-1.e |perl-Finance-Quote-1.47-1.e
   |l7  |l7
   |perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c25 |c25
   ||perl-Finance-Quote-1.47-1.e
   ||l6



--- Comment #54 from Fedora Update System  ---
perl-Finance-Quote-1.47-1.el6 has been pushed to the Fedora EPEL 6 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1510220] perl-Finance-Quote-1.42 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1510220

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Finance-Quote-1.43-1.f |perl-Finance-Quote-1.43-1.f
   |c28 |c28
   |perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c26 |c26
   |perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c27 |c27
   |perl-Finance-Quote-1.47-1.e |perl-Finance-Quote-1.47-1.e
   |l7  |l7
   |perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c25 |c25
   ||perl-Finance-Quote-1.47-1.e
   ||l6



--- Comment #49 from Fedora Update System  ---
perl-Finance-Quote-1.47-1.el6 has been pushed to the Fedora EPEL 6 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: gdb: No symbol table info available

[John Reiser]

I'm working on a segfault in the latest version of hedgewars and I can 
reproduce the crash easy enough ...


Filing a bugzilla report and including a reproducible test case
enables others to help you.  https://bugzilla.redhat.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: gdb: No symbol table info available

[Jan Kratochvil]

On Sat, 09 Dec 2017 20:42:46 +0100, Richard Shaw wrote:
> Any tips?

A correct backtrace would have replaced your line

#10 0x in ?? ()
with line
#10 0x0040043a in _start ()

but otherwise everything would be all the same.

Tips in general for segfaults are valgrind.  Or better recompile it with
-fsanitize=address but then it may (or may not) involve also recompiling glibc
with -fsanitize=address for this case which I have never tried if it works.


Jan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: gdb: No symbol table info available

[Richard Shaw]

On Sat, Dec 9, 2017 at 1:29 PM, Jan Kratochvil 
wrote:

> On Sat, 09 Dec 2017 19:13:24 +0100, Richard Shaw wrote:
> > #9  0x7621f891 in __libc_start_main (main=0x0, argc=0, argv=0x0,
> > init=, fini=, rtld_fini=,
> > stack_end=0x0) at ../csu/libc-start.c:329
> > result = 
> > unwind_buf = {cancel_jmp_buf = {{jmp_buf = {4309931, 0, 4217114,
> > 140737488346352, 4210861, 140737322809482, 140737322809482,
> > 140737300163376}, mask_was_saved = -8968}}, priv = {pad =
> > {0x2dd10, 0x404084 , 0x0, 0xb0bfd26695729445}, data = {
> >   prev = 0x2dd10, cleanup = 0x404084 ,
> > canceltype = 0}}}
> > not_first_call = 
> > #10 0x in ?? ()
> > No symbol table info available.
>
> That is OK, you cannot have symbols for address zero.
>
> What glibc it is? On glibc-2.26-16.fc27.x86_64 I get:
>

glibc-2.25-12.fc26.x86_64 but I've tested on my wife's f27 laptop and got
similar results but haven't done a side by side comparison just yet.



> #2  0x77a2bbda in __GI_exit (status=) at exit.c:105
> No locals.
> #3  0x77a11041 in __libc_start_main (main=0x4004ee , argc=1,
> argv=0x7fffd7b8, init=,
> fini=, rtld_fini=,
> stack_end=0x7fffd7a8) at ../csu/libc-start.c:342
> result = 
> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0,
> -7823762895322290015, 4195344, 140737488345008, 0, 0, 7823762346505857185,
> 7823745254383347873}, mask_was_saved = 0}}, priv = {pad =
> {0x0, 0x0, 0x77de5e83 <_dl_init+259>,
>   0x77dcb790 
> <__elf_set___libc_subfreeres_element_free_mem__>},
> data = {prev = 0x0, cleanup = 0x0,
>   canceltype = -136421757}}}
> not_first_call = 
> #4  0x0040043a in _start ()
> No symbol table info available.
>
> The bug is that GDB should find out the return address from
> __libc_start_main
> (to be 0x40043a in _start) which it does not in your case.
>
> Then "No symbol table info available." is in fact OK for _start as that is
> only asm-coded function with ELF symbol but with no DWARF symbol.


Any tips?

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Fedora EPEL 6 updates-testing report

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 885  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7031   
python-virtualenv-12.0.7-1.el6
 879  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 769  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 740  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 351  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
  80  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4c76ddcc92   
libmspack-0.6-0.1.alpha.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-9882374b91   
wordpress-4.9.1-1.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-678916467d   
exim-4.89-4.el6
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-ed87c07972   
hostapd-2.6-7.el6
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6aaee32b7e   
optipng-0.7.6-6.el6
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-3432442a31   
shellinabox-2.20-5.el6


The following builds have been pushed to Fedora EPEL 6 updates-testing

R-3.4.3-1.el6
hostapd-2.6-7.el6
lcgdm-1.9.1-1.el6
optipng-0.7.6-6.el6
python-pymediainfo-2.2.0-1.el6
shellinabox-2.20-5.el6
spamassassin-iXhash2-2.05-12.el6
tito-0.6.11-1.el6

Details about builds:



 R-3.4.3-1.el6 (FEDORA-EPEL-2017-3e43d7395c)
 A language for data analysis and graphics

Update Information:

Update to R 3.4.3, rebuild rpy and rkward to match.




 hostapd-2.6-7.el6 (FEDORA-EPEL-2017-ed87c07972)
 IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator

Update Information:

Latest hostapd release with KRACK patches applied.

References:

  [ 1 ] Bug #1503874 - KRACK affects hostapd
https://bugzilla.redhat.com/show_bug.cgi?id=1503874
  [ 2 ] Bug #1502588 - CVE-2017-13077 CVE-2017-13078 CVE-2017-13079 
CVE-2017-13080 CVE-2017-13081 CVE-2017-13082 CVE-2017-13086 CVE-2017-13087 
CVE-2017-13088 hostapd: various flaws [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1502588
  [ 3 ] Bug #1468942 - attempting to create Access Point overrides modprobe for 
wifi and crashes
https://bugzilla.redhat.com/show_bug.cgi?id=1468942




 lcgdm-1.9.1-1.el6 (FEDORA-EPEL-2017-738fd741cd)
 LHC Computing Grid Data Management

Update Information:

* new upstream release




 optipng-0.7.6-6.el6 (FEDORA-EPEL-2017-6aaee32b7e)
 PNG optimizer and converter

Update Information:

Security fix for CVE-2017-1000229 and CVE-2017-16938

References:

  [ 1 ] Bug #1520234 - CVE-2017-1000229 optipng: integer overflow in 
tiffread.c:minitiff_read_info() allows for arbitrary code execution
https://bugzilla.redhat.com/show_bug.cgi?id=1520234
  [ 2 ] Bug #1520227 - CVE-2017-16938 optipng: global buffer overflow in 
gifread.c:LZWReadByte when parsing malicious GIF
https://bugzilla.redhat.com/show_bug.cgi?id=1520227




 python-pymediainfo-2.2.0-1.el6 (FEDORA-EPEL-2017-54baa1189e)
 Python wrapper around the MediaInfo library

Update Information:

Added python wrapper around MediaInfo library.

References:

  [ 1 ] Bug #1519844 - Review Request: python-pymediainfo - Python wrapper 
around the MediaInfo library
https://bugzilla.redhat.com/show_bug.cgi?id=1519844




 shellinabox-2.20-5.el6 (FEDORA-EPEL-2017-3432442a31)
 Web based AJAX terminal 

Re: gdb: No symbol table info available

[Jan Kratochvil]

On Sat, 09 Dec 2017 19:13:24 +0100, Richard Shaw wrote:
> #9  0x7621f891 in __libc_start_main (main=0x0, argc=0, argv=0x0,
> init=, fini=, rtld_fini=,
> stack_end=0x0) at ../csu/libc-start.c:329
> result = 
> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {4309931, 0, 4217114,
> 140737488346352, 4210861, 140737322809482, 140737322809482,
> 140737300163376}, mask_was_saved = -8968}}, priv = {pad =
> {0x2dd10, 0x404084 , 0x0, 0xb0bfd26695729445}, data = {
>   prev = 0x2dd10, cleanup = 0x404084 ,
> canceltype = 0}}}
> not_first_call = 
> #10 0x in ?? ()
> No symbol table info available.

That is OK, you cannot have symbols for address zero.

What glibc it is? On glibc-2.26-16.fc27.x86_64 I get:

#2  0x77a2bbda in __GI_exit (status=) at exit.c:105
No locals.
#3  0x77a11041 in __libc_start_main (main=0x4004ee , argc=1, 
argv=0x7fffd7b8, init=, 
fini=, rtld_fini=, stack_end=0x7fffd7a8) 
at ../csu/libc-start.c:342
result = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -7823762895322290015, 
4195344, 140737488345008, 0, 0, 7823762346505857185, 
7823745254383347873}, mask_was_saved = 0}}, priv = {pad = {0x0, 
0x0, 0x77de5e83 <_dl_init+259>, 
  0x77dcb790 <__elf_set___libc_subfreeres_element_free_mem__>}, 
data = {prev = 0x0, cleanup = 0x0, 
  canceltype = -136421757}}}
not_first_call = 
#4  0x0040043a in _start ()
No symbol table info available.

The bug is that GDB should find out the return address from __libc_start_main
(to be 0x40043a in _start) which it does not in your case.

Then "No symbol table info available." is in fact OK for _start as that is
only asm-coded function with ELF symbol but with no DWARF symbol.


Jan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Zbigniew Jędrzejewski-Szmek]

On Sat, Dec 09, 2017 at 06:26:28PM +, Philip Kovacs wrote:
> s/do want/do NOT want 
> 
> On Saturday, December 9, 2017 1:21 PM, Philip Kovacs  
> wrote:
>  
> 
>  I am opposed to allowing PP unfettered access to projects in which
>  the maintainer(s) are responsive.  It's common for developers to
>  have artistic (volatile) temperaments , like a painter who paints
>  on canvas owned by someone else.

It's possible that this it crux of the difference between different
sides in this thread.

I deeply believe that such maintainers and such packages as you
describe must become a thing of a past. Don't get me wrong — I have
been there, I have done that (über-complicated packages, spec files
full of custom code) — and I think was a waste of time. If a program
requires a complicated spec file, then usually something is wrong with
the program.

Look at the recent fedora-devel thread "Forge-hosted projects
packaging automation": all the valiant efforts by maintainers to
express their creativity by fighting with github and gitlab hosting and
commit hashes and git tags and tarballs are replaced by very-strictly
scripted approach where you just define a few fields and let the
tooling do the rest.

The same story happened with python packaging a while back: all the
ways to call setup.py are replaced by a very boring %py_build and
%py_install invocations.

Fedora as a distro is moving away from arcane setups where only one or
two people can make changes towards team maintenance and having
everything simplified to avoid mistakes and documented to make things
easy for newcomers. I'd say that this is a trend which is true for all
of the Linux ecosystem. People have realized that bus factors of one
or two are bad for long term sustainability. Eh, even the kernel now
has sphinx-based docs so you can actually read the stuff.

The reason why that is happening is that we have ever more packages,
released more often, with a smaller maintainer/package ratio then
ever. If you want to scale, you need to simplify and automate.
Essentially, expressing your creativity/spirit/style in how the
whitespace is organized and how macros are defined is passé.

Zbyszek


  Does the owner have the right to change the color jars?  Perhaps.  Does the  
owner have the right to look at the painting and say "I don't like the way you 
painted that tree.  I'm going to change it."  Absolutely not.
> Perhaps add a project setting that allows package maintainers to configure 
> how PP changes can be made, by direct commit, by pull request, etc.  That 
> would allow maintainerswho are more "involved" with their packages to have 
> more control.   It's a common management problem.  People who have taken on 
> responsibility must also have control to the extent to which system allows.  
> You certainly do want to drive good people away..  
> 
> On Saturday, December 9, 2017 5:06 AM, Matthias Runge 
>  wrote:
>  
> 
>  On Fri, Dec 08, 2017 at 08:30:20PM +0100, Matthias Runge wrote:
> > Now this has gone back and forth. The system worked more or less ok.
> > Maybe it is more about the changes (and communication) of a
> > specific provenpackager?
> 
> After sleeping a night over this, I should have put it in different
> words:
> 
> My questionis are here:
> - do we have an issue at all?
> - do we have an issue with a single provenpacker
> - do we have an issue of attitude or with a group of people?
> 
> The consensus of this long thread was: no, the system works mostly ok.
> That makes me believe, we don't have a generic issue.
> 
> It's not my intention to blame anyone here, I'm still assuming best
> intentions.
> 
> Nevertheless, since people are different, and not everybody can be
> friends with each other, maybe it's a good idea to make communication
> mandatory, in cases where proven packagers touch others packages? For
> mass changes, there is/should always be an announcement to the
> devel mailing list.
> 
> Matthias
> -- 
> Matthias Runge 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
> 
>
> 
>

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Philip Kovacs]

s/do want/do NOT want 

On Saturday, December 9, 2017 1:21 PM, Philip Kovacs  
wrote:
 

 I am opposed to allowing PP unfettered access to projects in which the 
maintainer(s) are responsive.  It's common for developers to have artistic 
(volatile) temperaments , like a painter who paints on canvas owned by someone 
else.  Does the owner have the right to change the color jars?  Perhaps.  Does 
the  owner have the right to look at the painting and say "I don't like the way 
you painted that tree.  I'm going to change it."  Absolutely not.
Perhaps add a project setting that allows package maintainers to configure how 
PP changes can be made, by direct commit, by pull request, etc.  That would 
allow maintainerswho are more "involved" with their packages to have more 
control.   It's a common management problem.  People who have taken on 
responsibility must also have control to the extent to which system allows.  
You certainly do want to drive good people away..  

On Saturday, December 9, 2017 5:06 AM, Matthias Runge 
 wrote:
 

 On Fri, Dec 08, 2017 at 08:30:20PM +0100, Matthias Runge wrote:
> Now this has gone back and forth. The system worked more or less ok.
> Maybe it is more about the changes (and communication) of a
> specific provenpackager?

After sleeping a night over this, I should have put it in different
words:

My questionis are here:
- do we have an issue at all?
- do we have an issue with a single provenpacker
- do we have an issue of attitude or with a group of people?

The consensus of this long thread was: no, the system works mostly ok.
That makes me believe, we don't have a generic issue.

It's not my intention to blame anyone here, I'm still assuming best
intentions.

Nevertheless, since people are different, and not everybody can be
friends with each other, maybe it's a good idea to make communication
mandatory, in cases where proven packagers touch others packages? For
mass changes, there is/should always be an announcement to the
devel mailing list.

Matthias
-- 
Matthias Runge 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


   

   ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Philip Kovacs]

I am opposed to allowing PP unfettered access to projects in which the 
maintainer(s) are responsive.  It's common for developers to have artistic 
(volatile) temperaments , like a painter who paints on canvas owned by someone 
else.  Does the owner have the right to change the color jars?  Perhaps.  Does 
the  owner have the right to look at the painting and say "I don't like the way 
you painted that tree.  I'm going to change it."  Absolutely not.
Perhaps add a project setting that allows package maintainers to configure how 
PP changes can be made, by direct commit, by pull request, etc.  That would 
allow maintainerswho are more "involved" with their packages to have more 
control.   It's a common management problem.  People who have taken on 
responsibility must also have control to the extent to which system allows.  
You certainly do want to drive good people away..  

On Saturday, December 9, 2017 5:06 AM, Matthias Runge 
 wrote:
 

 On Fri, Dec 08, 2017 at 08:30:20PM +0100, Matthias Runge wrote:
> Now this has gone back and forth. The system worked more or less ok.
> Maybe it is more about the changes (and communication) of a
> specific provenpackager?

After sleeping a night over this, I should have put it in different
words:

My questionis are here:
- do we have an issue at all?
- do we have an issue with a single provenpacker
- do we have an issue of attitude or with a group of people?

The consensus of this long thread was: no, the system works mostly ok.
That makes me believe, we don't have a generic issue.

It's not my intention to blame anyone here, I'm still assuming best
intentions.

Nevertheless, since people are different, and not everybody can be
friends with each other, maybe it's a good idea to make communication
mandatory, in cases where proven packagers touch others packages? For
mass changes, there is/should always be an announcement to the
devel mailing list.

Matthias
-- 
Matthias Runge 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


   ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

gdb: No symbol table info available

[Richard Shaw]

I'm working on a segfault in the latest version of hedgewars and I can
reproduce the crash easy enough and I have installed both the debuginfo for
hedgewars and all the packages gdb suggested but the end of the log[1]
still says:

No symbol table info available.

Any ideas?

Thanks
Richard

[1] $ cat test.log

Thread 1 (Thread 0x77fa7300 (LWP 13966)):
#0  __GI__dl_catch_error (objname=0x28d6c30, errstring=0x28d6c38,
mallocedp=0x28d6c28, operate=0x765d4ff0 , args=0x2946aa0)
at dl-error-skeleton.c:187
errcode = 32767
c = {objname = 0x291f050, errstring = 0x291f670, malloced =
0x28d6c28, errcode = 0x7fffd724, env = {{__jmpbuf = {281479271743488,
1,
281479271743489, 65537, 281479271743489, 140733193388033,
281479271743489, 3340499160213259264}, __mask_was_saved = 65537,
  __saved_mask = {__val = {43280784, 0, 140737289327168,
43280792, 45365184, 0, 3340499160213259264, 0, 43280272, 43280272,
  140737289327168, 0, 140737488345416, 140737289324280,
140737323254718, 0}
old = 0x2b437c0
#1  0x765d56a5 in _dlerror_run (operate=operate@entry=0x765d4ff0
, args=0x2946aa0) at dlerror.c:163
result = 0x28d6c20
#2  0x765d501f in __dlclose (handle=) at dlclose.c:46
No locals.
#3  0x74027bee in CleanupVendorNameEntry
(pEntry=pEntry@entry=0x2946790,
unused=0x0) at libglxmapping.c:321
vendor = 0x2946790
#4  0x7402a161 in __glXMappingTeardown (doReset=doReset@entry=0) at
libglxmapping.c:1061
cur__GLXvendorNameHash = 0x2946790
tmp__GLXvendorNameHash = 0x0
pEntry = 
tmp = 
#5  0x74022dd7 in __glXFini () at libglx.c:2099
glas = 
#6  0x77de74b3 in _dl_fini () at dl-fini.c:235
array = 0x742306f0
i = 
l = 0x28d7160
maps = 0x7fffd8a8
i = 
l = 
nmaps = 
nloaded = 
ns = 0
do_audit = 
__PRETTY_FUNCTION__ = "_dl_fini"
#7  0x76239fc8 in __run_exit_handlers (status=0,
listp=0x765ce5b8 <__exit_funcs>, run_list_atexit=run_list_atexit@entry
=true,
run_dtors=run_dtors@entry=true) at exit.c:83
atfct = 
onfct = 
cxafct = 
f = 
#8  0x7623a01a in __GI_exit (status=) at exit.c:105
No locals.
#9  0x7621f891 in __libc_start_main (main=0x0, argc=0, argv=0x0,
init=, fini=, rtld_fini=,
stack_end=0x0) at ../csu/libc-start.c:329
result = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {4309931, 0, 4217114,
140737488346352, 4210861, 140737322809482, 140737322809482,
140737300163376}, mask_was_saved = -8968}}, priv = {pad =
{0x2dd10, 0x404084 , 0x0, 0xb0bfd26695729445}, data = {
  prev = 0x2dd10, cleanup = 0x404084 ,
canceltype = 0}}}
not_first_call = 
#10 0x in ?? ()
No symbol table info available.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Fedora-packaging] Proposed Fedora packaging guideline: Forge-hosted projects packaging automation

[Matthew Miller]

On Sat, Dec 09, 2017 at 09:33:17AM +0100, nicolas.mail...@laposte.net wrote:
> Since I'm a nice person I added GitLab support this morning (both
> gitlab.com and hosted gitlab). Releases are clearly an afterthought
> in GitLab, they depend on free-form tags and can't be used in rpm
> without knowing the corresponding hash (so worst-case, packaging a
> GitLab release requires declaration of version + tag + commit and not
> just version as on other forges).
> 
> As far as I've seen pagure.io does not allow direct download of
> release, tag or commit project archives, so it can not be supported
> right now. RFE: https://pagure.io/pagure/issue/2845

Cool -- thanks for both of these!

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Reminder: upcoming retirement of webkitgtk and webkitgtk3 packages

[Neal Gompa]

On Fri, Dec 8, 2017 at 10:16 PM, Sérgio Basto  wrote:
> On Thu, 2017-12-07 at 23:26 +, Sérgio Basto wrote:
>> On Wed, 2017-12-06 at 16:19 -0800, Adam Williamson wrote:
>> > On Thu, 2017-12-07 at 00:04 +, Sérgio Basto wrote:
>> > >
>> > > hum Markdown plugin is build with GTK3 , the plus of GTK+ is
>> > > confusing
>> > > me
>> >
>> > GTK+ is the correct name of the project and the product. It is not
>> > called GTK. "GTK+ 3" and "GTK 3" refer to the same thing, and "GTK+
>> > 3"
>> > is technically the correct name. (It was called GTK a long, long,
>> > long
>> > time ago and the + was added to indicate an OO rewrite, but that's
>> > ancient history).
>>
>> Thanks, I already can build geany-plugin-markdown with webkitgtk3-
>> devel
>
> It is working with webkitgtk4 :) [1]
>
> [1]
> https://copr.fedorainfracloud.org/coprs/sergiomb/builds_for_Stable_Rele
> ases/build/685925/
>
> Thank you Michael , btw about package naming IMHO webkitgtk4 should be
> called webkit2gtk3 and for gtk4 webkit2gtk4
>

The webkitgtk4-devel package already provides pkgconfig(webkit2gtk-4.0).

The GNOME system for naming pkg-config files is
-, so it's clearer with the pkgconfig name
than the package name.

The naming of the packages was especially dumb in Fedora. It might
make sense to add some Provides that add sensible names, too.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

services which are enabled by default and crash

[Zbigniew Jędrzejewski-Szmek]

I recently installed all rpms that provide a systemd service file in a
container. Quite a few services are enabled by default and crash badly.
I think enabling so many services by default is a bad thing, but if they
at least run OK, that's less problematic. Right now I want to look at
those which crash.

Our policy [1] says
> If a service does not require manual configuration to be functional
> and does not listen on a network socket for connections originating
> on a separate physical or virtual machine, it may be enabled by
> default (but is not required to do so).

In general my plan is to do 'dnf install *' and reboot and have a clean
boot, always.

There's a few simple cases where the service is plain broken:
rootfs-resize: https://bugzilla.redhat.com/show_bug.cgi?id=1524031
gpm:   https://bugzilla.redhat.com/show_bug.cgi?id=1524034
soundmodem:https://bugzilla.redhat.com/show_bug.cgi?id=1094931 
rtkit: https://bugzilla.redhat.com/show_bug.cgi?id=1169449
audit: no bug number, but audit is generally incompatible with 
containers

But there are also services which cannot run in a container when they
are also started on the host (or have some other issues):

● iscsiuio.socket - Open-iSCSI iscsiuio Socket
   Loaded: loaded (/usr/lib/systemd/system/iscsiuio.socket; enabled; vendor 
preset: disabled)
Dec 09 14:51:41 f27c systemd[1]: iscsiuio.socket: Failed to listen on sockets: 
Address already in use

● iscsid.socket - Open-iSCSI iscsid Socket
   Loaded: loaded (/usr/lib/systemd/system/iscsid.socket; enabled; vendor 
preset: disabled)
Dec 09 14:51:41 f27c systemd[1]: iscsid.socket: Failed to listen on sockets: 
Address already in use

● ipmi.service - IPMI Driver
   Loaded: loaded (/usr/lib/systemd/system/ipmi.service; enabled; vendor 
preset: enabled)
Dec 09 14:51:42 f27c systemd[1]: Starting IPMI Driver...
Dec 09 14:51:42 f27c openipmi-helper[232]: Startup failed.
Dec 09 14:51:42 f27c systemd[1]: ipmi.service: Main process exited, 
code=exited, status=1/FAILURE

● ipmievd.service - Ipmievd Daemon
   Loaded: loaded (/usr/lib/systemd/system/ipmievd.service; enabled; vendor 
preset: enabled)
Dec 09 14:51:42 f27c ipmievd[297]: Could not open device at /dev/ipmi0 or 
/dev/ipmi/0 or /dev/ipmidev/0: No such file or dir
Dec 09 14:51:42 f27c systemd[1]: Starting Ipmievd Daemon...
Dec 09 14:51:42 f27c systemd[1]: ipmievd.service: Control process exited, 
code=exited status=1

impi* was enabled in https://bugzilla.redhat.com/show_bug.cgi?id=961878
without much discussion. Those were the early days where the policy wasn't
yet settled. I don't think it's acceptable to have a service which
crashes enabled by default, hence I propose to remove all those
services from default presets. An alternative would be to fix them to
e.g. exit cleanly when running in a container, but since I don't know
anything about iscsi, I have no idea if this is feasible. So unless I
hear some better idea, I plan to file patch against fedora-release to
drop the presets.

[1] https://fedoraproject.org/wiki/Packaging:DefaultServices

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposed Fedora packaging guideline: Forge-hosted projects packaging automation

[nicolas . mailhot]

De: "Zbigniew Jędrzejewski-Szmek" 

> Impressive! I just tested this on some random package using github and
> everything works great.

Thanks for the nice feedback

> Would it be possible to drop the requirement to have "/" at the end
> of a github URL? I think it's natural to paste the URL without the
> trailing slash...

Not having to handle special cases was easier for me, but ok done, the macro is 
now less pedantic.

> Your instructions say "just copy the file into /usr/lib/rpm/macros.d",
> suggesting that the name can by anything, but I think it has to start
> with "macros.".

You're right, it's documented now.

> Wouldn't it be better to recommend %autosetup instead of %setup?
> It's one less thing to change if patches are added.

I don't have a good history with %autosetup :) It tends to hate the patches I 
produce.

OTOH it would be nice if the macro could adjust %setup to mean %setup -n 
%{archivename} when necessary, but I couldn't figure how to do it cleanly.

> add a text like
> "See https://fedoraproject.org/wiki/Packaging:Versioning how to adjust
> Release tag for pre-/post- release commits.". 

Done, thank you for the review.

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1523959] perl-Digest-SHA3-1.02 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1523959



--- Comment #2 from Upstream Release Monitoring 
 ---
hotness's scratch build of perl-Digest-SHA3-1.02-1.el7.src.rpm for rawhide
completed http://koji.fedoraproject.org/koji/taskinfo?taskID=23608422

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1523959] perl-Digest-SHA3-1.02 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1523959



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1365254
  --> https://bugzilla.redhat.com/attachment.cgi?id=1365254=edit
[patch] Update to 1.02 (#1523959)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1523958] New: perl-Digest-SHA-6.00 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1523958

Bug ID: 1523958
   Summary: perl-Digest-SHA-6.00 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Digest-SHA
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: p...@city-fan.org, perl-devel@lists.fedoraproject.org,
ppi...@redhat.com, wjhns...@hardakers.net



Latest upstream release: 6.00
Current version/release in rawhide: 5.98-1.fc28
URL: http://search.cpan.org/dist/Digest-SHA/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

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/2842/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1523959] New: perl-Digest-SHA3-1.02 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1523959

Bug ID: 1523959
   Summary: perl-Digest-SHA3-1.02 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Digest-SHA3
  Keywords: FutureFeature, Triaged
  Assignee: dd...@cpan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: dd...@cpan.org, perl-devel@lists.fedoraproject.org



Latest upstream release: 1.02
Current version/release in rawhide: 1.01-1.fc28
URL: http://search.cpan.org/dist/Digest-SHA3/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

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/11584/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1523884] perl-DBIx-Simple-1.37 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1523884

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-DBIx-Simple-1.36 is|perl-DBIx-Simple-1.37 is
   |available   |available



--- Comment #1 from Upstream Release Monitoring 
 ---
Latest upstream release: 1.37
Current version/release in rawhide: 1.35-19.fc27
URL: http://search.cpan.org/dist/DBIx-Simple/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

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/2815/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1523956] New: perlbrew-0.81 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1523956

Bug ID: 1523956
   Summary: perlbrew-0.81 is available
   Product: Fedora
   Version: rawhide
 Component: perlbrew
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 0.81
Current version/release in rawhide: 0.80-2.fc27
URL: http://search.cpan.org/dist/App-perlbrew/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

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/3552/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Proposed Fedora packaging guideline: Forge-hosted projects packaging automation

[Zbigniew Jędrzejewski-Szmek]

On Fri, Dec 08, 2017 at 07:03:48PM +0100, nicolas.mail...@laposte.net wrote:
> Hi,
> 
> I am proposing for inclusion a macro set aimed at automating the packaging of 
> forge-hosted projects.
> 
> — Packaging draft: 
> https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation
> — FPC ticket: https://pagure.io/packaging-committee/issue/719 (without the 
> “hasdraft” tag because I don't know how to add it in pagure)
> — fedora-rpm-macros RFE with the macro file: 
> https://bugzilla.redhat.com/show_bug.cgi?id=1523779
> 
> What it does: conversion of a forge url, version, tag, commit set to the 
> values expected in rpm specfiles, in optional rpm variables. Computation of 
> the corresponding %{dist}.

Impressive! I just tested this on some random package using github and
everything works great.

Would it be possible to drop the requirement to have "/" at the end
of a github URL? I think it's natural to paste the URL without the
trailing slash...

Your instructions say "just copy the file into /usr/lib/rpm/macros.d",
suggesting that the name can by anything, but I think it has to start
with "macros.". At least "forgeforge.macros" did not work here.

Wouldn't it be better to recommend %autosetup instead of %setup?
It's one less thing to change if patches are added.

In the docs, the instructions under "Packaging a pre-release commit" 
actually apply to post-release commits. Maybe change the title
to "Packaging a pre-release/post-release commit" and add a text like
"See https://fedoraproject.org/wiki/Packaging:Versioning how to adjust
Release tag for pre-/post- release commits.". 

Zbyszek


> 
> Objective: centralize forge structure know-how in a single technical place, 
> deprecate all the complex manual forge URL handling spread over many Fedora 
> spec files, simplify packaging and spend time on more interesting stuff.
> 
> What's currently implemented: definitions for github.com and 
> code.googlesource.com
> (I didn't want to propose stuff I didn't use myself. Adding more definitions 
> is trivial. The macros are in Lua which is change-friendly, no arcane rpm 
> syntax knowledge is needed).
> 
> Please consult packaging draft for full information.
> 
> This is a spin-off of the work I'm currently doing on Go packaging, as Go is 
> heavily forge-oriented. I took the time to extract the generic 
> non-Go-specific forge knowledge in a separate macro file. The macros have 
> been heavily tested on real-life Go projects with quite a lot of variance, on 
> EL7 and rawhide. That's why they come with built-in error handling.
> 
> Regards,
> 
> -- 
> Nicolas Mailhot
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Matthias Runge]

On Fri, Dec 08, 2017 at 08:30:20PM +0100, Matthias Runge wrote:
> Now this has gone back and forth. The system worked more or less ok.
> Maybe it is more about the changes (and communication) of a
> specific provenpackager?

After sleeping a night over this, I should have put it in different
words:

My questionis are here:
- do we have an issue at all?
- do we have an issue with a single provenpacker
- do we have an issue of attitude or with a group of people?

The consensus of this long thread was: no, the system works mostly ok.
That makes me believe, we don't have a generic issue.

It's not my intention to blame anyone here, I'm still assuming best
intentions.

Nevertheless, since people are different, and not everybody can be
friends with each other, maybe it's a good idea to make communication
mandatory, in cases where proven packagers touch others packages? For
mass changes, there is/should always be an announcement to the
devel mailing list.

Matthias
-- 
Matthias Runge 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Fedora-packaging] Re: Proposed Fedora packaging guideline: Forge-hosted projects packaging automation

[Neal Gompa]

On Sat, Dec 9, 2017 at 3:33 AM,   wrote:
>
> Since I'm a nice person I added GitLab support this morning (both gitlab.com 
> and hosted gitlab). Releases are clearly an afterthought in GitLab, they 
> depend on free-form tags and can't be used in rpm without knowing the 
> corresponding hash (so worst-case, packaging a GitLab release requires 
> declaration of version + tag + commit and not just version as on other 
> forges).
>

I made an RFE for this a while back, people can thumbs it up so that
it gets more priority:
https://gitlab.com/gitlab-org/gitlab-ce/issues/38830


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Fedora-packaging] Proposed Fedora packaging guideline: Forge-hosted projects packaging automation

[nicolas . mailhot]

De: "Matthew Miller" 

Hi

> Could open-source solutions pagure.io and gitlab.com be added, please?

Since I'm a nice person I added GitLab support this morning (both gitlab.com 
and hosted gitlab). Releases are clearly an afterthought in GitLab, they depend 
on free-form tags and can't be used in rpm without knowing the corresponding 
hash (so worst-case, packaging a GitLab release requires declaration of version 
+ tag + commit and not just version as on other forges).

As far as I've seen pagure.io does not allow direct download of release, tag or 
commit project archives, so it can not be supported right now.
RFE: https://pagure.io/pagure/issue/2845

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org