DevHeads.net

Postings by Bruno Wolff III

No i686 build of grub2?

Currently grub2 isn't being built for i686 since somewhere between
2.02-8 and 2.02-10.
I looked through the change log (but not the git log yet) and didn't see
anything mentioning this, which I would have expected if it was an
intentional change.
So is this a new permanent feature going forward or a temporary oops?
(I still have one machine I use regularly, that only runs i686 and it
will probably be a while before I can afford to replace it.)

I'm still here

I haven't had much time for Fedora develoment the last 9 months or so, but I
may be able to start doing more again around August. I continue to use
Fedora on my work desktop and multiple machines at home (currently rawhide).

Intending to retire and/or orphan festival

I plan to retire festival before f25 beta unless someone else wants to
take it over.

It really needs a lot of work to update it to a current version. Also recently
outside changes have resulted in it segfaulting (even after a rebuild) and
it is currently unusable.

gstreamermm 0.10 -> 1.4 change

Maybe I missed something, but I didn't see any announcement about gstreamermm
changing from 0.10 to 1.4. Is there any documentation on what packages
that need gstreamermm are supposed to do to cope with the change?
In my case, I'm trying to get lordsawar working again and upstream isn't
to active right now, so I probably won't get help from them.

What's up with boost in rawhide?

Rawhide has boost 1.6 now but a number of packages haven't been rebuilt
for it yet. I haven't seen bugs filed against my packages asking me to
fix things, so I am wondering if the boost guys were planning to do rebuilds
or if there was some other plan I should be aware of. The change page seems
to not cover this state. The was a place to link to a message they would
send for help abput rebuilds, but it wasn't filled in. It's certainly
possible that a message was sent and I missed it and the change page
didn't get updated.

Using a patch with DOS line endings

I have a patch for a source file that has DOS line endings and %patch
strips the \r characters causing the patch to fail while suggesting the
use of the --binary option. However the %patch macro will not accept
the binary option.

Is there an easy way to use a patch with DOS line endings or am I going
to need to convert the fix to unix line endins in prep, before applying
the patch?

Should generic-release issues block releases?

This is being post to remixes, test and devel since people on test and devel
may not ordinarily be involved with remixes, but might want to comment.
Replies have been pointed back to the remixes list (hopefully won't be
munged) and you probably should join remixes temporarily if you want to
follow this thread.

In yesterday's QA meeting bug
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1224561" title="https://bugzilla.redhat.com/show_bug.cgi?id=1224561">https://bugzilla.redhat.com/show_bug.cgi?id=1224561</a> was nominated as an f23
final blocker.

lordsawar changing from GPLv2+ and GFDL to GPLv3+ and GFDL

While working on the 0.3.0 for lordsofwar update I noticed that it is now
GPLv3+ and GFDL instead of GPLv2+ and GFDL.

dnf and removing the running kernel

It looks like I got burned by dnf removing the running kernel during update.
Due to dracut / grubby issues only my oldest kernel was bootable. I didn't
notice that the old kernel had been removed until after the machine crashed
(I suspect because the kernel had removed, since that kernel had been
working just fine for months.)

This is something that really needs to be fixed by default.

appdata validation and <li> too long

The hedgewars appdata file from upstream is getting flagged as invalid by
rpmlint. I checked with appdata-validate and get the following:
appdata-validate -v /usr/share/appdata/hedgewars.appdata.xml
/usr/share/appdata/hedgewars.appdata.xml 1 problems detected:
• style-invalid : <li> is too long

What is the limit on the size of list elements?
Does this really break anything or can I just leave it?

rawhide failing to compose

Are the rawhide compose failures being looked at? (I just want to make sure
they have been noticed by people in a position to fix them.)

Unpackaged files checking - oddities

While working on a spec file to cause build failure if new fonts showed
up in a package, I noticed two oddities with the checking for unpackaged
files.

An unpackaged empty directory will not trigger a build failure.

If a file is covered by %exclude in the main package, but is not included
in any subpackage, it will not trigger a build failure.

mygui changed from LGPLv3+ to MIT

The license for mygui changed between 3.2.0 and 3.2.1 from LGPLv3+ to MIT.

Should redhat-release be versioned or unversioned?

While looking at bug 1044675 I noticed that redhat-release is unversioned
in fedora-release and versioned in generic-release. I would expect it
to be the same in both of these packages. I think it probably makes the
most sense to version it for anything that is still using that, but wanted
to check if other people had good reasons for doing it one way or the
other.

P.S. To resolve the actual problem, I am going to change a reference
from redhat-release to system-release, which probably should have
happened a while ago.

How to exclude and arch for a noarch package?

I have a noarch package that depends on kernel-modules-extra that is no
longer being built for arm. What is the proper way to exclude my package
from arm?

oyranos build loop issue

Currently Xcm and oyranos both need each other to build, but because of a
soname bump in libraw, neither can be rebuild right now. I asked upstream
to see if Xcm was really a build dependency. If it is, I'll probably just
note that in a bug against oyranos because I'll probably be out of time
to work on this. I was just doing some provenpackager rebuilds of things
that needed rebuilds for soname bumps and didn't want to get too heavily
involved in cases where there were rebuild failures.

Is the %doc macro supposed to work in rawhide?

I use %doc in ember, but when doing rawhide builds it puts the files
in versioned directories. These files don't end up being included in
the rpm and the build fails because of the unpackaged files.

This seems like a case where a simple rebuild should just work with
the new unversioned doc directories change.

Bruno will be on vacation for a week and a half.

I'm going to be going to the WBC this weekend and will be getting back
after a bit more than a week.

I'll have crappy internet access while I'm there and should be able to
keep a lookout for urgent issues. I should be back in time to handle
branching spin-kickstarts for Fedora branch. I don't think anything
too important is supposed to be happening while I'm gone.

sear and sear-media being retired

I am going to retire sear and sear-media as sear isn't being actively
maintained upstream and ember is the primary worldforge client.

Because of the beta freeze, I won't be doing the actual retirement for
about a week (hopefully). I have already done ember and ember-media
builds that obsolete sear and sear-media, respectively.

xmms being retired as of F19

I plan to retire xmms before F20 is branched as it is causing issues with
the removal of some other obsolete packages and it has no upstream support.

If anyone has objections to this please speak up soon.

Out of date (behind stable) build in testing

hedgewars-0.9.18-1 is still in updates-testing despite it also being in
the release and 0.9.18-3 being in updates. Is there a way I can get rid of
the version in updates-testing?

Any issue with fedpkg new-sources?

Hans and I have been having a problem uploading the source for the
new version of hegdewars to the lookaside cache. There is some initial
network traffic, but then things hang.

Has anybody successfully uploaded a new file to the lookaside cache in
about the last 12 hours?

I'll have odd connectivity the next week or so

I'm leaving for a vacation tonight and will be on the road through most of
Monday. Similarly next week when I return. In between I'll should have
some network access, but my schedule will be weird. If something important
cmoes up, I'll probably be able to deal with it.

Ogre going to 1.7.4 (rawhide now, f17 soon)

I am upgrading ogre to 1.7.4 in rawhide. I am handling rebuilds of the
few dependencies.

Assuming things go OK, I'll be doing the upgrade in f17 soon,

pdfs and gpl v2

egoboo is a gpl v2 project that provides some pdf documentation files
in the same tarball as the source. Is it OK to distribute those?
(I didn't any other license noted in these files but I could have missed one.)

Non-free tarball checked in

I checked in a tarball for egoboo that turned out to have a non-free
(noncommercial restriction) font file in it. The tarball has only
been used for local builds (no scratch-builds). Do I need to remove
this tarball from the lookaside cache? If so how do I do it?
The hash is e6f3130695d297dcd9fe74e50bd59b68.

C++ ABI rebuilds for rawhide too?

Are the same packages going to get automatically rebuilt in rawhide as
well as f17?

Don't be afraid to ask for help

I am sending this because, we have a lot of FTBFS packages which I have
see at least one blog griping about, I accidentally fixed something that
was blocking other work (in the sense that I didn't know that other work
that I wouldn't have to do was waiting for this problem to be solved) and
I fixed something for someone that asked for help in a roundabout way.

We are all not experts in everything and it isn't a problem to ask for
help if you are stuck on something for a package.

Is there a way to passphrase protect my koji cert?

While replacing my koji cert yesterday I was interested in adding a
passphrase to slow down exploitation if my home desktop got compromised.
I've look through some of the documentation for maintainers and I haven't
seen any instructions on how to protect it with a passphrase. Is this
possible? (In a way compatible with fedpkg and koji command line.)

Should we be using Bohdi yet for branched?

It doesn't look like Bohdi isn't set up for branched yet. I thought we had
made the switch over at essentially the same time we branched the source
repositories in the past. Also it looks like bugzilla hasn't been updated
yet to allow f17 as a distro version.

It looks like branched package updates are getting pulled in so it isn't
a big deal right now, but as well get to alpha freeze it's going to be
a problem.