DevHeads.net

Postings by Christopher

Intent to orphan js-jquery1 and js-jquery2

It is my intention to orphan js-jquery1 and js-jquery2. Does anybody want
to take them over?

These very old versions of jQuery have security issues that I do not have
time nor expertise to maintain. Upstream's last patch for either of these
occurred over 2 years ago. Everybody should be using jQuery 3 by now
(js-jquery). Anything older is insecure and unsafe.

Personally, I think they should be retired, but I don't know (or have time
to check) to see if that would cause problems for anybody.

Can't fork in src.fedoraproject.org

When I try to fork rpms/thrift, I get the error message: Repo
"forks/ctubbsii/thrift" already exists.

However, it clearly does not exist. It is not listed at
<a href="https://src.fedoraproject.org/user/ctubbsii" title="https://src.fedoraproject.org/user/ctubbsii">https://src.fedoraproject.org/user/ctubbsii</a> , which shows 0 forks.

Perhaps I forked it in the past, and the delete did not get cleaned up
correctly? I don't know.

Updating thrift in rawhide to 0.11.0

(sorry if this gets posted twice; previous attempt was sent from wrong
address and will hopefully bounce anyway)

Thrift in rawhide is currently 0.10.0. My intention is move to Thrift
0.11.0 in rawhide.
Affected packages seem to be:

accumulo (ctubbsii, mizdebsk, milleruntime)
avro (ricardo, gil, lef)
disruptor-thrift-server (trepik)
golang-opencensus (eclipseo, nim, jchaloup)
hive (orphan, pmackinn, coolsvap, moceap)
purple-line (fujiwara)
python-elasticsearch (dbruno, apevec, piotrp)
python-txamqp (dcallagh)

Kernel updates breaking grub configuration with tuned

So, I've been seeing this problem recently where every time I update the
Fedora kernel (currently F27), my grub configuration gets mangled.

I have tuned installed, so it has installed /etc/grub.d/00_tuned, which
executes /etc/tuned/bootcmdline, which in turn spits out when
grub2-mkconfig is run.

### BEGIN /etc/grub.d/00_tuned ###
set tuned_initrd=""
set tuned_params="skew_tick=1"
### END /etc/grub.d/00_tuned ###

However, every time I update the F27 kernel, it mangles the params line, to
something like:

set tuned_params="skew_tick=1"=1"=1"=1"=1"

The =1" can be repeated many times.

Avoiding Jargon: dist-git

Can we stop saying "dist-git" in our docs? Nobody knows what that is.
The service at <a href="https://src.fedoraproject.org" title="https://src.fedoraproject.org">https://src.fedoraproject.org</a> is clearly branded as "Fedora
Package Sources".

Using the jargon "dist-git" in our documentation is simply confusing, since
it doesn't match what the service calls itself, and doesn't match any user
interface packagers use.

How to package a gnome-shell-extension default on?

Is it possible, and if so, how do I package a gnome-shell-extension that is
defaulted to on for all users?

maven-checkstyle-plugin write access

I'm an admin on the maven-checkstyle-plugin repo, but do not have write
access for some reason. Can somebody regenerate the ACLs or whatever so I
can push?

How to get ACLs for specific branch?

Hi,

I am listed as "main admin" on
<a href="https://src.fedoraproject.org/rpms/python-keyring" title="https://src.fedoraproject.org/rpms/python-keyring">https://src.fedoraproject.org/rpms/python-keyring</a>
I took over starting with EPEL7, though, so I don't have access to the el6
branch.

The error is:
$ git push
Total 0 (delta 0), reused 0 (delta 0)
remote: FATAL: W refs/heads/el6 rpms/python-keyring ctubbsii DENIED by
refs/heads/el[0-9]
remote: error: hook declined to update refs/heads/el6
To ssh://pkgs.fedoraproject.org/rpms/python-keyring
!

Modularity questions for "traditional" RPM packaging

Hi, I've been reading a lot lately about Fedora modularity, and I'm still a
bit confused on some points.

Is it necessary for maintainers to create modules for their RPM packages?
Is modularity something that a maintainer for an RPM package must deal with?
What kinds of new issues must an RPM maintainer keep in mind to avoid
making it harder for people creating/maintaining modules?
Do all RPMs have to be in a module to be included in future Fedora
releases?

Push to Batched?

I see a new option in Bodhi called "Push to Batched".
After clicking, it now gives the familiar "Push to Stable" option.

How does this work, what is meant by "Batched", how does it differ from
pushing to "Stable", can one push directly to "Stable", and when was this
change made and explained to packagers? I don't recall seeing anything
about this on this list. Perhaps I just missed the announcement of this
change?

Thanks,

Christopher

Pagure roles at Fedora

Hi,

Pagure seems to play several roles in the Fedora community, but it's a bit
confusing. Perhaps somebody can respond (or write a Wiki article on the
topic) to clear up some confusion.

For example, I hear/read the term "dist-git" a lot, but most of the
conversation about that seems to focus on Pagure being used to host Fedora
source repos. I don't really understand how these terms relate to each
other.

Another example: all the documentation for the transition away from Pkgdb
seems to reference pagure.io. However, that doesn't appear to be where the
things have moved to.

Deleting a fork in src.fedoraproject.org?

I was playing around in the new Pagure <a href="https://src.fedoraproject.org/" title="https://src.fedoraproject.org/">https://src.fedoraproject.org/</a> and I
created a fork of a repo to test. However, I don't need or want this fork.
How do I delete it? There doesn't appear to be an option.

HEADSUP: js-jquery -> js-jquery2

I want to update js-jquery to jQuery 3 (it is currently 2).

Upgrade path w/ new compat package

There seem to be a lot of possible guidance on the Wiki for what I'm trying
to do, but no clear, unambiguous step-by-step path to follow. So, I'm
seeking advice here.

js-jquery provides jquery 2.x and js-jquery 2.x
js-jquery1 provides jquery 1.x and js-jquery1 1.x

I want to upgrade js-jquery to 3.x and provide js-jquery2.
I want to do this efficiently with a minimum amount of time spent in
reviews.

I *think* the process is:

1. Create package review for new package js-jquery2
a. Create js-jquery2 from current js-jquery packaging (with rename)
b.

PPC64LE build for thrift

Hi,

I'm trying to build the latest version of thrift, and am running into a
problem with one of the build tests, which has a dependency on boost-static
for "%{_libdir}/libboost_unit_test_framework.a"

I really have no expertise with PPC at all, and also very limited knowledge
of autotools, but it looks like it's looking in the wrong libdir on PPC64LE.

Any help would be much appreciated.

<a href="https://koji.fedoraproject.org/koji/taskinfo?taskID=18366919" title="https://koji.fedoraproject.org/koji/taskinfo?taskID=18366919">https://koji.fedoraproject.org/koji/taskinfo?taskID=18366919</a>
<a href="https://koji.fedoraproject.org/koji/taskinfo?taskID=18366921" title="https://koji.fedoraproject.org/koji/taskinfo?taskID=18366921">https://koji.fedoraproject.org/koji/taskinfo?taskID=18366921</a>

Strange koji failures

Hi,

I occasionally get this strange failure in koji. Sometimes this happens
with a good package build, and I can just re-submit it without changing
anything, and it works fine. Is this a known issue?

For example, from
<a href="https://kojipkgs.fedoraproject.org//work/tasks/1330/17021330/build.log:" title="https://kojipkgs.fedoraproject.org//work/tasks/1330/17021330/build.log:">https://kojipkgs.fedoraproject.org//work/tasks/1330/17021330/build.log:</a>

sh: /usr/bin/python: No such file or directory

warning: Could not canonicalize hostname: buildvm-14.phx2.fedoraproject.org

New sources format

What's with the new sources format?
The old format, I could do `md5sum -c sources`
Why not make the new format with SHA512 follow the same pattern, so I could
do: `shasum -c sources` or `sha512sum -c sources`?

Is there any standard command-line tool to parse this new format, or do I
just gotta grep/awk/bash my way through it?

Building jquery for F24 branch

Can anybody help me build js-jquery1 for F24? I keep getting some NodeJS
and/or Grunt error with uglify, but only for the F24 branch. I want to
update the package, and I can get all the other branches to build just fine
(including EPEL7, F25, and rawhide), but F24 is broken even before I apply
any updates/changes, and I'm not sure why.

Dumb newbie packager questions

I should probably know the answers to these by now, but...

1. If I trigger more than one build for the same NVR in Koji, which one
will get tagged, and when? Which one will Bodhi use when I create an update?

2. Should I preserve the entire changelog in the SPEC? Or should I roll it
over when I update to the latest upstream? It seems the changelog could
easily become the bulk of a package if everything is preserved, and I'd
think git would suffice for anything older than the last few rebases onto
latest upstream.

3. What does the "e" stand for in n-v-r-e ?

4.

Co-maintainer sponsorship

With some of the stuff transitioning from fedorahosted Trac to pagure, and
with some of the wiki pages not being concise or up-to-date, can somebody
point me to the best current instructions to request a co-maintainer be
added? I have a colleague who's helping me update some of my packages, but
I'm not a sponsor, and he's not currently in the packagers group.

I was waiting before he introduced himself on this list, and he actually
submits his first patch before I proceed with the actual request for him to
be sponsored, but it'd be nice to be familiar with the process in advance.

Thanks.

pkgdb2 devel

Where does pkgdb2 development occur? Searching online, and
<a href="https://admin.fedoraproject.org/pkgdb/" title="https://admin.fedoraproject.org/pkgdb/">https://admin.fedoraproject.org/pkgdb/</a> itself points to
<a href="https://fedorahosted.org/pkgdb2/" title="https://fedorahosted.org/pkgdb2/">https://fedorahosted.org/pkgdb2/</a>

That page says there's a clone at
<a href="https://github.com/fedora-infra/pkgdb2" title="https://github.com/fedora-infra/pkgdb2">https://github.com/fedora-infra/pkgdb2</a>

But, based on what's at both locations, it seems like the Trac page is out
of date and so is the link at the bottom of pkgdb, and the development is
actually occurring on GitHub.

In short, should I file a Trac ticket or a GitHub issue for a feature
request?

Koji payload hash?

What is the "Payload Hash" in koji?
It looks like an MD5, but of what? It's not the rpm... I've checked.
Should koji be providing verification hashes for manual downloads of built
RPMs? I think this would be useful for testing.

<a href="http://koji.fedoraproject.org/koji/rpminfo?rpmID=8351409" title="http://koji.fedoraproject.org/koji/rpminfo?rpmID=8351409">http://koji.fedoraproject.org/koji/rpminfo?rpmID=8351409</a>

fedpkg local --noclean?

Is it possible to pass rpmbuild options like --noclean to `fedpkg local`?
If so, I can't seem to figure out how.

Please bump bz#1017603 to F24

Can somebody please re-open and bump
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1017603" title="https://bugzilla.redhat.com/show_bug.cgi?id=1017603">https://bugzilla.redhat.com/show_bug.cgi?id=1017603</a> to F24. The bug was
auto-closed because it was marked for F22. I've taken the package for newer
Fedora versions, but cannot update bugs marked for older Fedora versions
which were auto-closed, because I don't have permission. (Permission can't
even be granted for F22, because it's EOL, so I can't ask an admin on the
older branches.)

Please Mark bz#1164414 for EPEL7

Can somebody please reopen and appropriately mark the following bug for
EPEL7, so it doesn't get auto-closed on new Fedora releases? Thanks.

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1164414" title="https://bugzilla.redhat.com/show_bug.cgi?id=1164414">https://bugzilla.redhat.com/show_bug.cgi?id=1164414</a>

Did something change with ssh-agent in F24?

Previously in F23, an ssh-agent was running when I started a gnome session.
I believe (perhaps incorrectly) that this was being provided by
gnome-keyring-daemon.

Now, it appears that one isn't running.

fedora-packager installs yum

Installing fedora-packager pulls in yum as a dependency. Is this expected
on a system built around dnf and without yum already installed?

Unsorted comps

So, I'm trying to follow the retire instructions to retire nc6 and update
comps, and I noticed a discrepancy between the instructions for updating
the comps, and the actual state of the comps files.

Running the xsltproc command at
<a href="https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups" title="https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups">https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package...</a>
always results in a different/re-sorted/de-duplicated version of the comps
file.

(retire nc6) never retired a package before

Hi all,

I've never retired a package before, so I'm trying to figure out my way
through it for nc6.

Background:

* nc was properly obsoleted by nmap-ncat, and retired (though, it hasn't
been removed from comps entirely)
* nc6 should also be obsoleted by nmap-ncat with nc, but it never was.
Instead it was just orphaned, so I took it (before I fully understood the
situation).

What I'm wondering is:

Which branch should I retire this in, and work with nmap packager to add an
Obsoletes line for nc6? Just master/rawhide? Or all branches?

i686 failures

I'm trying to revive rpms/hadoop, but am running into some failures[1] on
i686 in koji that I cannot reproduce locally in x86_64. The thing is... I
don't really have any good 32-bit environment to test this locally. Hadoop
isn't really suitable for 32-bit architectures (IMO) and I doubt it's a
well-tested upstream arch.

Any suggestions for how I should proceed? Is it really necessary that *all*
packages support i686 arch, even when it doesn't make sense for the
application's users?

[1]: <a href="http://koji.fedoraproject.org/koji/taskinfo?taskID=14521689" title="http://koji.fedoraproject.org/koji/taskinfo?taskID=14521689">http://koji.fedoraproject.org/koji/taskinfo?taskID=14521689</a>