I'm about to push jemalloc-4.0.0 for rawhide. Scratch builds for f23 and
f24 are available here:
http://users.linpro.no/ingvar/jemalloc/4.0.0/
There are a few packages that requires jemalloc, and they should be
recompiled and tested against the new package.
$ repoquery --whatrequires jemalloc |\
sed 's,\(.*\)-.*-.*,\1,g;' | sort | uniq
blender
blenderplayer
bro
gridengine
gridengine-execd
gridengine-qmaster
gridengine-qmon
jemalloc-devel
nfs-ganesha
nfs-ganesha-ceph
nfs-ganesha-gluster
nfs-ganesha-proxy
nfs-ganesha-utils
nfs-ganesha-vfs
nfs-ganesha-xfs
redis
varnish
Please report back any problems or comments.
Ingvar
Missing expected images:
Cloud atomic Disk x86_64
Cloud base Disk i386
Images in this compose but not 23 Branched 20150831:
Cloud base Vagrant x86_64
Docker Filesystem x86_64
Cinnamon Live i386
Cinnamon Live x86_64
Cloud base Disk x86_64
No images in 23 Branched 20150831 but not this.
Failed openQA tests: 2 of 20
ID: 1092 Test: x86_64 universal server_no_swap
ID: 1085 Test: x86_64 universal server_simple_free_space
--
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
Missing expected images:
Kde Live i386
Kde Live x86_64
Cloud base Disk i386
Kde Disk armhfp
Images in this compose but not Rawhide 20150831:
Cloud base Vagrant x86_64
Docker Filesystem x86_64
Cloud atomic Disk x86_64
Cloud atomic Vagrant x86_64
Cloud base Disk x86_64
Images in Rawhide 20150831 but not this:
Lxde Live i386
Security Live x86_64
All 20 openQA tests passed.
--
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
= Proposed System Wide Change: TeXLive 2015 =
https://fedoraproject.org/wiki/Changes/TeXLive2015
Change owner(s): Tom Callaway <spot(a)fedoraproject.org>
Update Fedora TeXLive packaging to 2015.
== Detailed Description ==
Fedora's core latex support comes from TeXLive. We've been on 2014 for a while now, and 2015 is out. Time to upgrade! Since lots of things use latex to generate documentation, the scope of this update is wide.
== Scope ==
* Proposal owners: Actually update texlive package to 2015 sources. Ideally, have a mass rebuild in the 24 release cycle to catch any odd breakage cases, if no mass rebuild, identify packages with BR on texlive* and manually rebuild.
* Other developers: If your package depends on latex/TeXLive, rebuild to make sure that everything works properly and renders correctly.
* Release engineering: Mass rebuild would be ideal, however, if this is the only thing that needs it, we can do a targeted rebuild of packages that BR: texlive*
* Policies and guidelines: No new policy/guideline changes required.
* Trademark approval: N/A (not needed for this Change)
--
Jan Kuřík
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
Hello,
a major update to NetworkManager, a service that manages our network
connectivity is planned to be released later this year.
======================================================================
TLDR: If you're a maintainer of a VPN plugin, we'll reach out to you
with the port to new API soon. If you use libnm-glib your application
won't break, but libnm is better.
======================================================================
We plan to import a snapshot of the pre-release code very early
(probably in one week's time). We believe the code base is in a very
solid state and this will make it possible to start ironing out the
remaining wrinkles early and make use of the new features.
Among usual pile of fixes this release will bring new client libraries
(libnm and libnma) that essentially modernized and streamlined versions
of existing libraries (libnm-glib, libnm-vpn, libnm-util and libnm
-gtk).
We're keeping the old libraries so libnm-glib users will be unaffected
with one exception: due to glib type system restrictions libnm-glib and
libnm can't be loaded at the same time. Therefore libnm-based VPN
preferences plugins can't be mixed with libnm-glib based applications
and vice versa. To fix this situations the VPN plugins will provide
both libnm-glib and libnm based versions of the preferences plugins.
NetworkManager 1.2 provides a compatibility shim to make the porting
easier. We'll do the porting and submit changes to the upstreams and
the package maintainers.
A repository with new versions of the daemon, connection editor and VPN
plugins is available here:
https://copr.fedoraproject.org/coprs/lkundrak/NetworkManager/
♥,
Lubo
Hi everyone,
I would like to introduce go-compilers packages.
Intro:
- golang language is supported on primary and secondary architectures
- at the moment we have two compilers: golang and gcc-go
- on Fedora we have a partial support for debugging
- go-srpm-macros packages provides basic macros (go_arches,
golang_arches, gcc_go_arches, ...)
- f21, f22, f23, rawhide, el6 are supported. Fedora is primary, el6 is
almost 1:1 with fedora branches (e.g. etcd is not build in el6 yet)
Current state:
At the moment if a user wants to package a golang projects he follows
golang packaging guidelines draft [1]. Among other things, there is a
recommended form of the spec file. In a "Packaging library" example
there is a build section which shows how to create symlink and build
package via 'go build' command. In a "Build ID" and "Debuginfo"
information how to hack build to be able to extract debug info is described.
[1] https://fedoraproject.org/wiki/PackagingDrafts/Go
Problems:
1) for given architecture correct compiler has to be chosen (go_arches,
golang_arches, gcc_go_arches macros)
2) if debug info is provided, building has to be hacked (generate Build
ID for golang compiler)
3) go-srpm-macros is in minimal buildroot
To solve 1), the following is used at the moment:
# If go_arches not defined fall through to implicit golang archs
%if 0%{?go_arches:1}
ExclusiveArch: %{go_arches}
%else
ExclusiveArch: %{ix86} x86_64 %{arm}
%endif
# If gccgo_arches does not fit or is not defined fall through to golang
%if %{isgccgoarch}
BuildRequires: gcc-go >= %{gccgo_min_vers}
%else
BuildRequires: golang
%endif
To solve 2), the following is used at the moment:
# If gccgo_arches does not fit or is not defined fall through to golang
# gccco arches
%if %{isgccgoarch}
%if 0%{?gcc_go_build:1}
export GOCOMPILER='%{gcc_go_build}'
%else
echo "No compiler for SA"
exit 1
%endif
# golang arches (due to ExclusiveArch)
%else
%if 0%{?golang_build:1}
export GOCOMPILER='%{golang_build}'
%else
export GOCOMPILER='go build'
%endif
%endif
%if 0%{?with_debug} && !%{isgccgoarch}
function gobuild {
local LDFLAGS="-B 0x$(head -c20 /dev/urandom|od -An -tx1|tr -d ' \n')"
eval ${GOCOMPILER} -a -v -x "$@";
}
%else
function gobuild { eval ${GOCOMPILER} -a -v -x "$@"; }
%endif
Why so long? Intention was to cover situations where there is no
go-srpm-macros package (rhel, possibly f21) in a minimal buildroot.
- the first block sets GOCOMPILER env and choose the correct compiler.
- the second block defines gobuild function which for a case of golang
compiler generates Build ID for resulting binary.
What is go-compilers package?
- review request: https://bugzilla.redhat.com/show_bug.cgi?id=1258182
- it consists of two packages (one that requires golang compiler, one
that requires gcc-go compiler)
- based on an architecture it provides three virtual provides:
compiler(go-compiler), compiler(golang), compiler (gcc-go)
- based on an architecture it defines gobuild and gotest macros which
hide hack for Build ID for golang compiler (transparent to user) and
hides golang/gcc-go compiler command (thus making one command for all
compilers the same)
How go-compilers solves problems 1-3)
- Make 1) shorter. With go-compilers it is possible to just use
ExclusiveArch: %{go_arches}
BuildRequires: compiler(go-compiler)
- Make 2) shorter. go-compilers ships macros.go-compilers which defines
%{gobuild} and %{gotest} macros for golang or gcc-go based on
architectures. Both blocks can be removed. How is gobuild defined?
%gobuild() \
function gobuild { \
local LDFLAGS="${LDFLAGS:-} -B 0x$(head -c20 /dev/urandom|od -An -tx1|tr
-d ' \\n')" \
go build -compiler gc -ldflags "${LDFLAGS:-}" -a -v -x "$@"; \
} \
gobuild %{?*}
- For 3) go-srpm-macros will be provided by go-compilers subpackages.
Besides, go-srpm-macros in not in epel6 at the moment. This way, it will
be there.
Why it could be improved?
a) Make choose of compiler transparent for user. And change the compiler
for all packages at once.
b) Make Build ID hack transparent for user. Move it to one place so it
can be updated in one place only if needed.
c) Make the spec file as short as possible. User can always decide if he
uses %{gobuild} macro or not.
What do you think? Is it worth creating the package? Will it simplify
packaging or not? My aim is to hide all compiler specific features and
provide abstract functions as a black box. Those functions can be then
changed independent of user's spec file. For example, when golang
compiler starts to generate build id's, the generator can be removed
without changing user's spec file.
Any suggestions or feedback is appreciated and welcome.
Regards
Jan
Hi!
This is a reminder, that Fedora 23 "Change Checkpoint: 100% Code
Complete Deadline" is coming in a week. It's important milestone as
contingency plan may be put into effect for Changes that miss this
deadline. As always, the list will be shared with FESCo.
2015-Sep-08 Change Checkpoint: 100% Code Complete Deadline
2015-Sep-08 Fedora 23 Beta Freeze
Expected bug state is ON_QA - Change has to be code complete and can
be tested in the Beta release (optionally by Fedora QA).
Please make sure to update state of yours Change(s) bug(s) on time. In
case of any problems, let me know, we will try to find working
solution.
Schedule: http://fedoraproject.org/wiki/Releases/23/Schedule
F23 ChangeSet: https://fedoraproject.org/wiki/Releases/23/ChangeSet
Thanks,
Jan
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
I'm sorry but I'm not able to organize the WG meeting this week. If
somebody else is volunteering to organize the meeting (which should be
at 5pm UTC this week), feel free to do so.
Honza