Re: Could someone help me with writing polkit rule?

[tim.laurid...@gmail.com]

It is some time ago it was fighting with polkit, but as far is  I remember
you have to
make a .policy file to get pkexec to work right

Like this one I use in yumex.
https://github.com/timlau/yumex/blob/master/misc/dk.yumex.backend.policy.in

It should be installed in /usr/share/polkit-1/actions/

When you can make a rule to bypass the polkit password prompt

Tim

PS.

You can use *cat /var/log/secure | grep polkit * to look for errors


On Fri, Oct 25, 2013 at 11:22 AM, Peter Lemenkov  wrote:

> Hello All!
>
> I 'm trying to write a polkit rule which allows every member of a
> particular group ("ejabberd") to run a specific script
> ("/sbin/ejabberdctl" or "/usr/sbin/ejabberdctl"). Other users should
> not be even able to run it. This sounds simple, so I quickly wrote
> this:
>
> http://peter.fedorapeople.org/stuff/ejabberdctl.polkit.rules
>
> I installed it to %{_datadir}/polkit-1/rules.d/51-ejabberdctl.rules,
> and added /usr/bin/ejabberdctl which contains just the following:
>
> ===
> #!/bin/sh
> /usr/bin/pkexec /usr/sbin/ejabberdctl "$@"
> ===
>
> So when user types ejabberdctl it actually runs /usr/sbin/ejabberdctl
> under the polkit supervision. Unfortunately people started reporting
> about the issues with the other apps:
>
> * https://bugzilla.redhat.com/show_bug.cgi?id=1009408
>
> I can't find what's wrong with the rule above so I'm calling you for
> help. Could please someone help me fixing this mess?
> --
> With best regards, Peter Lemenkov.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
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: pycairo

[tim.laurid...@gmail.com]

python3-cairo is a separate package, it contains the latest upstream
release 1.10.0
but it looks like the License is wrong in the .spec (License: MPLv1.1 or
LGPLv2)
https://apps.fedoraproject.org/packages/python3-cairo/sources/spec/


pycairo is licensed under the GNU Lesser General Public License (LGPL)
version 3.

So it should be good, no new review needed.

Tim






On Thu, Oct 24, 2013 at 2:18 AM, Christopher Meng wrote:

>
> On Oct 24, 2013 1:26 AM, "Kevin Fenzi"  wrote:
> > Right. So, I would suggest:
> >
> > Since the rename review is stalled, someone update and submit a new
> > rename review (closing the old one as a duplicate) then get it
> > reviewed.
> >
> > The only slight wrinkle in this is the folks who have commit on pycairo
> > might also want such on the new python-cairo, as long as whoever
> > submits the new rename review is ok with adding any of them that want
> > it, I don't see an issue.
>
> I hope one of these people(also in python3-cairo) can submit a new review
> request.
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
-- 
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 : yumdaemon - DBus API for yum

[tim.laurid...@gmail.com]

Thanks



On Wed, Oct 23, 2013 at 5:58 PM, Jerry James  wrote:

> On Wed, Oct 23, 2013 at 3:05 AM, tim.laurid...@gmail.com
>  wrote:
> > I have made the first public release of yumdaemon a DBUS API for yum with
> > python 2 & 3 client bindings
> > It can be helpful for applications moving to python 3 but need to
> performing
> > yum actions.
> > future plans is to make the API work with dnf when there is an api to
> work
> > with.
> >
> > API Docs : http://timlau.fedorapeople.org/yumdaemon/
> >
> > If someone will help reviewing, so I can get the package into fedora.
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1022407
> >
> > Tim
>
> I'll take it.  Can you review one of these?
>
> 1) irstlm: statistical language model tool
> https://bugzilla.redhat.com/show_bug.cgi?id=1003057
>
> 2) lexertl: modular lexical analyzer generator
> https://bugzilla.redhat.com/show_bug.cgi?id=1021017
>
> Thanks!
> --
> Jerry James
> http://www.jamezone.org/
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Review Swap : yumdaemon - DBus API for yum

[tim.laurid...@gmail.com]

I have made the first public release of yumdaemon a DBUS API for yum with
python 2 & 3 client bindings
It can be helpful for applications moving to python 3 but need to
performing yum actions.
future plans is to make the API work with dnf when there is an api to work
with.

API Docs : http://timlau.fedorapeople.org/yumdaemon/

If someone will help reviewing, so I can get the package into fedora.

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

Tim
-- 
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/F22 System Wide Change: Python 3 as the Default Implementation

[tim.laurid...@gmail.com]

You can use GDbus as a replacement for python-dbus

You can see how I have done it in the yumdaemon python api.
https://github.com/timlau/yum-daemon/blob/master/client/yumdaemon/__init__.py

Same code is working unchanged in python 2 & 3

Tim


On Tue, Oct 22, 2013 at 2:22 PM, Daniel J Walsh  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/17/2013 11:45 AM, Miloslav Trmač wrote:
> > On Thu, Oct 17, 2013 at 9:13 AM, Bohuslav Kabrda 
> > wrote:
> >>> * The Change plan should be updated to take into account Dennis's
> >>> Feedback * I suggeested that perhaps a better contingency plan would be
> >>> to simply ship with some applications using python2 and others using
> >>> python3.
> >>>
> >>
> >> Personally I don't have problem with this, but: - Side tag is a good
> >> contingency plan. If we have to revert for whatever reason, then without
> >> sidetag we will have to rebuild everything with Python 2 again.
> >
> > Yes.  In general it would be great to start frequently making disruptive
> > changes on branches to not disrupt other people, and this is a very big
> > change where at least having the option is very much warranted Mirek
> >
> Began working on porting all of the SELinux python code to python3.  I
> plan on
> shipping bindings for both 2 and 3, but tools are hung up on missing yum
> and
> dbus python3 bindings.
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlJmbgUACgkQrlYvE4MpobMUygCdFFfP2E4luT6+U1+y6sOdglWe
> gK4AoMNhuRj8sB0ZuFvUD8nn3CZPDKqH
> =4pTR
> -END PGP SIGNATURE-
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
-- 
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: PyQt5 in Fedora

[tim.laurid...@gmail.com]

Thanks Rex
Let me know if you need help  for package reviews
I will be glad to help

Tim


On Fri, Oct 18, 2013 at 3:38 PM, Rex Dieter  wrote:

> tim.laurid...@gmail.com wrote:
>
> > Is there some reason that PyQt5 is not in Fedora or has it just not been
> > packaged yet ?
>
> The latter.
>
> For me personally, I've been prioritizing getting all qt5-related modules
> packaged first (still have 2-3 to go).
>
> -- Rex
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

PyQt5 in Fedora

[tim.laurid...@gmail.com]

Is there some reason that PyQt5 is not in Fedora or has it just not been
packaged yet ?

Tim
-- 
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/F22 System Wide Change: Python 3 as the Default Implementation

[tim.laurid...@gmail.com]

Is DNF ready for prime time, the is no API at the moment, so it is not
possible to convert tool using the yum api to use a DNF api
I am working on a Python 3 version af yumex, there is package manager for
the XFCE spin, I have isolated all the yum actions in DBUS services, but
they will require yum and python2
until DNF has a usable API to do the same.

Tim


On Wed, Oct 9, 2013 at 4:31 PM, Dennis Gilmore  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Wed, 09 Oct 2013 14:07:12 +0200
> Jaroslav Reznik  wrote:
>
> > ** Request Koji side tag and encourage packagers to rebuilt their
> > packages with Python 3 there
> python is not in the minimal build root python-libs is pulled in by
> deps.
>
> So all the koji parts of the change proposal are irrelevant
>
> Dennis
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.21 (GNU/Linux)
>
> iEYEARECAAYFAlJVaOEACgkQkSxm47BaWffHvACfY9Iwxin2/NgmsSh7/ZMz6nAa
> jZcAnAqDP9BdIBst6A2t3FTDEsYzbMOQ
> =e62K
> -END PGP SIGNATURE-
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
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: python-urlgrabber, yum: blatant disregard for packaging guidelines and common sense

[tim.laurid...@gmail.com]

the original urlgrabber maintainer left long time ago, but the yum team
adopted the code, because it was critical to yum, so this is cause why
there has been no upstream release.
yum shold make upstream releases in more frequently, instead of adding very
large patches to latest git HEAD.
yum-utils releases was made by me, but I have not had so much time to spend
on yum-utils, so there has not been any releases for a long time.

dnf is not in a state to replace yum yet, and it will take awhile to get
there, a lot of tool uses yum api and dnf has no stable api yet, so yum
will properly stay here for years to come
so there is no excuses to not make upstream releases more frequent :)

Tim



On Wed, Oct 9, 2013 at 9:14 AM, Jan Zelený  wrote:

> On 8. 10. 2013 at 19:06:21, Stanislav Ochotnicky wrote:
> > I was looking for examples of nice packages for upcoming packaging
> workshop
> > we are doing in Brno. I made the terrible mistake of doing fedpkg clone
> > python-urlgrabber.
> >
> > If there was some normal packaging issue I'd most likely just file a bug
> in
> > bugzilla, but this made my blood boil. This is one of our core
> components!
> >
> > snippet from spec:
> > Source0: urlgrabber-%{version}.tar.gz
> > Patch1: urlgrabber-HEAD.patch
> >
> > Guess what? The patch is 100k big. The tarball is actually smaller! Of
> > course the package does not even follow post-release versioning
> > guidelines[1]. The only good thing is that the tarball sha actually
> matches
> > upstream released version from 2009.
> >
> > Now I *get* that yum uses new features of urlgrabber. But package
> maintainer
> > is also upstream developer. Just do the damn release ffs! Oh fun fact:
> yum
> > is actually in the same boat.
>
> A sad remain from times long gone. Yum and related components don't do
> upstream releases, I'm not sure why besides historical reasons (James might
> know a bit more on this one). However fixing this now would be like fixing
> a
> sail on a boat that has a hole in the trunk.
>
> Yum is not going to be in Fedora for much longer and starting releases in
> upstream about a year before dnf takes over makes only a little sense to
> me.
>
> Jan
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
-- 
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-0.4.2 released

[tim.laurid...@gmail.com]

Hi Ales

How is the state of the Python API, I want to make a DBus API around it to
use with the nextgen Yumex
Like the one i have made for yum[1]

[1] : https://github.com/timlau/yum-daemon

Tim





On Tue, Oct 1, 2013 at 5:02 PM, Ales Kozumplik  wrote:

> Hello,
>
> dnf-0.4.2 was released in Fedora 20[1] and Fedora Rawhide today.
>
> The highlights of the release are parallel downloads, detecting the
> fastest mirrors for downloads, support for repo.cost config option (which
> all has been in Yum for a long time and we are adding it to DNF again now)
> and losing the urlgrabber dependency. See the full release notes on the
> documentation page.[2]
>
> We also started a blog about DNF:
>
>   dnf.baseurl.org
>
> At the current time it pretty much contains only the release announcements
> same as the ones I sent to the lists. Lot more to come.
>
> Ales
>
> [1] http://bit.ly/1c0zK0n
> [2] 
> http://akozumpl.github.io/dnf/**release_notes.html#id13
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.**org/mailman/listinfo/devel
> Fedora Code of Conduct: 
> http://fedoraproject.org/code-**of-conduct
-- 
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: The final push for the application installer in Fedora 20

[tim.laurid...@gmail.com]

AppData is focusing alot about application, what about content : icons,
themes, backgrounds

Tim


On Mon, Sep 30, 2013 at 1:00 PM, Michael Schwendt wrote:

> On Fri, 27 Sep 2013 11:24:45 +0100, Richard Hughes wrote:
>
> > In GNOME Software, we show a list of applications for each category
> > that we think are frikin’ awesome. Some have AppData[1], and some
> > don’t. For the ones that don’t yet have AppData it leaves the
> > responsibility of writing the long description to the Linux community,
> > where we can push the data back to upstream so that all the
> > distributions can benefit. So far we’ve had a superb reaction from
> > lots of upstream projects and a lot of descriptions have been merged.
>
> Could you highlight how much of a "cross-distro effort" this really is?
> Audacious upstream has asked whether the AppData file would only be used
> by Fedora? Writing a simple file and including it in the Fedora rpms is
> easy, but it would look more beautiful with an official screenshot and
> an official updatecontact address.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
-- 
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: The final push for the application installer in Fedora 20

[tim.laurid...@gmail.com]

vlc is not part of fedora, cause of patent related stuff, not a legal
expert, but I dont think fedora cant contain somethng there links to these
kind of applications

If you create a new kind of application metadata, would it not be a good
idea to start using the information we allready have in the .spec files and
build from that
instead of starting from scratch, it is better than no information at all

Tim


On Fri, Sep 27, 2013 at 12:24 PM, Richard Hughes wrote:

> In GNOME Software, we show a list of applications for each category
> that we think are frikin’ awesome. Some have AppData[1], and some
> don’t. For the ones that don’t yet have AppData it leaves the
> responsibility of writing the long description to the Linux community,
> where we can push the data back to upstream so that all the
> distributions can benefit. So far we’ve had a superb reaction from
> lots of upstream projects and a lot of descriptions have been merged.
>
> For Fedora 20 we want all the awesome apps to have AppData, so users
> can evaluate the application before installing it. It would add a
> really nice bit of polish to the whole experience. If you can spare 5
> minutes and want to help.
>
> I’ve got another shared document that just needs a few details for
> each application:
>
> https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdElaYUoxcXRxeVRVS05Femg4Zzk2NWc#gid=0
>
> The list of awesome-but-unloved apps is: audacity, ardour2,
> gnome-banshee, rosegarden, sound-juicer, doom, openarena, xonotic,
> tremulous, btanks, frozen-bubble, quadrapassel, neverball, gnomine,
> wesnoth, supertuxkart, redeclipse, lyx, gparted, virt-manager,
> eclipse, gitg, monodevelop, blender, shotwell, octave, saoimage,
> workrave, celestia, polari, pidgin, chromium, pitivi, vlc and
> openshot.
>
> If you want to add any other apps there, please feel free, although I
> would much prefer the AppData file to go upstream if you’re a
> contributor or maintainer of a project. Remember, we can’t feature
> applications on the front page that don’t have AppData, so that’s an
> added incentive. I’d love to expose more people to blender for
> instance.
>
> There’s no way I can do all this myself for Fedora 20, so I really
> need your help. Again. Thanks.
>
> Richard
>
> [1] http://people.freedesktop.org/~hughsient/appdata/
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
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: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

[tim.laurid...@gmail.com]

On Tue, Nov 20, 2012 at 9:06 PM, Adam Williamson wrote:

> I was kinda hoping to just let that die a quiet death, but since this
> thread has been thoroughly revived - I would've worded it differently if
> I'd thought about it at all, and I'm sorry for that, it was a silly way
> to put things. That thread was getting ridiculous and I was badly
> stressed out from Beta work. Sorry to anyone who was offended by what I
> wrote for any reason. I was really just trying to draw a humorous
> comparison between fedora-devel circa 2003 and fedora-devel now (it
> really was uncanny how similar the two threads were), but it got a bit
> negative. Sorry about that.
>

Adam, thank for your great work at Fedora QA, They is a lot of negativity
on this list
and it is not very helpful or constructive.

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

Re: PKLA --> JavaScript

[tim.laurid...@gmail.com]

On Thu, Nov 15, 2012 at 5:37 PM, Ian Pilcher  wrote:

> I've just reviewed those pages, and it's certainly not obvious to me
> how I would go about "porting" a PKLA file.
>
>   [libvirt Management Access]
>   Identity=unix-group:wheel
>   Action=org.libvirt.unix.manage
>   ResultAny=no
>   ResultInactive=no
>   ResultActive=yes
>
> The latter page, in particular, reads like something written for an
> audience of developers, rather than system administrators.  I'm sure
> that I can figure it out in time, but this seems like a terrible burden
> to put on system administrators, particularly those who are (sometimes
> proudly) averse to anything that smacks of "programming".
>


the .rules file should look like this: and go into *
/usr/share/polkit-1/rules.d/ *

polkit.addRule(function(action, subject) {
if (action.id == "org.libvirt.unix.manage" &&
subject.isInGroup("wheel")) {
return polkit.Result.YES;;
}
});
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: remove polkit from core?

[tim.laurid...@gmail.com]

On Wed, Nov 14, 2012 at 6:53 AM, Ian Pilcher  wrote:

> On 11/13/2012 09:50 PM, Matthias Clasen wrote:
> >
> > Yes, this was a misunderstanding. What is still supported is the .policy
> files containing the default policy. And that is very good, since such
> policy files are installed by pretty much every package that uses polkit,
> while .pkla files were only used by very few packages.
> >
>
> Wait.  So the .pkla file I wrote to allow my run virt-manager as my
> normal user is going to stop working, and I'm going to have to write the
> replacement in JavaScript?
>
> Let's just say I'm struggling to find the words ...
>


In F18 yes.

http://davidz25.blogspot.dk/2012/06/authorization-rules-in-polkit.html
http://www.freedesktop.org/software/polkit/docs/master/polkit.8.html

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

Re: A minimal subset of python (was Re: [@core] working definition for the minimal package set)

[tim.laurid...@gmail.com]

Did a quick scan and removed internals

random   : ['import random : (cli.py)']
subprocess   : ['from subprocess import Popen, PIPE :
(yum/packages.py)']
gettext  : ['import gettext : (output.py)']
fnmatch  : ['import fnmatch : (completion-helper.py)']
tempfile : ['import tempfile : (yum/misc.py)']
base64   : ['import base64 : (yum/misc.py)']
imp  : ['import imp : (yum/plugins.py)']
logging.config   : ['import logging.config : (yum/__init__.py)']
string   : ['import string : (yum/__init__.py)']
textwrap : ['from textwrap import fill : (yum/plugins.py)']
urlgrabber.grabber   : ['from urlgrabber.grabber import URLGrabError :
(output.py)']
iniparse.compat  : ['from iniparse.compat import NoSectionError,
NoOptionError, ParsingError : (yum/config.py)']
ConfigParser : ['from ConfigParser import ConfigParser,
ParsingError : (yum-updatesd.py)']
cmd  : ['import cmd : (shell.py)']
uuid : ['from uuid import uuid4 : (yum/misc.py)']
logging.handlers : ['import logging.handlers : (yum/logginglevels.py)']
threading: ['import threading : (yum-updatesd.py)']
shlex: ['import shlex : (completion-helper.py)']
signal   : ['import signal : (cli.py)']
cStringIO: ['from cStringIO import StringIO :
(yum/mdparser.py)']
locale   : ['import locale : (output.py)']
xml.sax.saxutils : ['import xml.sax.saxutils : (yum/misc.py)']
lzma : ['import lzma : (yum/misc.py)']
sha  : ['import sha : (yum/misc.py)']
urllib   : ['import urllib : (yum/misc.py)']
re   : ['import re # For YumTerm : (output.py)']
gpgme: ['import gpgme : (yum/misc.py)']
fcntl: ['import fcntl : (yum/rpmtrans.py)']
optparse : ['from optparse import OptionParser :
(yum-updatesd.py)']
xml.etree: ['from xml.etree import cElementTree :
(yum/mdparser.py)']
struct   : ['import struct : (yum/packages.py)']
logging  : ['import logging : (output.py)']
socket   : ['import socket : (yum/logginglevels.py)']
weakref  : ['from weakref import proxy as weakref :
(output.py)']
sqlitecachec : ['import sqlitecachec : (yum/yumRepo.py)']
os   : ['import os : (yum-updatesd.py)']
pdb  : ['import pdb : (yummain.py)']
struct, time, cStringIO, base64, types
curses   : ['import curses : (output.py)']
__builtin__  : ['import __builtin__ : (shell.py)']
operator : ['import operator : (yumcommands.py)']
rpm  : ['import rpm : (output.py)']
errno: ['import errno : (yummain.py)']
binascii : ['import binascii : (yum/misc.py)']
types: ['import types : (output.py)']
md5  : ['import md5 : (yum/misc.py)']
pwd  : ['import pwd : (output.py)']
gpgme.editutil   : ['import gpgme.editutil : (yum/misc.py)']
copy : ['import copy : (yum/config.py)']
hashlib  : ['import hashlib : (yum/misc.py)']
atexit   : ['import atexit : (yum/plugins.py)']
StringIO : ['import StringIO : (yum/__init__.py)']
exceptions   : ['import exceptions : (utils.py)']
sqlutils : ['from sqlutils import sqlite, executeSQL, sql_esc :
(yum/pkgtag_db.py)']
urlgrabber   : ['import urlgrabber : (yum/__init__.py)']
sqlite   : ['import sqlite : (yum/sqlutils.py)']
urlgrabber.progress  : ['from urlgrabber.progress import TextMeter,
TextMultiFileMeter : (output.py)']
shutil   : ['import shutil : (yum/misc.py)']
xattr: ['import xattr : (yum/packages.py)']
bz2  : ['import bz2 : (yum/misc.py)']
grp  : ['import grp : (yum/packages.py)']
sqlite3  : ['import sqlite3 as sqlite : (yum/sqlutils.py)']
stat : ['import stat : (yum/packages.py)']
warnings : ['import warnings : (yum/config.py)']
glob
urlgrabber.mirror: ['import urlgrabber.mirror : (yum/yumRepo.py)']
iniparse : ['from iniparse import INIConfig : (yum/config.py)']
sys  : ['import sys : (yum-updatesd.py)']
cElementTree : ['import cElementTree : (yum/mdparser.py)']
os.path  : ['import os.path : (yummain.py)']
urlparse : ['import urlparse : (yum/config.py)']

Tim


On Tue, Nov 13, 2012 at 5:09 PM, David Malcolm  wrote:

> On Mon, 2012-11-12 at 11:28 -0500, Matthew Miller wrote:
> > Okay, cool -- there's a lot of enthusiasm for a SIG for the core package
> > set.
> >
> > So, first up on the SIG goals: clarifying our target.
> >
> > It's been suggested before that there's so many possibilities that this
> is
> > useless, but the point here is to *pick* a reasonable choice as a group
> and
> > to work with that (e

Re: Unblocking packages: new review needed?

[tim.laurid...@gmail.com]

On Wed, Nov 7, 2012 at 10:07 AM, Alec Leamas  wrote:

> No top-posting in fedora-devel :)
>
>
Sorry :)


> Besides that, I can just agree with Tim. The oldest package was reviewed
> less than a year ago, the two others last summer. Requiring a new review
> is, well, somewhat formal.
>
> That said, it should be easy to review these to resolve this issue.  If
> you just make some new review requests, linking to the previous review I'll
> guess this could be handled without to much problems.
>

I don't see anywhere in http://fedoraproject.org/wiki/Package_Review_Process

That a new review is needed,

"Reviews are currently done for totally new packages, package
renames,
and packages merged from the old Fedora Core repository."

I don't see this case, fits any of the cases.

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

Re: Unblocking packages: new review needed?

[tim.laurid...@gmail.com]

Sound very strange, it is not some kind orphan package, there have been out
of Fedora and has to re-enter.
It it an active maintained package in F17, there just have not worked with
latest version for gnome-shell, because they change the way themes works in
every release.
It a waste of reviewers time to have to review such a package again IMHO.

Tim


On Wed, Nov 7, 2012 at 2:57 PM, M.M.  wrote:

> I have requested Release Engineering to unblock some packages,
> which previously had been blocked on some branches:
> https://fedorahosted.org/rel-eng/ticket/5387
> I have been told that those packages must be reviewed again in order to be
> unblocked.
> I'm not 100% sure of what to do. Do I have to open a new review request
> on Bugzilla for each package "from scratch" (i.e., exactly as if they were
> completely new)?
> Are there any further steps I must take?
> Thank you in advance.
> M.M.
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[tim.laurid...@gmail.com]

On Tue, Oct 30, 2012 at 10:58 PM, David Airlie  wrote:

>
>
> - Original Message -
> > From: "Richard Hughes" 
> > To: "Development discussions related to Fedora" <
> devel@lists.fedoraproject.org>
> > Sent: Wednesday, 31 October, 2012 6:35:14 AM
> > Subject: Re: Anaconda is totally trashing the F18 schedule (was Re: f18:
> how  to install into a LVM partitions (or
> > RAID))
> >
> > On 30 October 2012 18:45, Adam Williamson 
> > wrote:
> > > so if were to try and switch back to oldui at
> > > this point, we'd have to go through the whole process of adjusting
> > > the
> > > code for the changes to dracut again, quite apart from any other
> > > issues.
> >
> > I don't understand how fixing up the old anaconda with the dracut
> > changes would be so difficult. More than 140 man-hours? It's surely
> > going to be a lot less work than getting anaconda to a point where it
> > actually works with a consistent UI. Anaconda isn't the kind of thing
> > we can fix with a zero day update, and surely it should have been
> > developed in parallel with a release and then "switched on" just
> > after
> > branching rather than the situation we have now where there is major
> > design and development work being done *so close* to where we should
> > have everything locked down tight.
> >
> > I really don't see why the Anaconda team should be treated so
> > differently from every other team. If we ship anything close to the
> > Anaconda we've got now then F18 is going to get ripped apart by the
> > reviewers.
>
> Should we just skip F18? (like seriously).
>
> Dave.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>


Or just push the release by 1-2 months, So there is time to beat anaconda
into shape, going back to oldui will not be very productive, then we will
have the same problems in F19

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

Re: [SOLVED] kernel 2.6.x and Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller (kmod-wl)

[tim.laurid...@gmail.com]

On Tue, Oct 23, 2012 at 5:41 AM, Dario Lesca  wrote:

> On this Asus EeePC seashell series Notebook:
> http://www.smolts.org/client/show/pub_e9f34fbb-dd9d-4b7d-8c77-027292c81297
>
> After kernel update to 3.6.[12] (plus relative kmod-wl* module) the WiFi
> stop work
>
> I have found this article:
> https://bbs.archlinux.org/viewtopic.php?pid=1176829
>
> then I have install the akmod driver and I have apply to .spec file this
> patch:
>
> > [root@ludvic ~]# diff -Naur rpmbuild/SPECS/wl-kmod.spec.orig
> rpmbuild/SPECS/wl-kmod.spec
> > --- rpmbuild/SPECS/wl-kmod.spec.orig2012-10-22 22:57:55.284478328
> +0200
> > +++ rpmbuild/SPECS/wl-kmod.spec 2012-10-22 22:32:17.134583423 +0200
> > @@ -69,7 +69,7 @@
> >  %build
> >  for kernel_version in %{?kernel_versions}; do
> >   pushd _kmod_build_${kernel_version%%___*}
> > - make -C ${kernel_version##*___} M=`pwd` modules
> > + make -C ${kernel_version##*___} M=`pwd` modules API=WEXT
> >   popd
> >  done
>
> Rebuild with "rpmbuild -ba rpmbuild/SPECS/wl-kmod.spec", remove old
> module "rmmod wl", uninstall and reinstall new RPMS generated, reload
> module "modprobe wl", and test it:
>
> Now WiFi work
>
> Hope this help
>
> Many thanks
>
> --
> Dario Lesca - sip:da...@solinos.it
> (Inviato dal mio Linux Fedora 17 Gnome3)
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel


my laptop has

03:00.0 Network controller: Broadcom Corporation BCM4313 802.11b/g/n
Wireless LAN Controller (rev 01)

and it works great with the 3.6.x kernel in F18 out of the box, in earlier
releases I had to use the kmod-wl driver.

Have you tried to remove all the wl stuff and see if it work without, if
you have kmod-wl installed it will black list the kernel buildin BCM4313
drivers.

You can also try to boot an F18 Live cd to check if it works. in tree
drivers is preferred over out of tree ones :)

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

Re: [Feature Suggestion] UsrMove continued

[tim.laurid...@gmail.com]

On Tue, Oct 9, 2012 at 9:40 AM, Richard W.M. Jones wrote:

> So you make your system incompatible with every other Linux distro out
> there, and with all existing documentation, but to what end? Tidyness?
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones
> New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
> programs, test, and build Windows installers. Over 70 libraries supprt'd
> http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>

+1 to Richard, I really don't see the purpose, why does it matter that
number of dirs in /.
Lot of apps will break if you move /proc or /dev, and if you replace them
with symlink in the next 10 years you still have the same number of dirs
under /, you have even more because you have added some new ones.
I can understand you want to merge dirs there have the same function /bin
-> /usr/bin, but this has no benefits at all.

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

Re: Any progress in Software Center in Fedora effort?

[tim.laurid...@gmail.com]

On Fri, Oct 5, 2012 at 5:19 PM, Jiri Eischmann  wrote:

> Hi,
> the possibility of Software Center in Fedora has already been discussed
> several times, last time a few month ago.
> I read an article about a successful Google Summer of Code project [1]
> whose goal was to make Software Center a distribution independent
> program using PackageKit.
> Matthias even made an Ubuntu-independent infrastructure for AppStream
> (additional data about packages/apps).
> I wonder if there are still any efforts to get it to Fedora and what it
> would require from our infrastructure.
>
> If I understand it correctly, there are currently three options:
> 1) Software Center based on PackageKit by Matthias
> 2) Light Software Center - a new app based on PackageKit from the
> beginning
> 3) Apper already supports AppStream [2]
>
> I'm asking because I hear from many (not only) beginners that they would
> appreciate something like Ubuntu Software Center in Fedora. I guess it's
> one of the main reasons why many users rather go for Ubuntu than Fedora.
>
> Jiri
>
> [1] http://blog.tenstral.net/2012/08/gsoc-appstream-final-report.html
> [2] http://blog.tenstral.net/2012/08/appstream-for-apper.html
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel



The ultimate software center is a web application, like Google playstore.

All the rating and commenting and other info, need to be centrally
maintained and it is not a good idea to try to distribute this kind of
metadata.
There shall just be a local installer to install the packages triggered by
the web app.
Another thing is what the users of Fedora and most other linux'es is not my
old mother and most of these users, don't care about a big fancy software
shop.
So nobody is going to do this great amount of work it takes to make a great
webstore, Ubuntu need it for the same ways as Apple, they want to earn some
money.
It is an illusion that if we just have a fancy webstore, every body will
start using Fedora IMHO.
It will be nice if more people uses Fedora, but it not the main target, the
greatness of Fedora is not measured but how many user it have, compared to
other Linuxes or other os'es.

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

Re: Building packages for EPEL6 when Fedora moved to systemd

[tim.laurid...@gmail.com]

On Fri, Sep 14, 2012 at 1:29 PM, Henrique Junior wrote:

> Currently several packages in epel6 are facing the problem that Fedora is
> now systemd based and therefore many RPMs can not be created for EL6 and
> EL5.
> Can a maintainer use, lets say, two spec files (one for Fedora and another
> for EL) or the correct approach in this case is the use of IFs during the
> creation of the spec?
>
> --
> Henrique "LonelySpooky" Junior
> http://about.me/henriquejunior
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>

The fedora build setup has git branches for each release EL-5, EL-6, F17,
F19, Master, so there is no problem to have different .SPEC files for each
branch

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

Re: Subject: Re: Mate-Desktop

[tim.laurid...@gmail.com]

On Fri, Aug 24, 2012 at 11:04 PM, Rave it  wrote:

> >
> > Rex Dieter wrote:
> >
> > I can understand your frustration, and that you and Dan had trouble
> > communicating and working together.
> >
> > I do wish to thank you for the positive contributions you made, and in
> > your future endeavors.
> >
> > -- rex
> >
> No mercy, no thanks.
>
> Why do you Mr. Rex Dieter as sponsor accept rude speaking,  and racist
> remarks from Dan Marchal?
>
> 'Portuguese n00b'
> https://github.com/mate-desktop/mate-doc-utils/issues/3
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel


I have seen a lot in unfriendly talk on my time as a fedora packager, but
this really takes the Oscar.
It is a disgrace for the Fedora project when a Fedora packager behaves in
this way against an upstream project.

ketheriel : We would rather like patches ;)

dmashal : So write one. That's your job. Not mine. Sorry.Dan

ketheriel Nice attitude dude. If I recall correctly you called me a
'Portuguese n00b' and mocked on my face the other day... So I guess I'm
have all the motivations to fix those issues :)

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

Re: avant-window-navigator (awn) in Fedora 17

[tim.laurid...@gmail.com]

On Thu, Jul 26, 2012 at 12:11 PM, Damian Ivanov wrote:

> Hello all,
>
> awn has been orphaned in F17 because latest bzr fails to build
> (0.4.1-XXX), though latest stable (0.4.0) builds fine. see
>
> https://build.opensuse.org/package/show?package=avant-window-navigator&project=home%3Adamianator%3Afedora


I have orhaned awn, because it was a pain to maintain and upstream is
almost stalled
especially the awn applets was hard, as they is made for gnome-2.x and hard
to get working with gnome-3.x .
And without the applets awn is not very fun.
and with a stalled upstream, it is very hard to fit into a fast moving
distro like Fedora.

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

Re: DNF Any testing time-frame?

[tim.laurid...@gmail.com]

Would it not be better to work with yum upstream to make the current yum
depsolver more modular so you could plugin another libsolv based depsolver,
instead of making a fork of yum and starts trashing the current API. There
is a lot more to yum, that just solving dependencies. And making a fork
there is not fully compatible will put a lot of work on your shoulders :)
without the benefit on the work done by yum upstream :) like parallel
download etc.

Tim

On Tue, Jun 19, 2012 at 6:05 PM, Ales Kozumplik  wrote:

> On 06/19/2012 03:50 PM, Frank Murphy wrote:
>
>> Current status
>>
>> Targeted release: Fedora 18
>> Last updated: 2012-6-19
>> Percentage of completion: 40%
>>
>> When would it hit rawhide, ballpark?
>>
>
> I can't give a date yet, but following the FESCo approval of the feature I
> made review requests today:
>
> https://bugzilla.redhat.com/**show_bug.cgi?id=833462
> https://bugzilla.redhat.com/**show_bug.cgi?id=833511
>
> Just don't hold your fingers crossed that anyone can use this to replace
> yum with. Not only that a subset of the full yum functionality is supported
> (see the thread about 'yum history'), but the plugins API etc. is not ready
> either.
>
> ATM it is just what it is: an experimental fork of Yum using libsolv
> inside.
>
> Ales
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.**org/mailman/listinfo/devel
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ARM is a dead end

[tim.laurid...@gmail.com]

On Fri, Jun 15, 2012 at 9:15 AM, drago01  wrote:

> On Fri, Jun 15, 2012 at 6:42 AM, tim.laurid...@gmail.com
>  wrote:
> >
> > [...]
> >
> > Linux is about choices
>
> No it isn't:
> http://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html
>
> (I do disagree with Kevin though).
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>

Choices have consequences, who have to live with, so having choices it not
the same as you can get everything you want :)

If people choose to spend time to build Fedora on a arch and getting the
work done, it is not up to me to judge there work to be a waste of time,
because I don't care about this arch.

Fedora is made by contributors and they decide what they want to spend
there time on, but they don't decide what other contributor will spend
there time on.

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

Re: ARM is a dead end

[tim.laurid...@gmail.com]

On Fri, Jun 15, 2012 at 1:57 AM, Kevin Kofler wrote:

> Hi,
>
> I've been pointed to a news item about a (apparently the first) x86 (Atom)
> based smartphone:
> http://www.engadget.com/2012/06/14/orange-san-diego-review/
>
> So even smartphones are going x86 now. It looks like x86 is going to defeat
> ARM just like it defeated all the previous attempts at changing the
> instruction set, even Intel's own IA-64. The fastest x86 CPUs are still
> worlds faster than the fastest ARM CPUs. This new smartphone's single-core
> Atom is competitive in speed with other smartphones' multi-core ARMs.
>
> So I would urge Fedora not to waste our time on a low-end architecture
> filling a temporary niche which will become obsolete as demand for
> performance increases. We should rather support only one primary
> architecture (x86, i.e.: x86_64, and legacy i686 as long as there's a need
> for it) and support it well, as we have done since we finally got rid of
> the
> legacy PPC burden. Niche architectures are exactly what secondary
> architectures are for.
>
>Kevin Kofler
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel



Why do we waste time on Linux, when we all just can use Windows, the
desktop market leader 


Linux is about choices and is driven by people by by people with passions
for something, even if not what every body else think is importent.
So telling people to don't waste time on something they care about, Is
wrong in so many ways.

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

Orphan: avant-windows-navigator and friends

[tim.laurid...@gmail.com]

With a little sadless I has to orhan avant-windows-navigator,
awn-extras-applet and libdesktop-agnostic for fedora-devel (fedora-17)

The avant-windows-navigator package don't build in rawhide because of
changes in latest version of vala
The awn-extras-applet has lot of problems with gnome 2.x dependencies there
no longer is in fedora, because of transition to gnome 3.

Upstream is moving very slow, so there is not much help there.

I will keep it for F16 & F15 until they are EOL.

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

Re: Package review SIG dead?

[tim.laurid...@gmail.com]

On Fri, Oct 7, 2011 at 8:39 PM, Adam Williamson  wrote:
> On Fri, 2011-10-07 at 17:49 +0530, Rahul Sundaram wrote:
>> On 10/07/2011 02:49 PM, Stanislav Ochotnicky wrote:
>>
>> > I know a lot of people wanted to have a discussion about this first,
>> > but since we had the opportunity to hack on this we did. I believe
>> > there are still many of us still interested, just not knowing what
>> > exactly we should do next.
>> >
>> > [1] https://github.com/timlau/FedoraReview
>> > [2] https://github.com/sochotnicky/FedoraReview/tree/lang-checks
>
>> This should be in the Fedora repository
>
> I hear they're having trouble getting the package reviewed 
> --

It is not the review there is the problem, it is these damn QA folks :)

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

Re: Package review SIG dead?

[tim.laurid...@gmail.com]

On Fri, Oct 7, 2011 at 11:19 AM, Stanislav Ochotnicky
 wrote:
> Excerpts from Richard Shaw's message of Thu Oct 06 22:17:51 +0200 2011:
>> After some initial interest there doesn't appear to be any activity
>> unless I'm missing something.
>>
>> I am still interested. Anyone else?
>
> Sorry for taking time to reply, but I had a bit too many things at
> once sprung up on me
>
> So...During FUDCon Milan a few of us decided to do a hackfest
> session on timlau's FedoraReview tool[1].
>
> It seemed like a good base for a review tool, the basic architecture
> seemed flexible enough etc. Our latest version is at github[2] as
> well. Changes from timalu's version:
>  * split checks based on them being general or specific to certain
>   language
>  * dynamic loading - every python file dropped in checks subdir is
>   considered a test module.
>  * fix several problems with running local checks without bug in
>   bugzilla
>  * Cleaups, pep8 applications
>
> It would be great to have a way so that everyone can implement checks
> in their language of choice, but for the time being we did this.
>
> Idea is to have each SIG maintain their own checks/templates together
> with their guidelines.
>
> I know a lot of people wanted to have a discussion about this first,
> but since we had the opportunity to hack on this we did. I believe
> there are still many of us still interested, just not knowing what
> exactly we should do next.
>
> [1] https://github.com/timlau/FedoraReview
> [2] https://github.com/sochotnicky/FedoraReview/tree/lang-checks
>
> --
> Stanislav Ochotnicky 
> Software Engineer - Base Operating Systems Brno
>
> PGP: 7B087241
> Red Hat Inc.                               http://cz.redhat.com
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>

Looks like very nice additions to my tool, I have not had to much time
to improve the tool lately.
If you like, I can give access to the original git repo or we can move
it to the fedora git, but github makes it easier to people to make
forks etc.


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

Re: Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes

[tim.laurid...@gmail.com]

>> * What if there are two layers of users that need to be rebuilt?
>>
>> The delays just pile one upon another...
>
> You can update rawhide at any time and accomplish that work without
> delays.  Then it shows up in the next Fedora version.
>

Yes, but then we have align the schedules, so have a new gnome release
in good time before a new fedora release tree is forked and when a new
Fedora GA is released, it will be close to the next Gnome release and
Fedora will not be the latest and greatest.
As an example i was hit by the latest gnome 3.2 pre-release in Rawhide
and F16 in awn-extras-applets, there contains a lot of applets to awn
written in C, Python & Vala with a lot of different requirements to
all kind of different gnome stuff (fx. gnome-menu 2.0) this was bumped
to 3.0 and some python binding disappeared. It will take me 2-3 weeks
before figure out how to work around the issues, remove stuff there
can't be fixed and get into updates-testing and to stable. Lucky for
me, nothing depends on awn-extras-applets, but users will have
problems updating to the new gnome packages without removing the
awn-extras-applets package.
This is not ideal between alpha and beta, but it the way things goes,
if we want to have the latest gnome close to the fedora release.

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

Re: how to have yum prefer one dependency over others

[tim.laurid...@gmail.com]

On Mon, Sep 19, 2011 at 1:00 PM, Kevin Kofler  wrote:
> Matthew Garrett wrote:
>> Debian policy is that any virtual dependencies must also have an
>> explicit dependency. In your case it would be something like
>>
>> Requires: phonon-backend-gstreamer | phonon-backend
>
> Unfortunately, RPM does not support this idiom.
>

Why don't you just replace rpm, with deb too, while you are at it ?

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

Re: Package Review Needed

[tim.laurid...@gmail.com]

On Fri, Jun 24, 2011 at 1:13 PM, He Rui  wrote:
> On Wed, 2011-06-22 at 12:00 +, devel-requ...@lists.fedoraproject.org
> wrote:
>> Date: Wed, 22 Jun 2011 11:15:15 +0800
>> From: He Rui 
>> Subject: Package Review Needed
>> To: devel 
>> Content-Type: text/plain; charset="UTF-8"
>>
>> Greetings!
>>
>>
>> Could someone please review the following ticket? I'll be happy to
>> swap
>> reviews.:)
>>
>> tinymce - Web based Javascript HTML WYSIWYG editor:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=608574
>>
>>
>> The Fedora QA team is interested in exploring nitrate to replace our
>> use
>> of wiki for managing test results from community test events, and
>> currently the Nitrate package is under reviewing[1], which however has
>> dependencies on the tinymce package. Thus it will be very appreciated
>> if
>> someone can offer help on it.
>>
>>
>>
>> Many thanks,
>> Hurry
>
>
> Please notice that I'm still in need of this review, This application is
> the text editor control integrated into the Nitrate TCMS system which
> will be adopted by Fedora qa.
>
> Please help!!
>
> --
> Contacts
>
> Hurry
> FAS Name: Rhe
> Timezone: UTC+8
> TEL: 86-010-62608141
> IRC nick: rhe #fedora-qa #fedora-zh
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>

I will review it .

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

Re: Proposal: retire bittorrent

[tim.laurid...@gmail.com]

On Wed, Jun 15, 2011 at 2:37 PM, Jon Ciesla  wrote:
> My only concern is that there be a command-line replacement available.  I
> currently fetch my ISOs with bittorrent-curses and screen.  Can someone
> with experience with any of them offer a recommendation?  Python, C and
> C++ clients especially.  I've searched, but there are many out there.
>

transmission-cli should do the job

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

Review Swaps

[tim.laurid...@gmail.com]

Hi

I have a number of packages under review, they should be very easy to review

712560 Review Request: gnome-shell-extension-theme-selector -
extension for review & change gnome-shell themes
712561 Review Request: gnome-shell-theme-atolm - the atolm gnome-shell theme
712562 Review Request: gnome-shell-theme-deviantart - the deviantart
gnome-shell theme
712563 Review Request: gnome-shell-theme-gaia - the gaia gnome-shell theme
712564 Review Request: gnome-shell-theme-orta - the orta gnome-shell theme
712565 Review Request: gnome-shell-theme-smooth-inset - the
smooth-inset gnome-shell theme
712566 Review Request: gnome-shell-theme-tron-legacy - the tron-legacy
gnome-shell theme
712567 Review Request: gnome-shell-theme-ubuntu-ambiance - the
ubuntu-ambiance gnome-shell theme
712662 Review Request: gnome-shell-extension-autohidetopbar - auto
hide topbar extension
712690 Review Request: gnome-shell-theme-dark-glass - Dark Glass
gnome-shell theme

So if you what to do some swapping, then let me know.

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

Re: F15 / VirtualBox

[tim.laurid...@gmail.com]

On Fri, Jun 10, 2011 at 12:37 AM, Dave Jones  wrote:

>
> Why are people choosing it over other solutions, and what can we change
> in qemu/kvm to get users using that instead ?
>
>
I use Virtualbox on a laptop with Fedora 14 as host OS, I use for building
and test installation of Windows application and for Running some windows
only application (Lotus Domino Designer and Administrator)

I use it for the following reasons:

   - The easy snapshot features, when doing a lot of package testing on
   Windows, I have to rollback to an earlier snapshot.
   - Local shared folders. to share files from Fedora host to windows
   client.
   - Nice GUI, Very easy to setup and manage new clients.
   - Save current state of guest, so I easy can switch clients with out
   having to close the the client OS down.
   - Running Windows application in a windows guest, runs very smooth, no
   delay in updating the GUI.

I have tried the same stuff on kvm about a year ago, it was
the possibility to share local host folders with the guests and when running
windows applications (ex. Lotus Domino Designer) there was a little delay
before the GUI was updated.

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

Re: Gnome Shell Extension manager/framework planned?

[tim.laurid...@gmail.com]

On Fri, Jun 3, 2011 at 7:01 PM, Michael Wiktowy
wrote:

> On Fri, Jun 3, 2011 at 12:35 PM, Colin Walters  wrote:
> >> If this is under way, could extension makers be pointed towards it to
> >> future-proof their extensions.
> >
> > I'm not sure what you mean by this.
>
> Searching around now, it looks like Looking Glass (alt+f2 "lg")
> already registers the extensions so maybe not much else needs to be
> done in the extensions to take advantage of future enhancements to
> extension management.
>
> Also, wrt. yum as the existing manager for now, is there some policy
> on one extension per package, package naming, configuration formats,
> etc.? Right now, a lot of extensions are only available via
> instructions to just git clone development trees right into your
> extension directories which is bypassing a lot of review, auditing,
> and sanity processes. Is there anyone shepherding these into sane and
> consistent rpm packages?
>
> /Mike
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>

The latest version of gnome-tweak-tool can enable/disable installed
extentions

http://timlau.fedorapeople.org/files/pics/tweek-tool.png

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

Re: Intent to package GNOME Shell frippery

[tim.laurid...@gmail.com]

On Wed, Jun 1, 2011 at 7:59 PM, Michael Cronenworth  wrote:

> Ron Yorston wrote:
> > I'd prefer them to be in one package: they are intended to work
> > together.
>
> Except the Shut Down menu extension directly conflicts with the
> alternative-status-menu extension. Sub-packages are the safest bet.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>

+1 for sub packages too.

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

Re: Suggests/Recommends proposal [Was: Re: PackageKit in Fedora 15 (beta)]

[tim.laurid...@gmail.com]

On Tue, Apr 26, 2011 at 8:55 PM, Matej Cepl  wrote:

> Dne 26.4.2011 18:23, Florian Festi napsal(a):
> > I think if anybody can come up with a exact description how they should
> > look like and how they should work and can create some evidence that
> > this is want we need and want implementing them is not the problem[*].
> > Until now no one has come up with a proposal and enough confidence.
>
> Well, I would for starters just take
> http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
> as a basis for the further refinement.
>
> == Recommends ==
>
> This declares a strong, but not absolute, dependency.
>
> The Recommends field should list packages that would be found together
> with this one in all but unusual installations.
>
> == Suggests ==
>
> This is used to declare that one package may be more useful with one or
> more others. Using this field tells the packaging system and the user
> that the listed packages are related to this one and can perhaps enhance
> its usefulness, but that installing this one without them is perfectly
> reasonable.
>
> -
>
> As an examples of Recommends I heard crond (or procmail) and
> /usr/sbin/sendmail ... strictly speaking crond (and procmail) work
> without sendmail, but almost never seen the former without the latter,
> and usually if you want that it is some very special case, where
> administrator knows what he is doing.
>
> On the other hand the case in the hand ... gnome-settings-daemon and
> packagekit (or phonon-gstreamer-backend and its packagekit plugin) would
> be Suggests — there are many real world scenarios where one could live
> without PackageKit, but there is no discussion that PK plugin (when it
> works, that is) could be very useful addition for totem or phonon.
>
> > As soon as one looks at the details it becomes less obvious what "we
> > really want". Even whether the Suggests/Recommends should live in the
> > packages or in comps or else where or both or both or in all three is
> > still under debate.
>
> IMHO, Suggests/Recommends should live in the spec file and be maintained
> by the package maintainers.
>
> > Do we need reverse relations? Do we really want to
> > have exactly two levels of strength? Do we need "conditionals" (install
> > an package only if two or more other packages are installed) as we had
> > (have) in comps? Or should be trash the whole concept of comps and comps
> > groups and start all over? When and how should they be evaluated? Do we
> > need to save the users decision not to want the suggested package? What
> > happens if the Suggests changes during an update?
>
> We can work on these more elaborate ideas later, but I think that the
> plain introduction of the Suggests/Recommends as outlined above
> (roughly, I guess there would be a lot of discussion about that even)
> would be nice starter for F16 (with a lot of bugs to discuss what level
> of dependency is required for each particular case). We can deal with
> the esoteric cases you suggest later.
>
> And specifically about comps ... no, I would leave them in cases where
> they are useful (i.e., roughly anywhere they don't do work of S/R
> dependencies). They are useful for suggesting grouping of packages and
> organization of installation models (i.e., definition of what's Desktop,
> what's KDE, etc.). And even then I don't think there is a need for any
> rush to replace comps any time soon ... the biggest value of
> Suggests/Recommends IMHO is the possibility to break unnecessary
> Requires which make these nonsensical situations (i.e., you need
> PackageKit in order to have gdm).
>
> > So I am not too optimistic that we'll have Suggests or
> > Recommends any time soon.
>
> As I said above I have been saying this for almost five years already.
> It took Cato the Elder fifty years, so I think I have still some way to
> go :)
>
> > [*] Depending on the exact features implementing still can be tricky and
> > require a lot of work. I doubt that it will be even remotely close to
> > half an hour but nothing that cannot be handled.
>
> Of course, I expect that it was half an hour used in a Pickwickian manner.
>
> Best,
>
> Matěj
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel


The hard part is to define what the package tools should do in the different
cases
A depsolver need to work with real requirements, so it need to be defined in
what cases that a soft requirement will become a real requirements to do the
right thing
And 2 kind of soft deps don't make it more simple.
There is lot of actions you can do in a yum transaction :
install,update,remove,downgrade,obsolete,reinstall and you can mix them in a
single transaction so it gets very complex.

Another issue is that  Suggests/Recommends is a parent -> child relations
When having a package there supports some kind of plugin infrastructure, you
have to add recommends for all p

Re: Acer Aspire One, Wifi, and Fedora 15

[tim.laurid...@gmail.com]

On Mon, Apr 18, 2011 at 12:58 AM, Matthew Garrett wrote:

> On Sat, Apr 16, 2011 at 03:10:01PM -0400, Eric Mesa wrote:
>
> >I see.  So what would I need to do to enable it?  Recompile the
> kernel?
> > Drop a file somewhere?
>
> There may be a kmod for it in rpmfusion? If not you'll need to rebuild
> your kernel.
>
>
I have a

03:00.0 Network controller: Broadcom Corporation BCM4313 802.11b/g LP-PHY
(rev 01)

I use

akmod-wl

from rpmfusion to get it working.

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

Re: Fedora SPEC Review Tool

[tim.laurid...@gmail.com]

On Wed, Apr 6, 2011 at 8:11 PM, Jeffrey Ness wrote:

> Hello everyone,
>
> As I'm new to the community and RPM Package Review (and development), I
> figured a tool to assist with reviews would be a nice time saver.
>
> With that said I have a simple Python tool (still in early beta stages)
> which does just that.
>
> Keeping with the concept of sharing, I wanted to hand this tool out to the
> community and get any feedback from y'all:
>
>  https://github.com/jness/spec_checks
>
> This tool uses the "Package Review Guidelines" written by Tom 'spot'
> Callaway:
>
>  http://fedoraproject.org/wiki/Packaging/ReviewGuidelines
>
> Thanks for your time
> Jeffrey-
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>


I am working on a tool too, there automates much of the dirty work when
reviewing a package

Like:
- Downloading SRPM & SPEC from bugzilla report
- Download upstream source
- check md5sums
- do a total review report will both manual & automated checks, ready to
complete and paste into the bugzilla report.

https://github.com/timlau/FedoraReview

checkout and cd to the src/ dir.

./review.py -b 

it will download the spec & srpm from the bugzilla report and build them in
mock and run a number of test and generate
a report there will be opened in gedit along with the spec file, so the
stuff no automated can be reviewed manually.

You will need to have mock installed and be member of the mock group for the
build to work.

./review.py --help

Will show you the other options of the tools.

./review.py -b  -u  -p  --assign

Will assign the review to  and set the review flags in the
bugzilla report.

It is still under heavy development, but can be very useful.

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

Re: Orphaned packages by leigh123linux

[tim.laurid...@gmail.com]

On Tue, Apr 5, 2011 at 7:42 AM, tim.laurid...@gmail.com <
tim.laurid...@gmail.com> wrote:

>
>
> On Fri, Apr 1, 2011 at 12:44 PM, Rahul Sundaram wrote:
>
>> Hi
>>
>> The following have been orphaned by  leigh123linux.  Sending on his
>> behalf since his is not subscribed to this list
>>
>> libdesktop-agnostic,  avant-window-navigator, awn-applets-extras,
>> gmixer, torium and html2text
>>
>> Rahul
>> --
>> devel mailing list
>> devel@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/devel
>>
>
> I have taken avant-window-navigator & awn-applets-extras
>
> Tim
>

I have taken libdesktop-agnostic too, as awn depend on it

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

Re: Orphaned packages by leigh123linux

[tim.laurid...@gmail.com]

On Fri, Apr 1, 2011 at 12:44 PM, Rahul Sundaram  wrote:

> Hi
>
> The following have been orphaned by  leigh123linux.  Sending on his
> behalf since his is not subscribed to this list
>
> libdesktop-agnostic,  avant-window-navigator, awn-applets-extras,
> gmixer, torium and html2text
>
> Rahul
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>

I have taken avant-window-navigator & awn-applets-extras

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

Re: Review swaps

[tim.laurid...@gmail.com]

On Sun, Feb 20, 2011 at 5:34 PM, Hans de Goede  wrote:

> Hi,
>
> I've been working on packaging lcd4linux (to use together with the digital
> picture frames I also wrote a libgphoto driver for a while ago).
>
> The packaging is complete and now I'm looking for reviewers for the
> following 3 packages. As usual I'll gladly swap a review for a review.
> Note that the first 2 are deps of the lcd4linux.
>
> 678887 - Review Request: libst2205 - Library for accessing the display of
> hacked st2205 photo frames
> 678889 - Review Request: serdisplib - Library to drive serial displays with
> built-in controllers
> 678891 - Review Request: lcd4linux - Display system state on an external
> LCD display
>
> Regards,
>
> Hans
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>

I will review them for free :)

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