Re: updating ffmpeg to 3.1.x in rawhide
by Sérgio Basto
On Dom, 2016-07-31 at 18:29 +0100, Jonathan Underwood wrote:
> On 31 July 2016 at 18:27, Sérgio Basto <sergio(a)serjux.com> wrote:
> >
> > On Dom, 2016-07-31 at 18:08 +0100, Jonathan Underwood wrote:
> > >
> > > It looks like there's no need to manually push packages to
> > > updates-testing, and that it happens automatically - is that
> > > correct?
> > yes, kwizart do the pushes manually like old times, i.e. first push
> > to
> > updates-testing and after some days push it to updates (stable),
> > until
> > we have one bodhi system (like is planned).
> So, is it still necessary to request a push in a bugzilla ticket?
no kwizart push all packages without ticket :)
--
Sérgio M. B.
8 years, 4 months
Re: updating ffmpeg to 3.1.x in rawhide
by Julian Sikorski
W dniu 31.07.2016 o 19:19, Jonathan Underwood pisze:
> Oh dear, seems 0.17.4 fails to build on the devel branch with the new
> ffmpeg. Looking into it.
>
https://xpra.org/trac/changeset/12943/xpra
> xpra/codecs/dec_avcodec2/decoder.c: In function
> '__pyx_pf_4xpra_6codecs_12dec_avcodec2_7decoder_7Decoder_22decompress_image':
> xpra/codecs/dec_avcodec2/decoder.c:7504:9: error:
> 'avcodec_decode_video2' is deprecated
> [-Werror=deprecated-declarations]
> __pyx_v_len = avcodec_decode_video2(__pyx_v_self->codec_ctx,
> __pyx_v_self->av_frame, (&__pyx_v_got_picture), (&__pyx_v_avpkt));
> ^~~~~~~~~~~
> In file included from xpra/codecs/dec_avcodec2/decoder.c:279:0:
> /usr/include/ffmpeg/libavcodec/avcodec.h:4753:5: note: declared here
> int avcodec_decode_video2(AVCodecContext *avctx, AVFrame *picture,
> ^~~~~~~~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors
> error: command 'gcc' failed with exit status 1
>
>
> On 31 July 2016 at 18:08, Jonathan Underwood
> <jonathan.underwood(a)gmail.com> wrote:
>> xpra-codecs-rfeeworld is now updated to 0.17.4 on F23, F24 and devel
>> branches. Builds have been pushed.
>>
>> It looks like there's no need to manually push packages to
>> updates-testing, and that it happens automatically - is that correct?
>>
>> Cheers,
>> Jonathan
>>
>> On 31 July 2016 at 11:09, Jonathan Underwood
>> <jonathan.underwood(a)gmail.com> wrote:
>>> I'll work on moving to xpra 0.17.4 in fedora this evening, and will do
>>> similarly for the rpm fusion package.
>>>
>>>
>>> On 31 Jul 2016 08:41, "Julian Sikorski" <belegdol(a)gmail.com> wrote:
>>>>
>>>> W dniu 31.07.2016 o 07:29, Julian Sikorski pisze:
>>>>> W dniu 28.07.2016 o 07:41, Julian Sikorski pisze:
>>>>>> W dniu 28.07.2016 o 04:48, Sérgio Basto pisze:
>>>>>>> On Qua, 2016-07-27 at 20:18 +0200, Julian Sikorski wrote:
>>>>>>>> I have done a test rebuild and found the following:
>>>>>>>> - there are currently 40 packages dependent on ffmpeg
>>>>>>>> - out of those, 37 rebuilt correctly
>>>>>>>> - 3 have failed:
>>>>>>>> - kodi: failure looks related to curl, not to ffmpeg
>>>>>>>> - mlt: strange error, something about zval. build.log crashes gedit
>>>>>>>> - xpra-codecs-freeworld: avcodec_decode_video2 is deprecated
>>>>>>>>
>>>>>>>> Given the small number of failures, I would be aiming to push the new
>>>>>>>> ffmpeg to rawhide and rebuild dependent packages on Saturday. Please
>>>>>>>> speak up if you don't agree.
>>>>>>>
>>>>>>> Julian, I agree , "and rebuild dependent packages on Saturday" do you
>>>>>>> do the mass rebuild ? or need help ?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>> I can do the mass rebuild, I have the privileges now.
>>>>>>
>>>>>> Best regards,
>>>>>> Julian
>>>>>>
>>>>> The mass rebuild has now been completed.
>>>>>
>>>>> Best regards,
>>>>> Julian
>>>>>
>>>> I have now rebuilt kodi as well as the maintainer has fixed the curl
>>>> issue.
>>>> For xpra, there is a patch in upstream svn (revision 12943), but it does
>>>> not apply cleanly to 0.16.x branch. I'll leave it up to the maintainer
>>>> whether backporting is worth the effort, or will it just be easier to
>>>> rebase to 0.17.x
>>>> The mlt failure is due to php-7.0:
>>>> http://koji.rpmfusion.org/koji/taskinfo?taskID=15442
>>>>
>>>> Best regards,
>>>> Julian
8 years, 4 months
Re: updating ffmpeg to 3.1.x in rawhide
by Sérgio Basto
On Dom, 2016-07-31 at 18:08 +0100, Jonathan Underwood wrote:
> It looks like there's no need to manually push packages to
> updates-testing, and that it happens automatically - is that correct?
yes, kwizart do the pushes manually like old times, i.e. first push to
updates-testing and after some days push it to updates (stable), until
we have one bodhi system (like is planned).
Thanks,
--
Sérgio M. B.
8 years, 4 months
[Fwd: [Bug 1344830] glibc: Revert sendmsg/recvmsg ABI changes]
by Sérgio Basto
:P)
-------- Forwarded Message --------
From: bugzilla(a)redhat.com
To: sergio(a)serjux.com
Subject: [Bug 1344830] glibc: Revert sendmsg/recvmsg ABI changes
Date: Thu, 28 Jul 2016 14:44:26 +0000
https://bugzilla.redhat.com/show_bug.cgi?id=1344830
--- Comment #4 from Florian Weimer <fweimer(a)redhat.com> ---
(In reply to Sergio Monteiro Basto from comment #3)
>
> "All affected rawhide packages have been rebuilt."
>
> How do we know what are the affected packages ?
I used this query against symboldb:
SELECT source, MAX(build_time)::date build_time,
json_agg (DISTINCT arch ORDER BY arch) AS architectures
FROM (SELECT SUBSTRING (p.source FROM '(.*)\.src\.rpm$') AS source,
build_time, p.arch
FROM symboldb.package p
JOIN symboldb.file USING (package_id)
JOIN symboldb.elf_reference er USING (contents_id)
JOIN symboldb.package_set_member USING (package_id)
WHERE er.name IN ('recvmsg', 'recvmmsg', 'sendmsg',
'sendmmsg')
AND er.version = 'GLIBC_2.24') x
GROUP BY source ORDER BY 1;
I applied this against the Koji build roots for i386, x86_64, armhfp,
ppc64,
ppc64le, s390x, aarch64.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=Au17y
ZGSPq&a=cc_unsubscribe
--
Sérgio M. B.
8 years, 4 months
SIMD vs no SIMD on i686 (was: [Bug 3975] executable stack flag prevents use of libx264.so.148 with selinux in enforcing mode)
by Dominik 'Rathann' Mierzejewski
Hello, Sérgio.
On Tuesday, 19 July 2016 at 02:35, RPM Fusion Bugzilla wrote:
> https://bugzilla.rpmfusion.org/show_bug.cgi?id=3975
>
> --- Comment #4 from Sérgio Basto <sergio(a)serjux.com> 2016-07-19 02:35:19 CEST ---
> (In reply to comment #3)
> > I'll take a look at this. Could you try running execstack -c on the installed
> > library in the meantime?
>
> Be my guest , in meantime I read your thread on packaging Mailing list about
> sse3 , I'd like understand if we need 2 builds for i686 ... one with sse2 other
> without it, can you give us your opinion ?
The only real concern here are applications linked against libx264,
which someone might want to run on low-end hardware, because I don't
think anyone would want to encode anything to H.264 on non-SSE2 capable
CPU (i.e. Pentium 3 or Athlon XP and older). Considering last non-SSE2
CPUs went out of production about 8 years ago, I think it's fairly safe
to assume that the impact of doing SSE2-only builds would be negligible,
if any.
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
8 years, 4 months
[Bug 3985] New: Review request: kisslicer - Keep It Simple Slicer
by RPM Fusion Bugzilla
https://bugzilla.rpmfusion.org/show_bug.cgi?id=3985
Bug #: 3985
Summary: Review request: kisslicer - Keep It Simple Slicer
Classification: Unclassified
Product: Package Reviews
Version: Current
Platform: All
OS/Version: GNU/Linux
Status: NEW
Severity: normal
Priority: P5
Component: Review Request
AssignedTo: rpmfusion-package-review(a)rpmfusion.org
ReportedBy: mhroncok(a)redhat.com
CC: rpmfusion-package-review(a)rpmfusion.org
SPEC: https://churchyard.fedorapeople.org/SRPMS/kisslicer.spec
SRPM: https://churchyard.fedorapeople.org/SRPMS/kisslicer-1.1.0-1.fc23.src.rpm
%description
KISSlicer is a fast, easy-to-use, cross-platform program that takes 3D files
(STL) and generates path information (G-code) for a 3D Printer. This FREE
version has all the features needed for the hobbyist who uses a single-head
machine.
Why this package is not eligible to be included in Fedora: nonfree
The output rpmlint gives on both the source and binary packages. Explain for
each message why you've chosen to ignore it:
> kisslicer.x86_64: W: invalid-license Redistributable
valid in nonfree
> kisslicer.x86_64: W: no-documentation
upstream provides none
> kisslicer.x86_64: W: no-manual-page-for-binary KISSlicer
> kisslicer.x86_64: W: no-manual-page-for-binary kisslicer
upstream provides none, also a GUI so not really needed
> kisslicer.src: W: invalid-license Redistributable
valid in nonfree
2 packages and 0 specfiles checked; 0 errors, 5 warnings.
--
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
8 years, 4 months
