Re: Attention: F16 packages needing rebuilds due to the trailing slash bug of rpm-4.9.1

[Jeffrey Ollie]

On Wed, Aug 17, 2011 at 10:50 AM, Eric Sandeen sand...@redhat.com wrote:

 (aside: when sending lists of rpms like this, it sure would be nice to
 also include the maintainer name, so I could just search for me and know
 if I have an issue)  ;)

This seems to happen a lot - does someone have a script that could be
fed a list of packages and would then do the necessary magic to
reformat the list to include the packager names?  Having something
like that in the Fedora packaging tools would be awesome.

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: gimp

[Jeffrey Ollie]

On Wed, Aug 24, 2011 at 9:36 AM, Richard Shaw hobbes1...@gmail.com wrote:
 On Wed, Aug 24, 2011 at 9:33 AM, Genes MailLists li...@sapience.com wrote:
  It could be built to be installed in parallel with 2.6 - which would
 allow those who want to test/play with it.

 The other option is for someone to build packages and host them on
 fedorapeople.org as a personal repository.

 I certainly wouldn't mind trying 2.7+ but I would like the ability to
 easily revert if I run into problems.

You mean something like this?

http://repos.fedorapeople.org/repos/luya/gimp/

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Kudos to Tom Spot Callaway

[Jeffrey Ollie]

On Fri, Sep 9, 2011 at 2:16 AM, Christoph Frieben
christoph.frie...@googlemail.com wrote:
 2011/9/8 Jóhann B. Guðmundsson:
 On behalf of the systemd convertion team Just wanted to say thanks to
 Tom Spot Callaway he's been on fire today packaging submitted unit
 files and shipping them.

 Your work did not go unoticed!

 I do agree in particular with respect to his labour to provide cromium
 packages to the Fedora community. However, there is always some margin
 to improve: would it be possible to actually sign the chromium builds
 somehow? ~C

What would be more productive (in the long term at least) is figuring
out what the blockers are to getting Chromium into Fedora itself and
getting those fixed, rather than as an external repo.  That way
packages would be signed as a part of the normal update process.

I've never looked at the source or the packages myself so I can't say
anything more - the packages do work fantastically though and I
appreciate all the work Tom has done on them!

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 - F16 upgrade

[Jeffrey Ollie]

2011/9/18 Michał Piotrowski mkkp...@gmail.com:

 Just to let you know - I had to downgrade bind-libs-lite after the
 update, because my network was broken. There is a problem with loading
 lib that is required by dhclient.

This happened to me as well. I think that it happened because I had
been updating my F15 system from updates-testing by manually enabling
the updates-testing repo from the yum command line.  Since
updates-testing wasn't enabled in the config file preupgrade didn't
use the F16 updates-testing repo as a part of the upgrade process.
bind was recently updated so my installed bind from F15
updates-testing was considered newer than the F16 bind.

 I also have an old kernel
 uname -a
 Linux ozzy.pl 2.6.40.4-5.fc15.x86_64 #1 SMP Tue Aug 30 14:38:32 UTC
 2011 x86_64 x86_64 x86_64 GNU/Linux

This happened to me as well, but I'm not sure/don't remember why.

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30

[Jeffrey Ollie]

On Fri, Oct 14, 2011 at 2:58 AM, Jef Spaleta jspal...@gmail.com wrote:

 Has anyone made any serious use of gpg subkeys as ssh auth? I've been
 playing with it a little but havent fully made the jump yet.

I've looked a little at monkeysphere this morning and it looks
interesting.  It'd be nice if at least the FI folks could publish the
host keys for the Fedora systems using monkeysphere.  I plan on giving
monkeysphere a good trial here.  Note that there are a couple of bugs
currently, but they are fairly easy to work around.

https://bugzilla.redhat.com/show_bug.cgi?id=732191
https://bugzilla.redhat.com/show_bug.cgi?id=732203

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: UsrMove feature

[Jeffrey Ollie]

2011/10/25 Björn Persson bj...@xn--rombobjrn-67a.se:

 It's particularly odd that I can use /sbin/mkfs to make a disk image without
 privileges, but /bin/mount won't mount it even if I own both the image and the
 mount point.

You could create a setuid-root executable on the disk image and then mount it.

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Systemd unit file: Can/Should ExecStart and ExecStop run a script?

[Jeffrey Ollie]

On Thu, Nov 17, 2011 at 3:34 PM, Richard Shaw hobbes1...@gmail.com wrote:
 Ok, reviving this conversation!

 I ran into the issue that user mythtv can not create the file
 /var/run/mythbackend.pid. I see other services that have their pid
 file owned by their own user...

systemd doesn't really need a PID file to manage the service, can
mythtv be told not to create it?  If it insists on creating it see if
you can move it to a subdirectory of /run (like /run/mythtv) that is
owned by mythtv.

 Also, user mythtv can't write to the log file in /var/log/mythtv/

Change the ownership of /var/log/mythtv.

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Asterisk 1.8 in Rawhide (F-15)

[Jeffrey Ollie]

I've just built Asterisk 1.8.0 Beta 2 for Rawhide (F-15).  The
packages are completely untested at this point so I make no guarantees
at this point about it's usability.  I'll be doing some testing on my
own but I'd appreciate any testing that anyone else can do.

Since we have already passed F-14's feature freeze date I am very
unlikely to update F-14 to Asterisk 1.8 so F-13 and F-14 will stick
with 1.6.2.X until they go EOL.

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Orphaning PiTiVi

[Jeffrey Ollie]

I no longer have the time or the GStreamer-fu to do justice to the
PiTiVi package.  There are quite a few bugzilla entries piling up that
need some work.  Many are probably bugs in the underlying GStreamer
infrastructure...  Benjamin Otte (company) is listed as a
co-maintainer but I'm sure he'd appreciate some help as well.

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Python 3.2a1 in rawhide

[Jeffrey Ollie]

On Sat, Aug 21, 2010 at 5:48 PM, David Malcolm dmalc...@redhat.com wrote:
 I just built Python 3.2a1 into rawhide:
  http://koji.fedoraproject.org/koji/buildinfo?buildID=191382
 so the meaning of python3 in rawhide just jumped from Python 3.1 to
 Python 3.2

I tried rebuilding python-lxml, but I ran into this error:

gcc -pthread -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64
-mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -fPIC
-I/usr/include/libxml2 -I/usr/include/python3.2 -c
src/lxml/lxml.etree.c -o
build/temp.linux-x86_64-3.2/src/lxml/lxml.etree.o -w
src/lxml/lxml.etree.c: In function '__Pyx_Method_ClassMethod':
src/lxml/lxml.etree.c:144925:44: error: 'PyMethodDescrObject' has no
member named 'd_type'
error: command 'gcc' failed with exit status 1

The full build log can be found here:

http://koji.fedoraproject.org/koji/getfile?taskID=2417411name=build.log

I'm not familiar enough with C extensions in Python to find the fix
quickly, unless there's a FAQ somewhere with common problems when
porting between Python 2 and Python 3...

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Python 3.2a1 in rawhide

[Jeffrey Ollie]

On Mon, Aug 23, 2010 at 7:16 PM, David Malcolm dmalc...@redhat.com wrote:

 A suggested fix (caveat: not tested): ensure that the python-lxml.spec
 has a
  BuildRequires: Cython = 0.12
 and delete the .c file in the %prep, to ensure that Cython regenerates
 it during the build.

 Does this fix it?

That worked, or at least it let me build.  Cython isn't available for
python3 apparently so you can't let the python3 build stage generate
the .c files, you need to generate them during the python2 build stage
and copy them over to the python3 build dir.

One other issue I discovered was that I needed to suppress byte
compiling during the install stage because it seemed that the python3
installer somehow was doing python2-style byte compilation. (Or maybe
I'm just misunderstanding things)

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Python 3.2a1 in rawhide

[Jeffrey Ollie]

On Tue, Aug 24, 2010 at 10:37 AM, David Malcolm dmalc...@redhat.com wrote:
 On Tue, 2010-08-24 at 09:10 -0500, Jeffrey Ollie wrote:

 One other issue I discovered was that I needed to suppress byte
 compiling during the install stage because it seemed that the python3
 installer somehow was doing python2-style byte compilation. (Or maybe
 I'm just misunderstanding things)

 That sounds weird.  Do you have a build log?

http://koji.fedoraproject.org/koji/buildinfo?buildID=191689

If you look at the python3 subpackage you'll see that for foo.py there is
a foo.pyc as well as __pycache__/foo.pyc and __pycache__/foo.pyo

The fixed build is here:

http://koji.fedoraproject.org/koji/buildinfo?buildID=191767

Which I obtained by adding --no-compile to the %install section.
rpmbuild does it's own byte compilation anyway so nothing is gained by
doing the compilation in both places.

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Asterisk 11 for Fedora 18 (and other future plans for Asterisk in Fedora/EPEL)

[Jeffrey Ollie]

Digium released the first release candidate for Asterisk 11 yesterday, with
the final release due hopefully sometime this month.  I'm therefore going
to be updating the Asterisk package in Fedora 18 to the release candidate.

Fedora 17 is going to stick with the 10.X series, Fedora 16 is sticking
with the 1.8.X series.

EPEL 6 will stick with the 1.8.X series for the time being as Digium
designates is as a long term support release[1].  Digium plans on ending
support for 1.8.X in 2015 while RHEL 6 support from Red Hat will continue
until 2020[2] so at some point in 2015 Asterisk in EPEL 6 will need to
switch to a newer version, probably version 13 if Digium's plans hold.

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions
[2] https://access.redhat.com/support/policy/updates/errata/

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Red Hat QXL GPU Driver for Windows 7?

[Jeffrey Ollie]

When I powered up the Windows 7 guest that I have on my Fedora 18 system at
work, it wanted to install a driver for a Red Hat QXL GPU device.
Googling didn't turn up anything definitive but I'm wondering if this is an
early result of:

http://fedoraproject.org/wiki/Features/QXLKMSSupport

Is there someplace to get updated video drivers for Windows 7?

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Beware: Thunderbird (ver 3.0.1) CORRUPTS all email state

[Jeffrey Ollie]

On Thu, Jan 28, 2010 at 7:29 AM, Alex Hudson fed...@alexhudson.com wrote:

 I think it's a bit unfair to assume less than good faith on the part of
 other developers.

Amen...  I too use Thunderbird daily (including 3.0.1) and I have not
seen these issues either.  Although it does appear that the update
bypassed updates-testing and went straight to updates.  The notes seem
to indicate security fixes but there are no links to any bugs...

https://admin.fedoraproject.org/updates/F12/FEDORA-2010-0904

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 13 has been branched!!

[Jeffrey Ollie]

On Tue, Mar 2, 2010 at 10:54 PM, Kevin Kofler kevin.kof...@chello.at wrote:

 Yet another perfect example of an update which should have been pushed
 directly to stable.

No, it's an example of an update that should have been pushed to
updates-testing sooner...

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: desktopcouch?

[Jeffrey Ollie]

On Fri, Mar 12, 2010 at 8:56 AM, Tom spot Callaway
tcall...@redhat.com wrote:
 On 03/12/2010 09:47 AM, Jeffrey Ollie wrote:
 So is anyone going to submit a review of desktopcouch?  I've been
 messing with it for a personal project so I figured I'll at least get
 the review done and get it into the repos.  Long-term I'd appreciate
 some co-maintainers...

 I'll need it for gwibber, so I will either submit a review or actually
 do the review. Let me know what you'd prefer.

https://bugzilla.redhat.com/show_bug.cgi?id=573012

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F-13 Branched report: 20100317 changes

[Jeffrey Ollie]

On Fri, Mar 19, 2010 at 1:25 PM, Thomas Spura
spur...@students.uni-mainz.de wrote:

 Why testing?

 A maybe-broken update is better than a non-working programm isn't
 it?

Because there are a significant number of people that will scream
bloody murder if people push packages directly to stable without
having the package spend at least a little time in testing, no matter
what the reason.  There have been enough problems with seemingly
safe updates that go directly to stable that I have a hard time
disagreeing with them.

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

New maintainer for Quod Libet

[Jeffrey Ollie]

I no longer use Quod Libet on a regular basis and I can't spare the
time right now to fix up the issues that the package has.  So I'm
looking for someone to take over maintainership.  I would have
released ownership in the package database already but I'm getting an
error...

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

SSSD 1.11 and AD homeDirectory

[Jeffrey Ollie]

I'm messing around a bit with the new AD support in SSSD 1.11.  I've gotten
authentication working against our AD at work, but I'd like to be able to
mount the user's home folder (in our environment, it gets mapped to the
P: drive if you're logging into a Windows system that is part of the
domain) as their Linux home directory.  The user's home folder can be on
one of a dozen or more file servers, so I need to use the AD homeDirectory
attribute and dynamically mount the CIFS filesystem.

Numerous Google searches and man page readings haven't turned up the magic
incantation that I need to turn this on.  Is what I want to do possible
with SSSD 1.11?  If so, is it documented anywhere than the source?

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: SSSD 1.11 and AD homeDirectory

[Jeffrey Ollie]

On Wed, Sep 11, 2013 at 3:07 PM, Simo Sorce s...@redhat.com wrote:

 Almost certainly you do not want a home directory backed by a cifs
 filesystem, however if you really do I suggest you configure autofs and
 cifs with multi-user mounts on your machine.

It's not a question of want, I'm trying to integrate a Fedora
desktop(s) as seamlessly as possible into an existing Active Directory
environment, and that means having a user's personal files accessible
as seamlessly as possible.  The new AD support in SSSD 1.11 means that
the AD admins don't need to extend the AD schema and maintain the new
attributes.

 You will not be able to have the home directory be specified by the AD
 server though unless you want to cleverly use the unixHomeDirectory
 attribute (and your windows admin properly populates it for each user).

The actual attribute in AD is homeDirectory and is populated with
UNC paths to the user's home directory.  I'll have to dig into autofs
to see if it can do what I want.

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Building Gimp 2.7.2 problem

[Jeffrey Ollie]

On Mon, Dec 20, 2010 at 2:45 PM, Luya Tshimbalanga
l...@fedoraproject.org wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hello,
 I attempt to build gimp 2.7.2 for my repos.fedorapeople.org using koji
 scratch but got result:

 tions -Winit-self -Wpointer-arith -Wold-style-definition
 -Wmissing-format-attribute -Wformat-security  -c gimptooloptions.c
 gimptemplate.c:344:1: fatal error: error writing to -: Broken pipe
 compilation terminated.

Did you link to the same build as you cut'n'pasted?  The build you
linked to errored out due to the following:

gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../.. -I../../app
-I../../app -pthread -I/usr/include/gegl-0.1 -I/usr/include/babl-0.1
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include   -pthread
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng12
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include   -I/usr/include
-DG_LOG_DOMAIN=\Gimp-GEGL\ -DGIMP_DISABLE_DEPRECATED
-DBABL_DISABLE_DEPRECATED -DGSEAL_ENABLE
-DGDK_PIXBUF_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED
-DGTK_DISABLE_DEPRECATED -DPANGO_DISABLE_DEPRECATED
-DGDK_MULTIHEAD_SAFE -DGTK_MULTIHEAD_SAFE  -fPIC -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -fno-strict-aliasing
-Wdeclaration-after-statement -Wmissing-prototypes -Wstrict-prototypes
-Wmissing-declarations -Winit-self -Wpointer-arith
-Wold-style-definition -Wmissing-format-attribute -Wformat-security
-c gimpoperationposterize.c
gimpoperationcagecoefcalc.c:23:34: fatal error:
gegl-buffer-iterator.h: No such file or directory
compilation terminated.
  CC gimpoperationthreshold.o
gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../.. -I../../app
-I../../app -pthread -I/usr/include/gegl-0.1 -I/usr/include/babl-0.1
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include   -pthread
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng12
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include   -I/usr/include
-DG_LOG_DOMAIN=\Gimp-GEGL\ -DGIMP_DISABLE_DEPRECATED
-DBABL_DISABLE_DEPRECATED -DGSEAL_ENABLE
-DGDK_PIXBUF_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED
-DGTK_DISABLE_DEPRECATED -DPANGO_DISABLE_DEPRECATED
-DGDK_MULTIHEAD_SAFE -DGTK_MULTIHEAD_SAFE  -fPIC -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -fno-strict-aliasing
-Wdeclaration-after-statement -Wmissing-prototypes -Wstrict-prototypes
-Wmissing-declarations -Winit-self -Wpointer-arith
-Wold-style-definition -Wmissing-format-attribute -Wformat-security
-c gimpoperationthreshold.c
  CC gimpoperationpointlayermode.o
gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../.. -I../../app
-I../../app -pthread -I/usr/include/gegl-0.1 -I/usr/include/babl-0.1
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include   -pthread
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng12
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include   -I/usr/include
-DG_LOG_DOMAIN=\Gimp-GEGL\ -DGIMP_DISABLE_DEPRECATED
-DBABL_DISABLE_DEPRECATED -DGSEAL_ENABLE
-DGDK_PIXBUF_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED
-DGTK_DISABLE_DEPRECATED -DPANGO_DISABLE_DEPRECATED
-DGDK_MULTIHEAD_SAFE -DGTK_MULTIHEAD_SAFE  -fPIC -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -fno-strict-aliasing
-Wdeclaration-after-statement -Wmissing-prototypes -Wstrict-prototypes
-Wmissing-declarations -Winit-self -Wpointer-arith
-Wold-style-definition -Wmissing-format-attribute -Wformat-security
-c gimpoperationpointlayermode.c
gimpoperationcagetransform.c:23:34: fatal error:
gegl-buffer-iterator.h: No such file or directory
compilation terminated.

 Can anyone help rebuilding this gimp package? Thanks
 Ref: http://koji.fedoraproject.org/koji/taskinfo?taskID=2678792

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Problems with Rawhide Buildroot?

[Jeffrey Ollie]

Trying to build a new Asterisk package in rawhide this morning I'm getting this:

DEBUG backend.py:745:  /usr/bin/yum --installroot
/var/lib/mock/dist-f15-build-966033-145591/root/  groupinstall build
DEBUG util.py:281:  Executing command: /usr/bin/yum --installroot
/var/lib/mock/dist-f15-build-966033-145591/root/  groupinstall build
DEBUG util.py:247:  Error: Package: 4:perl-5.12.3-149.fc15.x86_64 (build)
DEBUG util.py:247: Requires: perl(Tk::Pod)
DEBUG util.py:247:   You could try using --skip-broken to work around
the problem
DEBUG util.py:247:  Error: Package: 4:perl-5.12.3-149.fc15.x86_64 (build)
DEBUG util.py:247: Requires: perl(Mac::InternetConfig)
DEBUG util.py:247:  Error: Package: perl-CPAN-1.9402-149.fc15.noarch (build)
DEBUG util.py:247: Requires: perl(Mac::BuildTools)
DEBUG util.py:247:   You could try running: rpm -Va --nofiles --nodigest
DEBUG util.py:320:  Child returncode was: 1

Full info here:

http://koji.fedoraproject.org/koji/taskinfo?taskID=2743524

I don't think it's just me as I've seen a couple of other failed
builds in Koji with the same problem:

http://koji.fedoraproject.org/koji/taskinfo?taskID=2743531
http://koji.fedoraproject.org/koji/taskinfo?taskID=2743521

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [ACTION REQUIRED] orphaned packages in rawhide

[Jeffrey Ollie]

On Tue, Feb 8, 2011 at 4:24 AM, Richard Hughes hughsi...@gmail.com wrote:
 On 7 February 2011 20:59, Bill Nottingham nott...@redhat.com wrote:
 Orphan smolt

 Don't we still use this by default on all spins?

Did Mike McGrath drop maintainership of smolt when he stepped out of
the Fedora Infrastructure Lead role?  I used to maintain this
(upstream development as well) but I dropped out a while back when my
non-Fedora commitments started taking up more of my time.

If no one seems eager to take over maintainership should we replace
smolt with another tool that has some momentum behind it?

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: mass rebuild status

[Jeffrey Ollie]

On Fri, Feb 11, 2011 at 9:23 AM, Dennis Gilmore den...@ausil.us wrote:

 asterisk

This one should be taken care of now.  I suspect that something in
F15/rawhide changed that made Asterisk's build system think that an
optional dependency was now a mandatory one.

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: mass rebuild status

[Jeffrey Ollie]

On Fri, Feb 11, 2011 at 3:20 PM, Christopher Aillon cail...@redhat.com wrote:
 On 02/11/2011 11:49 AM, Jeffrey Ollie wrote:
 On Fri, Feb 11, 2011 at 9:23 AM, Dennis Gilmoreden...@ausil.us  wrote:

 asterisk

 This one should be taken care of now.  I suspect that something in
 F15/rawhide changed that made Asterisk's build system think that an
 optional dependency was now a mandatory one.


 Yeah, the new rpm changed something with the way perl requires were
 generated.  It broke a few other things, too.

Actually it's not rpm-related, the Asterisk actually has a custom
C-based dependency checker and I wonder if something in gcc changed
and broke it.  I haven't had a chance to do much debugging except to
figure out a workaround.

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

New celt build broke jack-audio-connection-kit...

[Jeffrey Ollie]

I was just trying to build the latest Asterisk, which uses
jack-audio-connection-kit, but it looks like the most recent build of
celt from this afternoon broke the build:

DEBUG util.py:247:  libcelt0.so.1()(64bit) is needed by
jack-audio-connection-kit-1.9.6-4.fc16.x86_64

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 and Broadcom BCM4313

[Jeffrey Ollie]

On Wed, Apr 27, 2011 at 10:16 AM, Adam Williamson awill...@redhat.com wrote:

 In addition to what Matt says, probably the best way to get it working
 in F15 for now (pragmatically speaking) is to install the proprietary
 'wl' driver from a third party repository (the standard one has it
 packaged as kmod-wl / akmod-wl). That driver supports the chip in
 question and works, per multiple reports.

Yep, I have a HP Mini 5103 with the BCM 4313 chipset and wireless
works just fine once I installed akmod-wl from rpmfusion.

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposal: retire bittorrent

[Jeffrey Ollie]

On Wed, Jun 15, 2011 at 9:55 PM, seth vidal skvi...@fedoraproject.org wrote:

 Heck, I'd be willing to accept ANY bittorrent server that can be both
 tracker and primary seed and doesn't require a special apache module to
 do it.

 The biggest virtue of the old bittorrent client is that it is simple,
 stand  alone and while not fancy, it is straightforward to understand.

Why not look into using Web/HTTP seeding rather than running a client
for the initial seed?  The only downsides that I know of so far:

1) Not supported in rtorrent
2) Transmission doesn't apply any bandwidth limits to Web/HTTP seeds

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Heads-up: net-snmp soname bump in rawhide

[Jeffrey Ollie]

On Thu, Jul 7, 2011 at 8:23 AM, Jan Safranek jsafr...@redhat.com wrote:
 net-snmp-5.7 is heading to rawhide, please rebuild your packages if you
 depend on it.

 asterisk

I haven't dug into this deeply yet, but this seems to have broken the
asterisk build.

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Update thunderbird to 5.0?

[Jeffrey Ollie]

On Thu, Jun 30, 2011 at 8:57 AM, Heiko Adams
fedora-upda...@heiko-adams.de wrote:

 as far as I remember the versions of firefox and thunderbird have
 allways been sinchronuos at their latest stable version. So I'd like to
 know for personal interest if there are reasons that would deny updating
 thunderbird packages to version 5.

Thunderbird 5.0 is now in updates-testing...

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: gdbm license change

[Jeffrey Ollie]

On Mon, Nov 14, 2011 at 1:32 PM, Haïkel Guémar karlthe...@gmail.com wrote:

 PS: why the hell are we still shipping this crap ? Ruby 1.9.x has been
 the stable branch for almost three years, now. Upstream has decided to
 stop providing bugfixes for Ruby 1.8.7 by june 2012 and CVE fixes by
 june 2013.

From what I know there is a lot of software out there that isn't
compatible with Ruby 1.9 yet.  Puppet is one major example.

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F16: compile shotwell 0.12

[Jeffrey Ollie]

On Thu, Mar 29, 2012 at 10:10 AM, Thomas Moschny
thomas.mosc...@gmail.com wrote:

 You can try the shotwell RPMs from here (12.1 available only for F16 so far):
 http://repos.fedorapeople.org/repos/thm/shotwell/

 Please note that these are _not_ official builds. Please send feedback
 about these packages to me first.

Thanks for putting the 0.12 rpms together.  I'm getting back into
digital photography and so far I like shotwell the most for managing
my photos (although I need to sit down and give darktable a serious
look soon).

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Thunderbird bz 579023 still not fixed even though there is an upstream fix available

[Jeffrey Ollie]

On Thu, Apr 22, 2010 at 1:39 PM, Felix Schwarz
felix.schw...@oss.schwarz.eu wrote:

 I'm concerned about bz 579023 [1] which is a Thunderbird crasher bug.
 This bug was fixed upstream [2] for about 3-4 weeks. I ran a thunderbird
 koji  build version [3] with an adapted version of that patch since then
 without any problems. Other users confirmed that this patch fixes their
 problems as well.

 The Fedora bug has a number of duplicates with quite some number of cc'd
 users so I guess a lot of people experiencing these crashes.

And probably a lot of people aren't.

 However it is still not fixed in Thunderbird F-12 CVS. Can you please
 push the fix to CVS and push builds to testing/stable?

Why isn't Mozilla releasing a new version that contains the fix?

And even if the Fedora Thunderbird maintainer decides to push a
patched package to F-12, there's no way it should be pushed directly
to stable.

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Heads up! CouchDB 0.11.0 will soon hit Rawhide near you.

[Jeffrey Ollie]

On Thu, Jun 17, 2010 at 7:24 AM, Peter Lemenkov lemen...@gmail.com wrote:

 I don't aware of any incompatibilities, but, anyway, I would like to
 warn you all.  If everything will be OK, and no incompatibilities will
 be found  (or only easy-to-fix ones), then I'll consider upgrading
 F-13 (and, perhaps, even F-12) too.

I tried updating my F-12 system to 0.11.x and had problems with Futon
when used in conjunction with DesktopCouch.  I never really found a
resolution and switched back to 0.10.x.

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [HEADS-UP] systemd for F14 - the next steps

[Jeffrey Ollie]

I've been trying to test systemd on my dev box but without success so
far.  My system boots up and I get the usual GDM login screen and VTs
but I can't login.  SSH fails as well.  SSH gives me Unable to get
valid context for jcollie shows me the last login date and closes the
connection.  I think I'm seeing a similar message on the console but
it flashes too quickly for me to be sure.

I haven't gone as far as removing upstart and installing
systemd-sysvinit yet.  Is this my problem?  I've just been adding
init=/bin/systemd to the kernel boot line to try out systemd.  I'd
rather not brick this system so I thought that I'd check here to see
if I had missed anything before removing upstart.

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Python 2.7 rebuild status

[Jeffrey Ollie]

On Sun, Jul 25, 2010 at 8:13 PM, David Malcolm dmalc...@redhat.com wrote:
 Status:
 - we're down to 170 failing builds against python 2.7
 - various BuildRequires are now available in the 2.7 Koji tag:
  - boost and openmpi  (thanks oget!)
  - subversion (I took the liberty of applying a workaround for this)
  - kdebindings
  - gstreamer-python

Thanks to David for tracking down some 2to3 bugs python-lxml is now
available in the 2.7 koji branch.  I'm not sure how many rebuilds were
waiting for that but I'm sure that there are more than a few.

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Orphaning PycURL

[Jeffrey Ollie]

Hello,

I am going to be orphaning the PycURL package...  Upstream is dead,
the last new release was in 2008.  Yet, PycURL is a critical part of
Fedora as Yum uses it to download metadata and packages.

The final straw is that the package failed to build in the latest mass rebuild:

https://bugzilla.redhat.com/show_bug.cgi?id=914411

There are a number of other bugs associated with PycURL, but I didn't
want to become the de facto upstream so I've resisted efforts to apply
patches to the code.

Personally, I'd like to see Yum move away from PycURL but if someone
wants to take over upstream development more power to them.

--
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Orphaning PycURL

[Jeffrey Ollie]

On Fri, Feb 22, 2013 at 2:33 PM, Jon Ciesla limburg...@gmail.com wrote:

 Excellent!  Jeffrey, will you be picking python-pycurl up again, then?

No.  While this was an easy fix that was actually in another package,
PycURL has other problems.  I think that the most obvious one is
handling errors encountered by libcurl (DNS errors, connection
refused, etc.) and passing back sensible error messages back to the
Python layer.  I'm sure a little trolling of bugzilla would turn up
others.

There are patches out there that fix these and other problems, but as
I said, I don't want to become the de facto upstream PycURL
maintainer, especially for a package that is this critical to the
project.  I just don't have the time or interest.

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Orphaning PycURL

[Jeffrey Ollie]

On Fri, Feb 22, 2013 at 3:37 PM, Kamil Dudka kdu...@redhat.com wrote:

 I have taken the ownership for now.

Thanks!

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Orphaning PycURL

[Jeffrey Ollie]

On Fri, Feb 22, 2013 at 3:45 PM, Jeffrey Ollie j...@ocjtech.us wrote:
 On Fri, Feb 22, 2013 at 3:37 PM, Kamil Dudka kdu...@redhat.com wrote:

 I have taken the ownership for now.

I was cleaning up some old email when I ran across an email from Tomáš
Smetana that python-pycurl has been incorporated into RHEL as of
RHEL6, so it would make sense for someone @ Red Hat to maintain
python-pycurl in Fedora (not necessarily Kamil Dudka though).

--
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Init Script asterisk rpm package bug !

[Jeffrey Ollie]

On Wed, Feb 27, 2013 at 9:09 AM, Reindl Harald h.rei...@thelounge.netwrote:

  I have to 'chattr +i /etc/init.d/asterisk' for new updates don´t change
 it ...

 and if you instead
  * chkconfig asterisk off
  * create a native systemd-unit
  * systemctl enable asterisk.service
 you are clean and done
 running here since F15 in 2011


The Fedora packages already have native systemd units. Creating your own
shouldn't be necessary, although you would probably need to extend the
stock unit file to get the proper ordering with respect to hylafax and
iaxmodem.

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

aarch64 bugs

[Jeffrey Ollie]

Yesterday a bunch of bugs were opened up regarding aarch64 support in
some packages.  I'd like to do my part in fixing these, but is there a
way to actually run test builds?  I know that there's ARM support in
the works, but I haven't really kept up with the details.

--
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Dropping byzanz

[Jeffrey Ollie]

I released ownership of byzanz - I haven't used it in a long time and no
longer have the time/interest to maintain it.

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: bugzilla.redhat.com vs upstream bug trackers

[Jeffrey Ollie]

On Mon, Jun 17, 2013 at 7:49 AM, Jóhann B. Guðmundsson
johan...@gmail.com wrote:

 It's package maintainers responsibility to act as the liason between
 upstream and Fedora thus reporters only need to report in our Bugzilla
 instance.

I think that this is a fantasy that is not going to happen unless
every package maintainer's primary employment is maintaining said
packages (not necessarily employed by Red Hat).

I'm sure that I'm representative of many packagers out there - I'm not
paid to maintain packages in Fedora, in fact any open source I get to
use at work is because I've been successful at asking for forgiveness
instead of permission.

I maintain packages in Fedora because it allows me to get what I want
to do done, whether at work or at home.  Since I've done the work of
making these packages, why not share them with the Fedora community?

It drives me absolutely bonkers when people open bugs on the RedHat
bugzilla and then insist that I do the work of coordinating with
upstream because they are too busy or they don't want to create a
bunch of accounts in the upstream bugtracker.  I mean it drives me
absolutely bonkers to the point I have trouble remaining polite.  In
fact I've completely ignored a bug in RedHat's bugzilla for months
because of the reporter's attitude that their time was so much more
valuable than mine that I can't read the bug, much less post a
response without resorting to nasty four-letter words.

The work that I do in maintaining my packages is my contribution back
to the community that has given me so much already.  For most bug
reports, I'm willing to take a little bit of time and see if there's a
new release I've missed or if the bug has been already identified
upstream and there's a patch that can be applied.  But to expect me to
take a significant amount of time to work with upstream to find the
bug and patch it is unrealistic because:

1)  There's a 99.999% chance that I don't have the resources (either
hardware or software) to reproduce the bug.

2) There's a 100% chance that I don't have the time between work and
family obligations.

3) Even though I'm an excellent programmer, well versed in C and
Python, and decent in Perl, Ruby, et. al.  I probably don't have the
familiarity with the codebase to even know where to start looking for
a bug.

4) Most software is complex enough that even configuration problems
are best handled by upstream because I'd be familiar with a small set
of configuration scenarios, but everyone's situation is unique and
understanding what exactly a configuration option does (especially in
edge cases) often requires an understanding of the code behind it.

All of this means that I'm a speedbump in the way of getting the bug
fixed, at least until there's a patch that needs to be applied to the
package, or a new release to upgrade to.

--
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: bugzilla.redhat.com vs upstream bug trackers

[Jeffrey Ollie]

OK, so this post is going to be rather long and rambling, and
hopefully respectful, but I'm passionate about this subject (and
Fedora).  The tl;dr summary is that there shouldn't be a single
standard for what we expect of packagers, especially in the context of
what to expect when bugs are filed against their packages on Red Hat's
bugzilla.  My view is that expectations are going to depend on the
criticality of the package to Fedora (kernel, installer, default
desktop stack) and the packager (are they being paid to maintain the
package in Fedora or are they volunteering their time).

Also, where some of us seem to be at odds is the definition of proper
maintenance for packages.  My definition:

1) Ensure that packages meet all of the packaging guidelines.
2) Fix packaging related bugs in a timely manner.
3) Incorporate new upstream releases, in accordance with packaging
guidelines (e.g. packages shouldn't be updated to a new major version
in a released version of Fedora).
4) Incorporate patches that fix security issues or critical bugs.

In my view these expectations imply that a packager has some
involvement with upstream.  I think that the level of involvement is
going to depend on the packager and the package.  I don't think that a
hard and fast rule can be developed to cover every case without
becoming ridiculously long and complex.  Other than generally
encouraging packagers to become involved with upstream development it
should be left up to the conscience of the packager.

In no way should packagers be expected to provide end-user support for
packages, be an expert in every aspect of a package, or be expected to
work with upstream to debug issues because the end user is unwilling
to do the work themselves (in essence becoming an upstream developer
themselves).

OK, so with that out of a way, I'm hopefully going to respectfully (if
wordily) respond to Jóhann's comments.

On Mon, Jun 17, 2013 at 10:55 AM, Jóhann B. Guðmundsson
johan...@gmail.com wrote:
 On 06/17/2013 03:42 PM, Jeffrey Ollie wrote:

 I maintain packages in Fedora because it allows me to get what I want
 to do done, whether at work or at home.  Since I've done the work of
 making these packages, why not share them with the Fedora community?

 Because if you cannot properly maintain the component in the distribution
 the community is better of without it.

 1)  There's a 99.999% chance that I don't have the resources (either
 hardware or software) to reproduce the bug.

 Then you should not be maintaining that component

In some cases you may be right.  But in most cases I was the only
person to step up and package a particular piece of software.  Also,
in most cases I'm willing to step aside as the owner of a package if
someone wants to take over the responsibility.  In every case I've
been willing to take on co-maintainers to help out with the packaging
duties.

 2) There's a 100% chance that I don't have the time between work and
 family obligations.

 We do not need unresponsive or poor maintained packages in the distribution
 and if there is really need or demand for the component you maintain,
 co-maintainers will appear or people to pick it up if you drop it so if you
 dont have the time to properly maintain your component(s) in the
 distribution then either find yourself co-maintainers or drop the package.

Again, our key disagreement here is on the definition of proper
maintenance.  I have more than enough time to keep up with new
versions as they are released (most of the time) or to pull a patch
out of the upstream's version control and add it to the package. But
even if I had the hardware I don't have the kind of time it takes to
set up test environments to reproduce a bug, and then dig into the
code and find the bug, develop a fix and then test it.

 3) Even though I'm an excellent programmer, well versed in C and
 Python, and decent in Perl, Ruby, et. al.  I probably don't have the
 familiarity with the codebase to even know where to start looking for
 a bug.

 If you aren't familiar with the component you are packaging and maintaining
 why are you doing it et all?

Well, let's take Asterisk.  First off, there are a lot of components
that require specific (and expensive) hardware like ISDN  POTS
adapters.  And if I had the Asterisk-specific hardware I'd need ISDN
or POTS lines to connect to which would mean sending lots of my money
to the local telco or spending lots of money on other telephony
hardware to set up a lab environment.  Then you've got to worry about
country-specific setups.  ISDN and POTS lines work differently
depending on what country you're in, and I've only had minimal
experience with such lines in the US and none at all in other
countries.

Asterisk provides support many VoIP protocols, each with their own
quirks.  A number of them only talk to proprietary hardware (which I
don't own).   Even if you're using SIP, it's one of those protocols
whose specification is fuzzy enough that every implementation

Orphaning desktopcouch

[Jeffrey Ollie]

Hello,

I've orphaned desktopcouch in pkdg, I haven't had in interest in quite
a while and it could use some attention from more active maintenance.

--
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [ACTION REQUIRED] Retiring packages for Fedora 20

[Jeffrey Ollie]

On Tue, Aug 6, 2013 at 9:38 PM, Christopher Meng wrote:
 I don't understand why manaplus was orphaned just after 8 months it
 got into Fedora.

 If you can't keep it, don't package it.

Don't be so judgmental. Life isn't as predicable as one would hope.
There are many reasons for people to stop maintaining a package, and
many times people don't feel comfortable sharing that information with
stranger.

 desktopcouch

Thanks for picking this package up. I did announce that I was
orphaning it a while ago, but no one seemed interested in picking it
up at the time.

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Review Swap

[Jeffrey Ollie]

On Wed, Aug 7, 2013 at 5:56 PM, Nico Kadel-Garcia nka...@gmail.com wrote:
 Given the profound advantages of IMAP, especially the management of folders
 on one server, and the historical fact that *every single POP3 client*
 defaults to deleting the email off the server, I have to ask: why are you
 spending any time on such a server?

 I've done a lot of integration work with SMTP servers and client access, and
 have to wonder why you're doing this with so many stable servers available.

You may find the advantages of IMAP profound but I personally find
the IMAP protocol incredibly ugly, and I think that mail clients have
suffered because of it.  That said, if you want to be able to
access/manipulate multiple folders on the server then IMAP is
currently the only game in town.  If all you want to do is pull the
latest messages from the server down to the client then POP3 is much
simpler and understandable.  Having a POP3 server written in your
scripting language of choice makes it much easier to
configure/customize/understand.

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Broken dependencies: python-osmgpsmap

[Jeffrey Ollie]

On Tue, Aug 13, 2013 at 8:06 AM, Richard Shaw hobbes1...@gmail.com wrote:
 On Sun, Aug 11, 2013 at 8:46 AM, Michael Schwendt mschwe...@gmail.com
 wrote:

 On Sun, 11 Aug 2013 07:58:37 -0500, Richard Shaw wrote:

  Ok, I've been getting these messages for a while but I'm not the package
  owner for I didn't worry about it, however, it's been a couple of weeks
  so
  I decided to take a look to see how much work it would be.

 You are listed as a co-maintainer:
 https://admin.fedoraproject.org/pkgdb/acls/name/python-osmgpsmap

 Exactly, I wasn't sure if the owner had a fix in the works so I didn't want
 to muck anything up.

  Now I'm really confused... There are two separate packages in Fedora:
  osm-gps-map
  python-osmgpsmap
 
  Both point to the same upstream URL. The description from upstream of
  osm-gps-map says it includes python bindings but there is not currently
  a
  separate sub-package generated...
 
  So what's the deal? Do one of these packages need to be retired?

 No. The wrong %description has been pointed out in the review request.

 Review Request: osm-gps-map - A Gtk+ widget for displaying OpenStreetMap
 tiles
 https://bugzilla.redhat.com/show_bug.cgi?id=701982

 Blocks: 702103

 Bug 702103 - Review Request: python-osmgpsmap - Python bindings for
 osm-gps-map GTK+ widget
 https://bugzilla.redhat.com/show_bug.cgi?id=702103

 More than that, although the description on the upstream site still says
 there are python bindings, the whole python directory in the source seems to
 have been removed...

Sorry, just seeing this discussion now.  What happened was that the
newest version of osm-gps-map added gobject introspection, so Python
bindings can be automatically generated.  The older python-osmgpsmap
bindings I believe are deprecated now.  I haven't had the time to set
up a rawhide system to do any testing though but probably what needs
to happen is make sure that anything that used the older bindings get
ported and then the old bindings be retired.  AFAIK the only thing
that used the bindings is Gramps, but I haven't used that in a long
time and turned over ownership.

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Broken dependencies: python-osmgpsmap

[Jeffrey Ollie]

On Thu, Aug 15, 2013 at 8:19 AM, Richard Shaw hobbes1...@gmail.com wrote:

 Checking my F18 system only two packages require python-osmgpsmap...

 # repoquery --whatrequires python-osmgpsmap
 gramps-0:3.4.2-1.fc18.noarch
 kismon-0:0.6-4.fc18.noarch

 I wonder if the current/latest version of gramps and kismon able to use
 these auto-generated bindings?

I'm pretty sure gramps will, as it was a request from that community
that propmpted me to update osm-gps-map in rawhide.

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Broken dependencies: python-osmgpsmap

[Jeffrey Ollie]

On Thu, Aug 15, 2013 at 9:53 AM, Jon Ciesla limburg...@gmail.com wrote:

 Speaking as the new gramps maintainer, if the osm-gps-map Python bindings
 were built, I would be happy to test gramps with them and switch if they
 work.

It's my understanding that with gobject introspection that Python
bindings don't need to be built, they are automatically generated at
runtime.  So all you need is the latest osm-gps-map installed...  I'm
not an expert in that area so I could be wrong though.

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Probem adding bugs to Updates

[Jeffrey Ollie]

I'm getting errors like this when adding an update that references bugs:

Update successfully edited. Unable to access one or more bugs.
Exception: cookiefile=/var/tmp/bodhi-bz.cookie not in LWP or Mozilla
format

This is very recent since I submitted another update minutes before.

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Framework for Server Role Deployment

[Jeffrey Ollie]

On Tue, Apr 8, 2014 at 7:25 PM, Rob Kearey r...@ningaui.net wrote:
This Change, as written, is *extremely* vague, moreso that most other
changes that are filed for Fedora.  Is it intended to be updated with more
information when that becomes available?

 +1 - What are 'server roles'? Are we just reinventing Ansible/Puppet/et al 
 here?

Yeah, why is someone spending time creating a new Fedora-specific
configuration management system rather than just shipping an Ansible
playbook or a Salt formula or whatever?

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf replacement for yum-cron

[Jeffrey Ollie]

On Mon, Jun 16, 2014 at 7:50 AM, Neal Becker ndbeck...@gmail.com wrote:
 Been using yum-cron for years with good results.

 If yum is being phased out, I'll want a dnf-cron replacement

Already exists:

$ rpm -ql dnf | grep systemd
/usr/lib/systemd/system/dnf-makecache.service
/usr/lib/systemd/system/dnf-makecache.timer

$ cat /usr/lib/systemd/system/dnf-makecache.service
[Unit]
Description=dnf makecache

[Service]
Type=oneshot
Nice=19
IOSchedulingClass=2
IOSchedulingPriority=7
Environment=ABRT_IGNORE_PYTHON=1
ExecStart=/usr/bin/dnf -v makecache timer

$ cat /usr/lib/systemd/system/dnf-makecache.timer
[Unit]
Description=dnf makecache timer
ConditionKernelCommandLine=!rd.live.image

[Timer]
OnBootSec=10min
OnUnitInactiveSec=1h
Unit=dnf-makecache.service

[Install]
WantedBy=basic.target


-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

byzanz fails to build

[Jeffrey Ollie]

byzanz is failing to build in rawhide
(https://bugzilla.redhat.com/show_bug.cgi?id=1106024).  Unless someone
else wants it, I will be retiring the package as I have no interest in
it.

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Puppet 4

[Jeffrey Ollie]

On Mon, Jun 15, 2015 at 6:58 AM, Nico Kadel-Garcia nka...@gmail.com wrote:


 The /etc migration, however, is part of the stateless linux work
 desribed at http://0pointer.de/blog/projects/stateless.html.  They're
 planning on resetting /etc to a pristine vendor state, and
 basdically keep it that way. That's a pretty basic violation of 30
 years of the use of /etc.


You appear to ignore the fact that they aren't forcing every system to be
stateless.  They specifically discuss at several points that stateful
systems where /etc et al work as they always have will continue to be
supported.

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Looking for someone to take over Asterisk and related packages

[Jeffrey Ollie]

So, after almost 10 years, it's time to find someone else to take over the
Asterisk packages.  If you're interested, reply to the list.  I'd prefer if
someone with proven packaging skills would step up - Asterisk has several
security-related releases a year in addition to several bug-fix releases so
this isn't the package to get started with.

-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Looking for someone to take over Asterisk and related packages

[Jeffrey Ollie]

Thanks for stepping up Jared!

On Thu, Oct 29, 2015 at 2:28 PM, Jared K. Smith <jsm...@fedoraproject.org>
wrote:

> On Wed, Oct 28, 2015 at 5:03 PM, Jeffrey Ollie <j...@ocjtech.us> wrote:
>
>> So, after almost 10 years, it's time to find someone else to take over
>> the Asterisk packages.  If you're interested, reply to the list.  I'd
>> prefer if someone with proven packaging skills would step up - Asterisk has
>> several security-related releases a year in addition to several bug-fix
>> releases so this isn't the package to get started with.
>>
>> I'd be happy to help out.
>
> --
> Jared Smith
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>



-- 
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F24 System Wide Change: Change Proposal Name NewRpmDBFormat

[Jeffrey Ollie]

On Fri, Jan 15, 2016 at 2:24 AM, Tomáš Smetana  wrote:

>
> I tend to use systemd-nspawn containers for building rpms. So for example,
> I
> have a Fedora 24 system and use its dnf to create e.g. Centos 7 container
> root and then build Centos rpms from within that container.  If I
> understand
> the change correctly, this is going to break since the Centos 7 rpm-build
> will not be able to read the database created by the Fedora 24 dnf.
>

I personally prefer to build my containers by starting with the raw files
that are used to build the base CentOS and Fedora Docker containers:

https://raw.githubusercontent.com/CentOS/sig-cloud-instance-images/CentOS-7.2.1511/docker/centos-7.2.1511-docker.tar.xz
https://download.fedoraproject.org/pub/fedora/linux/releases/23/Docker/x86_64/Fedora-Docker-Base-23-20151030.x86_64.tar.xz

The CentOS tarfile can be easily untarred into an empty directory.  The
Fedora tarball contains a layer.tar file that contains the raw filesystem.

I like doing it this way because I don't have to depend on the host yum/dnf
to set up the filesystem.  This would work too for non-rpm systems (or for
RHEL) as well but I haven't had the need so I haven't searched for the
appropriate media.

-- 
Jeff Ollie
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: attempting to contact nonresponsive maintainer: ivazquez

[Jeffrey Ollie]

On Fri, Jan 15, 2016 at 4:20 PM, David Shea  wrote:

> Does anyone know how to contact Ignacio Vazquez-Abrams? I've been trying
> to contact him in regards to
> https://bugzilla.redhat.com/show_bug.cgi?id=1287273, and have also tried
> contacting him via the email address in bugzilla, and have not received any
> response.
>
> It looks like he has not been active in Fedora for a while. The
> fedora-active-user script returns this:
> Last login in FAS:
>ivazquez 2013-11-05
> Last action on koji:
>Thu, 17 Sep 2015 package list entry created: xmlcopyeditor in f23_Beta
> by ausil [still active]
> Last package update on bodhi:
> ERROR:active-user:'updates'
>
> The last koji action is obviously not correct, and points to another
> problem package: xmlcopyeditor was last updated by ivazquez in 2011, and
> since then has twice had to be updated or modified (like actually modified,
> not just rebulit) for build failures.
>

It's unfortunate, but this isn't the first time that Ignacio has gone AWOL:

https://www.redhat.com/archives/fedora-extras-list/2006-August/msg00708.html
https://www.redhat.com/archives/fedora-extras-list/2006-August/msg00564.html

There's an identically named person that's active on Stack Exchange, but I
have no idea if it's actually the same person.

-- 
Jeff Ollie
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: [OT] Tim, Gil, et. al. (e-mail address settings)

[Jeffrey Ollie]

On Fri, Jul 1, 2016 at 8:42 AM, gil  wrote:

> Il 01/07/2016 01:54, Joel Rees ha scritto:
>
> To keep this off-list as much as possible, the rant is here:
> http://reiisi.blogspot.com/2016/07/to-gil-tim-fedora-et-al.html
>
> (The blame lies elsewhere. I wish I had the network and social cred to
> get a real movement started, away from the current faceless CA system
> and towards a different identity assurance system that depends on
> actual, existing day-to-day trust relationships.)
>
> hi
> as i wrote in the past i dont care about your spam problems
> i dont want to use other providers ... so bored ...
> you dont have something else more interesting to write? No?
> then I'm not interested, i think i will add between unwelcome contact your
> email
>

Gil, you don't seem to realize that this isn't *our* spam problem, it's
*yours*. It's pretty much guaranteed that all of your email sent to the
Fedora mailing lists ends up in the spam folder of people that use GMail.
There are probably many other providers that do the same. And due to the
way that GMail is marking your mail as spam, there's nothing that GMail
users can do to change that.

You're lucky that a few of us are conscientious enough to look through our
spam folder for your emails (as well of a few other Fedora contributors
that get their email routed to the spam folder on a consistent basis). Most
of the Fedora contributors that use GMail probably don't bother.

As has been explained a number of times to you, only you (or your email
provider) can fix this. You seem to want to be a good Fedora contributor,
but whenever someone tries to discuss the issue with you, you've proven to
be hostile and uncaring. No one has asked you to switch to another email
provider, you just need to have the one you use fix the issues that have
been described to you.

-- 
Jeff Ollie
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Screenshots with Wayland and Dual Displays

[Jeffrey Ollie]

On Thu, Oct 6, 2016 at 10:41 PM, Chris Murphy <li...@colorremedies.com>
wrote:

> On Thu, Oct 6, 2016 at 3:59 PM, Jeffrey Ollie <j...@ocjtech.us> wrote:
> > I just noticed that I can't take a screenshot of anything on the
> secondary
> > display when using two displays - you just get a transparent PNG. In
> fact,
> > if you try and grab an area that spans the displays it'll capture the
> screen
> > from the primary display properly while the area from the secondary
> display
> > is transparent. I didn't find anything in Bugzilla that looked similar
> but I
> > wasn't sure if it should be filed under Wayland or something else.
>
> File it against the thing that's taking the screenshot.
>
> What command are you using? I'm using Wayland and taking screenshots
> and don't have that problem with gnome-screenshot; but I have
> something similar with Shutter.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1363845
>

I was able to figure out the search-fu that I needed and found this
existing bug report:

https://bugzilla.redhat.com/show_bug.cgi?id=1381724

-- 
Jeff Ollie
The majestik møøse is one of the mäni interesting furry animals in Sweden.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Screenshots with Wayland and Dual Displays

[Jeffrey Ollie]

I just noticed that I can't take a screenshot of anything on the secondary
display when using two displays - you just get a transparent PNG. In fact,
if you try and grab an area that spans the displays it'll capture the
screen from the primary display properly while the area from the secondary
display is transparent. I didn't find anything in Bugzilla that looked
similar but I wasn't sure if it should be filed under Wayland or something
else.

-- 
Jeff Ollie
The majestik møøse is one of the mäni interesting furry animals in Sweden.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

COPR Arm Builds?

[Jeffrey Ollie]

Will Arm builders be added to COPR at some point?

-- 
Jeff Ollie
The majestik møøse is one of the mäni interesting furry animals in Sweden.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Adding CAP_NET_RAW to binaries

[Jeffrey Ollie]

Instead of setting CAP_NET_RAW on the binary, why not have systemd give the
service the capability at runtime? The blackbox exporter isn't something
that you run from the CLI much anyway is it?

Here's what part of my service file looks like:

[Service]
User=blackbox_exporter
Group=blackbox_exporter
AmbientCapabilities=CAP_NET_RAW
ExecStart=/opt/blackbox_exporter/blackbox_exporter --config.file
/opt/blackbox_exporter/config.yaml --log.level debug

On Fri, Nov 10, 2017 at 10:07 AM,  wrote:

>
> I've done the naïve
> setcap cap_net_raw+ep /builddir/build/BUILDROOT/
> prometheus-blackbox-exporter-0.10.0-1.fc28.llt.x86_64/usr/
> bin/prometheus-blackbox-exporter
>

Maybe this is just bikeshedding, but why have you renamed the binary from
blackbox_exporter to prometheus-blackbox-exporter? blackbox_exporter
doesn't conflict with anything else AFAIK and renaming it is just going to
confuse people when they are reading upstream documentation etc.

-- 
Jeff Ollie
The majestik møøse is one of the mäni interesting furry animals in Sweden.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Retiring iksemel (XMPP library)

[Jeffrey Ollie]

It's been FTBFS for a while and the current version has some insecure
settings so I propose retiring iksemel fairly soon. As far as I can see it
only affects Asterisk and Zabbix. Asterisk's use of iksemel is optional so
it should be easy to build without and I suspect the same is true of Zabbix.

-- 
Jeff Ollie
The majestik møøse is one of the mäni interesting furry animals in Sweden.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/I5442Q55W7YE6ZFFDBZIUBE7KM2ZNTM3/

Re: Fedora should replace mailing lists with Discourse

[Jeffrey Ollie]

On Wed, Oct 17, 2018 at 1:55 PM John Florian  wrote:
>
> How does Discourse handle posts you've already read in a thread that's still 
> active.  With things like reddit or LWN, you get to read it over and over and 
> over again if you really want to see whats new now.

Discourse handles this quite well actually, as long as you're logged
in. It will keep track of the last post you've seen as well as show
you counts of new messages in a particular thread. I wouldn't claim
that it's as good as an email client but it's much better than other
forums and comment sites.

-- 
Jeff Ollie
The majestik møøse is one of the mäni interesting furry animals in Sweden.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Tip for Reporting Spam on Mailing Lists

[Jeffrey Ollie]

Do not reply to or forward spam emails back to the mailing list. You just
became part of the problem and many/most spam scanning services now
consider YOUR email to be spam. Gmail in particular makes it very difficult
to manage the spam status of individual emails (seems like you can only
report/unreport whole conversations).

-- 
Jeff Ollie
The majestik møøse is one of the mäni interesting furry animals in Sweden.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: update Ceph to 12.1.1 in epel7 ?

[Jeffrey Ollie]

Building 12.1.1 for EPEL7 would be VERY bad IMNSHO.  0.80.7 _is_ seriously
out of date, but:

1) You can't upgrade directly from 0.80.7 to 12.1.1 without upgrading to at
least 0.94.X and then 10.2.X first, and there are probably other
intermediate steps as well (you'd have to dig through the release notes to
be sure).

http://docs.ceph.com/docs/master/release-notes/#upgrading-from-pre-jewel-releases-like-hammer
http://docs.ceph.com/docs/master/release-notes/#upgrading-from-infernalis-or-hammer
http://docs.ceph.com/docs/master/release-notes/#id598
http://docs.ceph.com/docs/master/release-notes/#upgrading-from-firefly

Upgrading a Ceph installation is a non-trivial affair. Depending on the
versions involved and the amount of data in your system it can take days
for even a small installation. There are also a number of prerequisites
that need to be checked before upgrading like the underlying filesystem
used, file ownership, config settings etc.

2) I suspect that most people that are running Ceph on a CentOS/RHEL system
have switched to using the repos provided by Ceph at download.ceph.com. The
primary advantage of the upstream Ceph repos is that you can pin your
system to a specific release train. I personally am using Jewel currently,
but Ceph maintains repos for many different release trains.

I'm sure that I wouldn't be the only person that would be incredibly
annoyed if a "yum upgrade" upgraded Ceph to Luminous before I was ready.
For one thing, 12.1.1 is considered a release candidate by Ceph. I'm not
upgrading my Ceph cluster until at least 12.2.0 (which is going to be the
stable release) and likely will wait until 12.2.1. I'm also going to wait
until I'm good and ready. Since major operations can take days (literally),
I'm not going to do the upgrade just before I leave town for the weekend
for example.

Using the upstream Ceph repos means that I can switch from Jewel to
Luminous when I'm ready and still get upgrades for the kernel etc. without
a lot of bother.

3) Personally I think that the Ceph packages should just be deprecated from
the EPEL repo. Without the ability to provide packages for multiple release
trains theres no sane way to allow the end user to stay on a specific
release train until they are ready to upgrade, rather than when the package
manager decides to upgrade.

On Tue, Aug 1, 2017 at 10:09 AM, Kaleb S. KEITHLEY 
wrote:

>
> The last version of Ceph that was built in epel7 was 0.80.7, back in
> December, 2016.
>
> That's pretty seriously out of date.
>
> Is anyone going to have any heartache if I build 12.1.1 for epel7?
>
> --
>
> Kaleb
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
>



-- 
Jeff Ollie
The majestik møøse is one of the mäni interesting furry animals in Sweden.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org