Retire mingw-openjpeg (and native openjpeg status)
by Sandro Mani
Hi
I'm planing to retire mingw-openjpeg next week unless there are
objections. It is superseeded by mingw-openjpeg2 and no package depends
on it anymore. The openjpeg-1.x series is obsolete and has multiple
unfixed security issues.
Though not its maintainer, as a curiosity I've had a look at what still
needs native openjpeg in Fedora:
blender -> Patch from debian
https://anonscm.debian.org/cgit/pkg-multimedia/blender.git/tree/debian/pa...
calligra -> No upstream support
efl -> Upstream support
gdcm -> Upstream support
gpac -> No upstream support
gstreamer1-plugins-bad-free -> Upstream support
mtpaint -> Upstream support
vfrnav -> No upstream support
I think it would be a good idea for the respective maintainer to switch
to openjpeg2 where possible.
Thanks
Sandro
7 years, 3 months
policykit for ejabberd
by Randy Barlow
Hello!
I maintain ejabberd and I've got an issue filed about ejabberd's
policykit policy being desktop-centric[0]. I've done some reading about
how I could alter the policy to make it so that it doesn't expect the
user to be at a seat, but I can't help but think that sudo is a great
way to handle this problem and probably is what a server admin would
expect to use to control access to ejabberdctl.
I'm leaning towards removing the policykit integration from ejabberd,
but I wanted to ask on this list if there's a reason I should keep and
maintain it. I honestly don't know much about it, so if there's a value
in it that I'm not seeing I'd love to be educated.
[0] https://bugzilla.redhat.com/show_bug.cgi?id=1094143
7 years, 3 months
ppc64le: error: declaration does not declare anything
by Sandro Mani
Hi
I'm having some difficulties understanding the following error on
ppc64le (scratch build [1], build log [2]):
PackMath.h:
191 template<> inline v4f ei_pset1(const float& from)
192 {
193 // Taken from
http://developer.apple.com/hardwaredrivers/ve/alignment.html
194 float __attribute__(aligned(16)) af[4];
195 af[0] = from;
196 v4f vc = vec_ld(0, af);
197 vc = vec_splat(vc, 0);
198 return vc;
199 }
/builddir/build/BUILD/eigen-eigen-b23437e61a07/Eigen/src/Core/arch/AltiVec/PacketMath.h: In function 'typename Eigen::ei_packet_traits<T>::type Eigen::ei_pset1(const Scalar&) [with Scalar = float; typename Eigen::ei_packet_traits<T>::type = __vector(4) float]':
/builddir/build/BUILD/eigen-eigen-b23437e61a07/Eigen/src/Core/arch/AltiVec/PacketMath.h:194:40: error: declaration does not declare anything [-fpermissive]
float __attribute__(aligned(16)) af[4];
^
/builddir/build/BUILD/eigen-eigen-b23437e61a07/Eigen/src/Core/arch/AltiVec/PacketMath.h:194:3: error: expected primary-expression before 'float'
float __attribute__(aligned(16)) af[4];
^~~~~
/builddir/build/BUILD/eigen-eigen-b23437e61a07/Eigen/src/Core/arch/AltiVec/PacketMath.h:195:3: error: 'af' was not declared in this scope
af[0] = from;
The build completes on x86_64 and i686 and possibly others. Any ideas?
Thanks
Sandro
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=16927043
[2] https://koji.fedoraproject.org/koji/getfile?taskID=16927051&name=build.log
7 years, 3 months
Start packaging/maintaining in Fedora
by Lailah
Hello everyone!
I want to start packaging and maintaining packages in Fedora, but I'm a
bit lost. What should I do first? How can I start maintaining a
package? Is there anyone who can guide me a bit, please?
I know Python and C languages.
Thanks in advance! Sylvia
7 years, 3 months
Re: future of official optical media support in Fedora
by Keith Keith
On Thu, Dec 15, 2016 at 6:08 AM, Kamil Paral <kparal(a)redhat.com> wrote:
> > Now that Fedora 25 is out of the door, I'd like to start a discussion
> about
> > the future of officially-supported (meaning rigorously tested) optical
> media
> > for future Fedora releases.
>
> The discussion died off, so let me summarize and propose a plan.
>
> We haven't received as much feedback as I hoped for. Maybe people don't
> care enough about optical disks to even respond, or it might be a different
> reason. But we also didn't receive as much negative feedback as I feared.
> So hopefully this does not negatively impact too many people. The comments
> under the Phoronix article [1] weren't too helpful either, a few rants but
> no-one cared to follow up with some explanation or system specification
> which would be negatively affected for his/her use case. Some of them, I
> believe, just read the article title without realizing this only affects
> Alpha/Beta media or certain flavors of Final media.
>
> [1] http://phoronix.com/scan.php?page=news_item&px=Fedora-Post-
> 25-Optical-Future
>
>
> > Idea #1: Do not block on optical media issues for Alpha and Beta releases
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~~~~~~~~~~~~~
>
> This is the less controversial idea, I believe. We received a concern from
> Matthew, who was worried that we might find out too late if we don't check
> it for Alpha/Beta. I partly agree, but believe we should solve it with an
> improved QA processes, instead of bumping the release criteria to apply
> earlier. He did not object to this, and nobody else did, so I assume
> everyone agrees :-) If there are no further concerns, I'll prepare a
> criterion adjustment proposal for this.
>
> >
> > Idea #2: Do not block on optical media issues for Final release for
> certain
> > flavors/image types (Server, netinst)
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > This is a bolder variant of the previous idea and can be done separately
> or
> > combined with it. It makes optical media functionality not guaranteed
> even
> > for Final release, but just for certain Fedora flavors or image types for
> > which it makes sense (not all of them). Which images to cover, that's the
> > heart of the discussion. If you look into our test matrix again, we
> > currently block on 6 of them:
> > * Workstation Live + netinst
> > * KDE Live
> > * Server DVD + netinst
> > * Everything netinst
>
> This was received with reasonably positive reception as well. But it's
> harder to compile a list which images should be covered by criteria and
> which not.
> - Workstation Live will be covered, that's clear - we give out these DVDs
> at events, it's sent out to the developing world
> - Everything netinst is the most universal and generic netinst, so
> covering that one means we don't need to cover Workstation netinst and
> Server netinst. People seem to agree to this.
> - Nobody argued for KDE Live. We probably don't bulk press KDE Live DVDs.
> If we cover Workstation Live, it's improbable that only KDE Live would
> break, but not impossible. If such thing happens, are people OK with
> releasing Fedora XX KDE Live only bootable over USB?
> - Server DVD is a mixed bag. Matthew didn't include it in his block-list,
> Adam did. Neal uses it over IMPI (but netinst would be good enough for him
> IIUIC, sans some package deps issue which can be solved using a kickstart).
> I would appreciate more feedback from Server folks. Again, we'll cover
> netinst so it's improbable DVD would break, but not impossible. Are people
> OK releasing it only bootable over USB (and PXE)?
>
> Thanks.
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>
>We haven't received as much feedback as I hoped for. Maybe people don't
care enough about optical disks to even respond, or it might be a different
reason.
I must have missed this and deleted it by mistake.
I had something weird happen when F23 was the latest release. Somehow,
probably through user error, I deleted my partition table and bricked my
only USB stick. I think I corrupted the USB stick firmware somehow. I
have only one computer so using another to get another copy wasn't an
option. I did have a back up Fedora DVD because an earlier experience in
life when I found myself without an OS and a broken installation.
I think that having a read only media option with physical damage as the
only failure mode is valuable. I continue to keep a Fedora DVD even though
I prefer installing through USB.
7 years, 3 months
F26 Self Contained Change: Golang buildmode PIE
by Jan Kurik
= Proposed Self Contained Change: Golang buildmode PIE =
https://fedoraproject.org/wiki/Changes/golang-buildmode-pie
Change owner(s):
* Jakub Čajka <jcajka AT fedoraproject DOT org>
Change default build mode of golang in Fedora packaging macros to
buildmode=pie, which results in packages using them to produce
Position Independent Executables. Another part of the change is to
pass the Fedora hardened linker flags to the external linker(regular
system linker). In result reducing exploit-ability of binaries.
== Detailed Description ==
Change default build mode of golang in Fedora packaging macros to
buildmode=pie, which results in packages using them to produce
Position Independent Executables. Another part of the change is to
pass the Fedora hardened linker flags to the external linker(regular
system linker). This will only affect packages that depend on golang
packaging macros for their build. This should be first step towards
mandating this on all packages that provide binaries based on golang
in whole distribution via Go packaging guidelines(which is out of
scope for this change proposal).
== Scope ==
* Proposal owners:
change the Go packaging macros, resolve possible issue encountered
* Other developers:
help with resolving any issues encountered
* Release engineering:
none as mass-rebuild is scheduled
* List of deliverables:
N/A (not a System Wide Change)
* Policies and guidelines:
none
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
7 years, 3 months
GSequencer upstream wants to package for fedora
by Joël Krähemann
Hi all
My name is Joël Krähemann. I maintain Advanced Gtk+ Sequencer and I'd
like to provide it in fedora. Linux is my OS of choice since 2001.
Along the time I have used many distributions like debian, linux from
scratch, SUSE, fedora and a few others.
Prior I did an RPM spec provided on:
https://sourceforge.net/projects/ags/files/fedora/
Note the project is mainly hosted by GNU Savannah.
http://nongnu.org/gsequencer
The domain http://gsequencer.org is forwarded to it. Current stable
version of GSequencer is 0.7.113 and I'm working on version 1.0. The
branch 0.7.x only gets bug-fixes or features back-ported I'd really
like to see there.
Next goals are doing remote bindings and lv2 UI support as well
extending MIDI support. Further I'd like to accelerate loading Lv2
plugins the current code doing XPath lookup with RDF turtle converted
XML is slow for certain plugins. But you are able to blacklist if you
wish.
Bests,
Joël
7 years, 3 months
CVE-2016-8655, systemd, and Fedora
by Matthew Miller
In case you haven't seen: there was a recent kernel vulnerability in a
feature called "AF_PACKET". Most services don't need to use the raw
sockets this makes available, and on his blog*, Lennart Poettering notes
that systemd actually has a feature where services can whitelist or
blacklist address families, protecting them from not just this exploit
but similar classes.
The upcoming systemd v232 will include this by default for systemd's
own unit files. But, of course, that's a tiny subset of services in
Fedora. So....
Question 1: How can we take advantage of this feature in specific? We
could bulk file a bunch of bugs. Or, what about turning on some more
restrictive defaults (AF_INET AF_INET6 AF_UNIX) on some flag day in
Rawhide, and having services which have different needs add exceptions
to their own unit files (either more or less restrictive).
Question 2: What about *other* systemd security features? The blog post
mentions restricting namespaces as an upcoming feature, and there are
other existing ones which we are not using systemically — like
PrivateTmp, ProtectSystem, etc. How can we take better advantage of
these?
* http://0pointer.net/blog/avoiding-cve-2016-8655-with-systemd.html
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
7 years, 3 months