apitrace, bundled libbacktrace
by Sandro Mani
Hi,
apitrace 5.0 bundles libbacktrace, which looks like is living within the
gcc sources. libbacktrace is not build as a shared library from the gcc
sources, and not packaged.
Is it feasible to build libbacktrace as a shared library and ship it in
a corresponding package? Or should I rather go for a bundling exception
request?
Thanks,
Sandro
1 year, 6 months
whatever happened to yum + btrfs snapshotting?
by Neal Becker
Some time back there was discussion of being able to rollback yum updates via
btrfs snapshotting. As I recall, it turned out that the default btrfs install
was not setup correctly to make this feasible (I had briefly tested it on my
machine). I haven't heard anything since - this seems like a great idea.
--
-- Those who don't understand recursion are doomed to repeat it
2 years, 3 months
Bad default error policy causes printing issues and BIG usability issues
by Valent Turkovic
Hi,
currently default error policy for printers in Fedora is "Stop printer" on
any error which is a really bad default. I have run across this issue LOTS
of times with regular Fedora desktop users who don't get why has their
printer stopped working, there is no UI queue to warn users, there is no
easy way to "Start printer" with one click after it has been stopped. It is
just a big mess.
Even worse, previous versions of Gnome control panel (if I remember
correctly) had option to change default error policy, now that option is
removed and you can get to it only by installing system-config-printers
tool, something regular users have no idea about even exists, and it is not
installed by default.
There are too many examples which are simple user errors but result in
priner going offline (stopped) and this is really bad, because after any
small error users can't print any more.
For example: user trying to print while he/she is not at home so his/hers
printer is not available, user trying to print but has forgot to connect
usb priner cable, user trying to print but haven't turned it on, user
printing to wifi printer but while connected to different wifi network...
Any of these actions is simple uses error but results in permanently
disabling of priner (Stops printer) and users can't print even when they
resolve issue that was stopping them from accessing the printer.
Now Fedora is what is stopping them from printing.
Who is responsible for user experience of Fedora desktop? To whom should I
point this issue to?
3 years, 9 months
Firefox addon signing
by Michael Cronenworth
I'm sure those that need to know, know, but for those that haven't heard[1]
Mozilla's official Firefox build will enforce addons to contain a Mozilla signature
without any runtime option to disable the check.
Initially this prevents Fedora packaged addons since they are unsigned. The Mozilla
signing process takes time and can't be part of a package building process.
Is Fedora going to get authorization to build Firefox with a runtime disable option?
[1] https://blog.mozilla.org/addons/2015/02/10/extension-signing-safer-experi...
3 years, 9 months
Unretiring cx18-firmware, if anyone else still wants it in the distro
by Simon Farnsworth
Hello all,
I've got the misfortune of maintaining a small number of systems that use
the cx18 driver for their HVR-1600 cards; I'm just in the process of
bringing these systems up to Fedora 21, and have discovered that
cx18-firmware was retired.
As I'm going to have to maintain the package for work purposes, I'm
volunteering to maintain it in Fedora for F21 and later. If anyone's
interested in having it available in Fedora, the review request is at:
https://bugzilla.redhat.com/show_bug.cgi?id=1203379
--
Simon Farnsworth
4 years
SIMVoleon, SoQt rebuilt against Coin3 on f22 and rawhide
by Ralf Corsepius
Hi,
as some already might have noticed, Coin3 is about to land in Fedora.
Therefore, I rebuilt SIMVoleon and SoQt (two addon-packages to Coin),
against Coin3 on rawhide and f22. I do not expect this to impose
problems to Fedora, because I can't spot any packages depending on these
in Fedora.
On Fedora <= 21 these packages will have to stay with Coin2 to avoid
breaking backward-compatibility.
Though it's thinkable to do so, I do not plan to provide Coin3-compiled
versions of these packages for fc20, f21 and Coin2-compiled versions for
fc22, f23, at the moment. Please speak up now, should you have such a
demand.
Ralf
4 years, 1 month
A proposal for Fedora updates
by Bojan Smojver
Hi there,
I've been a bit perplexed by the Fedora updates recently (talking about
F-21 specifically). Many of them appear to be obsolete the moment they
hit stable, sometimes even testing.
Take the kernel, for instance. 3.19.2-201.fc21 replaced the previous
build in bodhi on the 24th. It is still not in testing as I'm writing
this (although the updates system says it is). Take Firefox. Submitted
on 23rd, took 3 days to appear anywhere where "regular" folks can test
it (which is actually stable). Then there are updates (e.g. dovecot)
that have been built in koji, but appear nowhere, probably because
person that built it forgot to submit it.
Can we create a fedora-updates-newbuild repo or something, which would
have a different key used for signing (i.e. not the one where a human
does the signing) and could be accessed using yum pretty much
immediately after the build has been created and flagged to go into this
repo if it succeeds?
So, something like:
fedpkg build --push-to-newbuild
Stoopid? Irrelevant? Exists but I'm not aware of it?
--
Bojan
4 years, 1 month
hardening breaks X.org
by David Airlie
So the rebuild to use hardened builds by default in rawhide, broke X.org.
Thanks guys, my system is more secure, but I can't run any apps.
Anyways enough snark from me, the problem seems to be that hardening
makes bind now override RTLD_LAZY options, and the X server relies
on the RTLD_LAZY on its drivers being lazy.
So should I
a) turn off hardened builds for all Xorg server/driver packages?
b) or is there a way to get partial relro back?
Dave.
4 years, 2 months
Texlive packaging (Was: A proposal for Fedora updates)
by Jindrich Novy
> On 03/27/2015 05:22 PM, Kevin Fenzi wrote:
> >* However, I'll note that the recent texlive updates were security as
*> >* well. ;)
*>
> If texlive packaging is causing issues with update pushes, could maybe
> ask the texlive maintainers to rework the packaging?
TeXLive packager says: No, sorry.
Kevin states that sigul lockups while running in batch mode so manual
action is needed for builds with many subpackages. This is the root cause.
Fixing sigul and releng tools sounds like much better way of dealing
with such issue than "Our broken tools don't scale so let's
repackage every bigger package to workaround it."
>
> Right now texlive has a 16 MB (!) spec file, producing a total of 5160
> binary rpms each build.
What's wrong with it? It is autogenerated, you are not supposed to touch
the spec file directly but edit texlive.spec.template and regenerate the
spec file by tl2rpm. All subpackages are generated with correct dependencies
(at least according to upstream metadata) and packages with wrong non-free
licences are excluded from build automatically.
Yes, all this is done automatically. Good luck doing that by hand for 5160
CTAN packages with every update from CTAN.
If YUM metadata size is in question then it might make sense to have a mechanism
of non-monolythic metadata in place, i.e. transactions not requiring TeX Live
shouldn't download TeX Live's metadata. I'm sorry, I'm not a releng person.
TeXLive itself has not been updated for quite long time because of compilation
error:
gcc -DHAVE_CONFIG_H -I. -I../../../texk/web2c -I./w2c
-I/home/jnovy/rpm/BUILD/texlive-2014/source/work/texk
-I/home/jnovy/rpm/BUILD/texlive-2014/sourc
../../../texk/web2c/luatexdir/lua/lepdflib.cc: In function 'int
l_new_Attribute(lua_State*)':
../../../texk/web2c/luatexdir/lua/lepdflib.cc:186:58: error: no
matching function for call to 'Attribute::Attribute(const char*&,
int&, Object*)'
uout->d = new Attribute(n, nlen, (Object *)uobj->d);
^
../../../texk/web2c/luatexdir/lua/lepdflib.cc:186:58: note: candidates are:
In file included from /usr/include/poppler/StructTreeRoot.h:20:0,
from ../../../texk/web2c/luatexdir/image/epdf.h:51,
from ../../../texk/web2c/luatexdir/lua/lepdflib.cc:22:
/usr/include/poppler/StructElement.h:77:3: note:
Attribute::Attribute(const char*, Object*)
Attribute(const char *name, Object *value);
which prevents me from building it properly for couple of months now.
Now for something completely different. Why it is hard to reduce granularity
of TeX Live distribution. TeX Live consists of the following levels of packaging
abstractions:
Schemes consisting of Collections consisting of CTAN packages. Schemes
depend on Collections
and they depend of particular CTAN packages. Now, CTAN packages in
Collections do overlap as
well as Collections in Schemes do overlap so the only solution is to
have CTAN packages packaged
separately and define all dependencies via Scheme and Collection meta
packages. This is roughly
how it is done now.
Entropy never decreases and we need to deal with it.
Jindrich
4 years, 2 months
