Re: Patches for trivial bugs sitting in bugzilla -> trivial patch policy?

[Ralf Corsepius]

On 06/26/2014 09:40 PM, Bruno Wolff III wrote:

On Thu, Jun 26, 2014 at 10:42:17 -0600,
  Kevin Fenzi  wrote:


Another idea that leaps to mind is to add more provenpackagers...
have we set the bar too high so no one wants to apply?


Trivial bug fixing across the project seems to be a reasonable
justification for giving out proven packager status.

Full ack.


As long as people
know their limitations so that not too many mistakes get made.
Your last sentence is the point, which makes me reluctant on the OPs 
proposal.


Unfortunately, Fedora has seen too many people who were not aware about 
the limitations of their skills and too many people, who were mixing up 
personal preference and stylishness with actual bugs.


Ralf

--
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: Patches for trivial bugs sitting in bugzilla -> trivial patch policy?

[Marcela Mašláňová]

On 26/06/14 22:33, Kevin Fenzi wrote:

On Thu, 26 Jun 2014 13:01:05 -0500
Yaakov Selkowitz  wrote:


On 2014-06-26 11:17, Richard Hughes wrote:

On 26 June 2014 17:02, Simone Caronni  wrote:

+1 from me!


If it's a trivial patch then I think it makes sense to just do it.
  From someone that touches hundreds of different projects every
month, I've found it's better to ask forgiveness than permission :)


As previously stated, that only works if you are a provenpackager.
The question is for those of us who are not, but are trying to help.

This seems to be particularly needed around mass rebuilds, which IMHO
should be an "all-hands-on-deck" time.  For example, I've been going
through the sizable F21FTBFS list[1][2], looking for arm-specific
bugs and fixing what else I can along the way.  So far most of my
~100 patches are just bitrotting in bugzilla, while branching is less
than two weeks away.

As a newcomer to Fedora development, is there something else I should
doing to get these patches reviewed and committed?


I'm pretty swamped, but I'm happy to go through them as time permits
and help apply/build them.

I assume they are attached to each of the FTBFS bugs?

If other provenpackgers have time it would be great to apply these
before branching.

kevin



I'm not sure if it's so great idea for all bugzillas. Some packagers 
prefer to add patches first into upstream then carry a patch for many 
releases.


FTBFS bugs are different, I guess it's okay to fix them immediately. It 
can hardly do more harm.


Marcela
--
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: Package onership

[Michael Cronenworth]

On 06/26/2014 11:34 PM, Dmitrij S. Kryzhevich wrote:

Package NearTree is going to be dropped as it is not built for F21. Its
maintainer, tmatsuu, was seen on koji in late 2012, September.

I would like to take NearTree as it is reqiured for my rasmol package. I made
a request in PkgDB, but who should I notice to grant the rights?


http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers

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

Package onership

[Dmitrij S. Kryzhevich]

Hi!

Package NearTree is going to be dropped as it is not built for F21. Its 
maintainer, tmatsuu, was seen on koji in late 2012, September.

I would like to take NearTree as it is reqiured for my rasmol package. I made 
a request in PkgDB, but who should I notice to grant the rights?

Dmitrij.
-- 
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: Patches for trivial bugs sitting in bugzilla -> trivial patch policy?

[Kevin Fenzi]

On Fri, 27 Jun 2014 01:27:23 +0200
Sandro Mani  wrote:

> On 27.06.2014 00:55, Kevin Fenzi wrote:
...snip...
> > - Not sure 'trivial' really covers the things you list in examples.
> >FTBFS could be more than trivial depending on the patch. Perhaps
> > the entire thing could be 'simple patches' or 'easy patches'
> Right. So the list Yaakov Selkowitz posted elsewhere in this thread 
> gives a good set of possible FTBFS causes. I'm not sure all FTBFS
> should be covered by such a policy, but if it is only a matter of
> fixing bad BRs, format security issues or makefile issues, these
> should fall under the accepted category. If the FTBFS fix involves
> porting for API/ABI breaks, then IMO that does not fall under this
> category. But yeah, simple might be more appropriate terminology.

Yeah, makes sense. 

> > - 'flags' are a pain to get bugzilla folks to add and manage. How
> > about a blocker bug instead? Then interested maintainers could
> > simply cc to the blocker bug to notice when new things are added.
> > You just add the patch bug to the blocks of the tracker.
> I guess this would work just as well!
> > - Should this be rawhide only? That would avoid 'trivial' patches
> > that cause a problem from affecting users that aren't as able to
> > debug them.
> What about rawhide for all and stable releases for packagers only?

Or perhaps (since they are simple/trivial) they could be applied in
stable releases, but not pushed as updates? They would go out with the
next update the maintainer pushed...

BTW, thanks for working on this. :) 

kevin


signature.asc
Description: 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

Re: yum install kernel-devel Installing & dnf install kernel-devel Installing also

[poma]

Reverted
installonly: kernel-devel should not be installonly.
https://github.com/akozumpl/dnf/commit/e3856e6


# dnf --disablerepo \* --enablerepo rawhide-koji update kernel\* \*perf
Dependencies resolved.

==
  Package Arch Version  Repository  
  Size
==
Installing:
  kernel  i686 3.16.0-0.rc2.git2.1.fc21 
rawhide-koji  86 k
  kernel-core i686 3.16.0-0.rc2.git2.1.fc21 
rawhide-koji  18 M
  kernel-modules  i686 3.16.0-0.rc2.git2.1.fc21 
rawhide-koji  16 M
  kernel-develi686 3.16.0-0.rc2.git2.1.fc21 
rawhide-koji 9.0 M
  kernel-modules-extrai686 3.16.0-0.rc2.git2.1.fc21 
rawhide-koji 2.2 M
Upgrading:
  kernel-headers  i686 3.16.0-0.rc2.git2.1.fc21 
rawhide-koji 985 k
  kernel-toolsi686 3.16.0-0.rc2.git2.1.fc21 
rawhide-koji 168 k
  kernel-tools-libs   i686 3.16.0-0.rc2.git2.1.fc21 
rawhide-koji  92 k
  kernel-tools-libs-devel i686 3.16.0-0.rc2.git2.1.fc21 
rawhide-koji  88 k
  perfi686 3.16.0-0.rc2.git2.1.fc21 
rawhide-koji 1.0 M
  python-perf i686 3.16.0-0.rc2.git2.1.fc21 
rawhide-koji 179 k

Transaction Summary
==
Install  5 Packages
Upgrade  6 Packages

Total download size: 48 M
Is this ok [y/N]: y


Ref. bz
[kerne] kernel-devel corresponding to the running kernel should stay installed
https://bugzilla.redhat.com/show_bug.cgi?id=1062997


poma


--
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: Patches for trivial bugs sitting in bugzilla -> trivial patch policy?

[Michael Catanzaro]

This is a really good idea.

On Thu, 2014-06-26 at 16:55 -0600, Kevin Fenzi wrote:
> - Should this be rawhide only? That would avoid 'trivial' patches that
>   cause a problem from affecting users that aren't as able to debug
>   them. 

No, since the primary use for this would probably be backporting
upstream fixes. At least that's what I would use it for (if it's
available to non-packagers; I'm not a packager).


signature.asc
Description: This is a digitally signed message part
-- 
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: Self Introduction: Dennis Kliban (dkliban)

[Kenjiro Nakayama]

Welcome on board!

Kenjiro

Dennis Kliban writes:

> I have been working with the ImageFactory (www.imgfac.org) team over the last 
> 18 months.  During that time we developed a second image building project 
> called nova-image-builder 
> (https://github.com/redhat-imaging/novaimagebuilder).  At this point we feel 
> it is appropriate to submit our first version of nova-image-builder to 
> Fedora.  I have submitted a review request: 
> https://bugzilla.redhat.com/show_bug.cgi?id=1113301
-- 
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: Patches for trivial bugs sitting in bugzilla -> trivial patch policy?

[Sandro Mani]

On 27.06.2014 00:55, Kevin Fenzi wrote:

On Fri, 27 Jun 2014 00:39:52 +0200
Sandro Mani  wrote:


So the thing that should be avoided IMO is not defining well enough
how the procedure should work, to avoid getting swamped with patches
which require additional work to apply. The requirement to fill out
post a "New Package Request" style form to the bug should allow most
of the work to be scripted, and ideally the proven packager would
just need to look at the patch, and if happy, fire the script.

So maybe such a policy could look something like this [1]. Contrarily
to what I wrote initially, I think it might actually make sense to
allow also non-packagers to file such requests, and it would provide
another way of showing off experience which will eventually lead to
one getting sponsored.

   Sandro

[1]
https://fedoraproject.org/wiki/User:Smani/Trivial_Patch_Policy_%28draft%29

A few comments:

- Not sure 'trivial' really covers the things you list in examples.
   FTBFS could be more than trivial depending on the patch. Perhaps the
   entire thing could be 'simple patches' or 'easy patches'
Right. So the list Yaakov Selkowitz posted elsewhere in this thread 
gives a good set of possible FTBFS causes. I'm not sure all FTBFS should 
be covered by such a policy, but if it is only a matter of fixing bad 
BRs, format security issues or makefile issues, these should fall under 
the accepted category. If the FTBFS fix involves porting for API/ABI 
breaks, then IMO that does not fall under this category. But yeah, 
simple might be more appropriate terminology.


- 'flags' are a pain to get bugzilla folks to add and manage. How about
   a blocker bug instead? Then interested maintainers could simply cc to
   the blocker bug to notice when new things are added. You just add the
   patch bug to the blocks of the tracker.

I guess this would work just as well!

- Should this be rawhide only? That would avoid 'trivial' patches that
   cause a problem from affecting users that aren't as able to debug
   them.

What about rawhide for all and stable releases for packagers only?


Draft updated accordingly.

Thanks,
Sandro
--
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: Patches for trivial bugs sitting in bugzilla -> trivial patch policy?

[Kevin Fenzi]

On Fri, 27 Jun 2014 00:39:52 +0200
Sandro Mani  wrote:

> So the thing that should be avoided IMO is not defining well enough
> how the procedure should work, to avoid getting swamped with patches
> which require additional work to apply. The requirement to fill out
> post a "New Package Request" style form to the bug should allow most
> of the work to be scripted, and ideally the proven packager would
> just need to look at the patch, and if happy, fire the script.
> 
> So maybe such a policy could look something like this [1]. Contrarily
> to what I wrote initially, I think it might actually make sense to
> allow also non-packagers to file such requests, and it would provide
> another way of showing off experience which will eventually lead to
> one getting sponsored.
> 
>   Sandro
> 
> [1] 
> https://fedoraproject.org/wiki/User:Smani/Trivial_Patch_Policy_%28draft%29

A few comments: 

- Not sure 'trivial' really covers the things you list in examples.
  FTBFS could be more than trivial depending on the patch. Perhaps the
  entire thing could be 'simple patches' or 'easy patches' 

- 'flags' are a pain to get bugzilla folks to add and manage. How about
  a blocker bug instead? Then interested maintainers could simply cc to
  the blocker bug to notice when new things are added. You just add the
  patch bug to the blocks of the tracker. 

- Should this be rawhide only? That would avoid 'trivial' patches that
  cause a problem from affecting users that aren't as able to debug
  them. 

kevin


signature.asc
Description: 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

Re: Patches for trivial bugs sitting in bugzilla -> trivial patch policy?

[Yaakov Selkowitz]

On 2014-06-26 15:33, Kevin Fenzi wrote:

On Thu, 26 Jun 2014 13:01:05 -0500 Yaakov Selkowitz wrote:

This seems to be particularly needed around mass rebuilds, which IMHO
should be an "all-hands-on-deck" time.  For example, I've been going
through the sizable F21FTBFS list[1][2], looking for arm-specific
bugs and fixing what else I can along the way.  So far most of my
~100 patches are just bitrotting in bugzilla, while branching is less
than two weeks away.

As a newcomer to Fedora development, is there something else I should
doing to get these patches reviewed and committed?


I'm pretty swamped, but I'm happy to go through them as time permits
and help apply/build them.

I assume they are attached to each of the FTBFS bugs?


Or to the previously reported bugs (usually -Werror=format-security), 
upon which they are now marked as dependent.  I tested the patches with 
mock before posting.


Here are my unreviewed patches from last week or earlier, oldest to newest:

https://bugzilla.redhat.com/show_bug.cgi?id=1106267
https://bugzilla.redhat.com/show_bug.cgi?id=1037113
https://bugzilla.redhat.com/show_bug.cgi?id=1106672
https://bugzilla.redhat.com/show_bug.cgi?id=1106724
https://bugzilla.redhat.com/show_bug.cgi?id=1037027
https://bugzilla.redhat.com/show_bug.cgi?id=1106709
https://bugzilla.redhat.com/show_bug.cgi?id=1106627
https://bugzilla.redhat.com/show_bug.cgi?id=1037142
https://bugzilla.redhat.com/show_bug.cgi?id=1106999
https://bugzilla.redhat.com/show_bug.cgi?id=1106110
https://bugzilla.redhat.com/show_bug.cgi?id=1107056
https://bugzilla.redhat.com/show_bug.cgi?id=1106682
https://bugzilla.redhat.com/show_bug.cgi?id=1105998
https://bugzilla.redhat.com/show_bug.cgi?id=1107402
https://bugzilla.redhat.com/show_bug.cgi?id=1106318
https://bugzilla.redhat.com/show_bug.cgi?id=1037057
https://bugzilla.redhat.com/show_bug.cgi?id=1107365
https://bugzilla.redhat.com/show_bug.cgi?id=1106295
https://bugzilla.redhat.com/show_bug.cgi?id=1106983
https://bugzilla.redhat.com/show_bug.cgi?id=1037361
https://bugzilla.redhat.com/show_bug.cgi?id=1107410
https://bugzilla.redhat.com/show_bug.cgi?id=1107232
https://bugzilla.redhat.com/show_bug.cgi?id=1037369
https://bugzilla.redhat.com/show_bug.cgi?id=1106307
https://bugzilla.redhat.com/show_bug.cgi?id=1106116
https://bugzilla.redhat.com/show_bug.cgi?id=1105976
https://bugzilla.redhat.com/show_bug.cgi?id=1037084
https://bugzilla.redhat.com/show_bug.cgi?id=1106751
https://bugzilla.redhat.com/show_bug.cgi?id=1037245
https://bugzilla.redhat.com/show_bug.cgi?id=1107101
https://bugzilla.redhat.com/show_bug.cgi?id=1106182
https://bugzilla.redhat.com/show_bug.cgi?id=1105923
https://bugzilla.redhat.com/show_bug.cgi?id=1107057
https://bugzilla.redhat.com/show_bug.cgi?id=1107080
https://bugzilla.redhat.com/show_bug.cgi?id=1037190
https://bugzilla.redhat.com/show_bug.cgi?id=1105994
https://bugzilla.redhat.com/show_bug.cgi?id=1105945
https://bugzilla.redhat.com/show_bug.cgi?id=1106011
https://bugzilla.redhat.com/show_bug.cgi?id=1106235
https://bugzilla.redhat.com/show_bug.cgi?id=1107042
https://bugzilla.redhat.com/show_bug.cgi?id=1106795
https://bugzilla.redhat.com/show_bug.cgi?id=1106018
https://bugzilla.redhat.com/show_bug.cgi?id=1037184
https://bugzilla.redhat.com/show_bug.cgi?id=1037185
https://bugzilla.redhat.com/show_bug.cgi?id=1037186
https://bugzilla.redhat.com/show_bug.cgi?id=1037390
https://bugzilla.redhat.com/show_bug.cgi?id=1037394
https://bugzilla.redhat.com/show_bug.cgi?id=1107271
https://bugzilla.redhat.com/show_bug.cgi?id=1106024
https://bugzilla.redhat.com/show_bug.cgi?id=1106029
https://bugzilla.redhat.com/show_bug.cgi?id=1037083
https://bugzilla.redhat.com/show_bug.cgi?id=1106247
https://bugzilla.redhat.com/show_bug.cgi?id=1107282
https://bugzilla.redhat.com/show_bug.cgi?id=1037207
https://bugzilla.redhat.com/show_bug.cgi?id=1037382
https://bugzilla.redhat.com/show_bug.cgi?id=1037396
https://bugzilla.redhat.com/show_bug.cgi?id=1105990


If other provenpackgers have time it would be great to apply these
before branching.


Thanks,

Yaakov Selkowitz

--
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: Patches for trivial bugs sitting in bugzilla -> trivial patch policy?

[Sandro Mani]

On 26.06.2014 22:47, Jeff Backus wrote:


On Thu, Jun 26, 2014 at 12:42 PM, Kevin Fenzi > wrote:



I'm not sure the entire group of provenpackagers would like to be
notified of such trivial patches waiting. Is there a group of
provenpackagers who would be willing to query for and apply these?


Maybe a simple way to allow non-provenpackagers to highlight these 
"trivial bug" patches would be via a perma-bug a-la FE-NEEDSPONSOR? 
That way there is a centralized place inclined provenpackages can 
check which doesn't require following a mailing list and is simple 
enough even us n00bs can figure it out. :)


I presume the implementation cost is miniscule, so might at least be 
worth an experiment.


So the thing that should be avoided IMO is not defining well enough how 
the procedure should work, to avoid getting swamped with patches which 
require additional work to apply. The requirement to fill out post a 
"New Package Request" style form to the bug should allow most of the 
work to be scripted, and ideally the proven packager would just need to 
look at the patch, and if happy, fire the script.


So maybe such a policy could look something like this [1]. Contrarily to 
what I wrote initially, I think it might actually make sense to allow 
also non-packagers to file such requests, and it would provide another 
way of showing off experience which will eventually lead to one getting 
sponsored.


 Sandro

[1] 
https://fedoraproject.org/wiki/User:Smani/Trivial_Patch_Policy_%28draft%29
-- 
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: Patches for trivial bugs sitting in bugzilla -> trivial patch policy?

[Jeff Backus]

On Thu, Jun 26, 2014 at 12:42 PM, Kevin Fenzi  wrote:

>
> I'm not sure the entire group of provenpackagers would like to be
> notified of such trivial patches waiting. Is there a group of
> provenpackagers who would be willing to query for and apply these?
>
>
Maybe a simple way to allow non-provenpackagers to highlight these "trivial
bug" patches would be via a perma-bug a-la FE-NEEDSPONSOR? That way there
is a centralized place inclined provenpackages can check which doesn't
require following a mailing list and is simple enough even us n00bs can
figure it out. :)

I presume the implementation cost is miniscule, so might at least be worth
an experiment.

Regards,
Jeff

-- 
Jeff Backus
jeff.bac...@gmail.com
http://github.com/jsbackus
-- 
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: Patches for trivial bugs sitting in bugzilla -> trivial patch policy?

[Kevin Fenzi]

On Thu, 26 Jun 2014 13:01:05 -0500
Yaakov Selkowitz  wrote:

> On 2014-06-26 11:17, Richard Hughes wrote:
> > On 26 June 2014 17:02, Simone Caronni  wrote:
> >> +1 from me!
> >
> > If it's a trivial patch then I think it makes sense to just do it.
> >  From someone that touches hundreds of different projects every
> > month, I've found it's better to ask forgiveness than permission :)
> 
> As previously stated, that only works if you are a provenpackager.
> The question is for those of us who are not, but are trying to help.
> 
> This seems to be particularly needed around mass rebuilds, which IMHO 
> should be an "all-hands-on-deck" time.  For example, I've been going 
> through the sizable F21FTBFS list[1][2], looking for arm-specific
> bugs and fixing what else I can along the way.  So far most of my
> ~100 patches are just bitrotting in bugzilla, while branching is less
> than two weeks away.
> 
> As a newcomer to Fedora development, is there something else I should 
> doing to get these patches reviewed and committed?

I'm pretty swamped, but I'm happy to go through them as time permits
and help apply/build them. 

I assume they are attached to each of the FTBFS bugs?

If other provenpackgers have time it would be great to apply these
before branching. 

kevin


signature.asc
Description: 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

Re: Non-responsive maintainer: Deji Akingunola (fas: deji)

[Kevin Fenzi]

On Wed, 25 Jun 2014 18:19:32 +0200
Sandro Mani  wrote:

> Hi,
> 
> Given that no-one seems to know how to contact deji, I'd like to
> request the takeover of scotch.

as a fesco member I can ack this. 

We will be orphaning his packages and you can pick up scotch. 

kevin


signature.asc
Description: 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

Re: Patches for trivial bugs sitting in bugzilla -> trivial patch policy?

[Mukundan Ragavan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


I think having a "trivial patch" policy and proven packager route of
implementation is a great idea!

On 06/26/2014 11:42 AM, Kevin Fenzi wrote:
> provenpackagers who would be willing to query for and apply these?
> 
> Another idea that leaps to mind is to add more provenpackagers... 
> have we set the bar too high so no one wants to apply?
> 

Isn't it best for the project as a whole to have the bar for proven
packager high? :)

Mukundan.

- -- 
GPG key-ID: 00E8658D

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCgAGBQJTrIIpAAoJEIfjPv0A6GWNTmcQAIGQ+HaTR36pU1gOydNJhTim
clypJ8mCmKC81uWUvI8cFjN2y61gAf9vLsrSkbIP4vZoVIVhFODtWSuYrDhgdwaK
82+QZ89wvKqfq/aWSS8mlo1MJJ3vm7OhnI7zH+pbrVnbUmKbOd9tXapePJt6koXC
S1Wyz/hBvqmXdafl/wGMFTBwieOe+bDRZTa6NNP4G8CksL1CNlg6L7oP3JWXtI0R
0dF3l9GUDSQGAN1+lQuGkmArTmiCqjr/lXQZR9OKMdcmXQhuEl+9kJd6klcMKI6r
o6Qm5/4Pf3VKRixhUec88IA30YUDeqJP4IgNGv64fwI8uJgX65Fipxf7NxDyMJt9
em0EOKNKjQtwnb3R0zr+YDbaWUCFCZVuiTFTHkaG5ojwezWE11+nJ5zaiI9i6WOJ
rxl7bbhG29MEBhnJaiDnm4Zdk38IEuCld6zcIe8tM0E7vkNTzLQ2BMyPyS5Jnwx6
UzuCfpzgMgfEMpE/j6r22prsEhbN/XEcd+vGkZpnFH1R/tTQcTFauiAc1UNODjpW
A9TqidqHH/1wxCeVuZYupsAh2pYy18cC1MrrbkJ2OZl+qacog2xpz2O11p6gDKi+
dkt31JF6Ftgc7CIuMYuNVU3WmKyUcXFROd6dpmmykN3ouDR14Iq7FWea0OM8Dsjh
UHCBmAQitu/csPghf2u7
=FOGa
-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

Re: Attempting to contact three unresponsive maintainers

[Kevin Fenzi]

On Thu, 26 Jun 2014 06:57:29 -0400
Andy Grimm  wrote:

> On Jun 18, 2014 5:28 PM, "Kevin Fenzi"  wrote:

...snip...

> > * sadmac - former email address cdah...@redhat.com
> >   https://admin.fedoraproject.org/pkgdb/packager/sadmac/
> >   Point of contact: 1
> >   Co-maintainer:0
> >   Watched:  1
> 
> If you still haven't located cdahlin,  wwoods can probably help.

Thanks, he gave me an email to try. 

kevin


signature.asc
Description: 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

Re: Attempting to contact three unresponsive maintainers

[Kevin Fenzi]

On Thu, 26 Jun 2014 15:42:10 -0400
Adam Jackson  wrote:

> On Wed, 2014-06-18 at 18:41 -0400, Adam Jackson wrote:
> > On Wed, 2014-06-18 at 15:28 -0600, Kevin Fenzi wrote:
> > 
> > > * ssp - former email address sandm...@redhat.com
> > >   https://admin.fedoraproject.org/pkgdb/packager/ssp/
> > >   Point of contact:   39
> > >   Co-maintainer:  254
> > >   Watched:0
> > 
> > We're reshuffling Søren's packages (in a RHEL ownership sense)
> > among the X team already, I'll follow up once that's sorted.  Not
> > that we're _claiming_ them, we're always happy to have additional
> > maintainers, just that we don't need to panic about finding new
> > owners.
> 
> Reassignments so far, for things where he's listed as Point Of
> Contact:
> 
> libX11: ajax
> lib[A-W]*, libX[A-Za-z]*, libdmx, libfontenc, libxkbfile: bentiss
> xrestop: jwrdegoede

All done. 

(It will sure be nice when we roll out the teams support for pkgdb). 

> Still looking for owners for:
> 
> gnome-system-monitor, libgtop2, libwnck, rdesktop, vino

ok. Let me know if you would just like me to orphan them at some point. 

kevin


signature.asc
Description: 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

Re: Patches for trivial bugs sitting in bugzilla -> trivial patch policy?

[drago01]

On Thu, Jun 26, 2014 at 6:42 PM, Kevin Fenzi  wrote:
> On Thu, 26 Jun 2014 17:17:07 +0100
> Richard Hughes  wrote:
>
>> On 26 June 2014 17:02, Simone Caronni  wrote:
>> > +1 from me!
>>
>> If it's a trivial patch then I think it makes sense to just do it.
>> From someone that touches hundreds of different projects every month,
>> I've found it's better to ask forgiveness than permission :)
>
> Yeah, but the proposal is talking about when someone is not a
> provenpackager and doesn't have permissions to just apply them. ;(

We need to fix that.
-- 
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: Attempting to contact three unresponsive maintainers

[Adam Jackson]

On Wed, 2014-06-18 at 18:41 -0400, Adam Jackson wrote:
> On Wed, 2014-06-18 at 15:28 -0600, Kevin Fenzi wrote:
> 
> > * ssp - former email address sandm...@redhat.com
> >   https://admin.fedoraproject.org/pkgdb/packager/ssp/
> >   Point of contact: 39
> >   Co-maintainer:254
> >   Watched:  0
> 
> We're reshuffling Søren's packages (in a RHEL ownership sense) among the
> X team already, I'll follow up once that's sorted.  Not that we're
> _claiming_ them, we're always happy to have additional maintainers, just
> that we don't need to panic about finding new owners.

Reassignments so far, for things where he's listed as Point Of Contact:

libX11: ajax
lib[A-W]*, libX[A-Za-z]*, libdmx, libfontenc, libxkbfile: bentiss
xrestop: jwrdegoede

Still looking for owners for:

gnome-system-monitor, libgtop2, libwnck, rdesktop, vino

- ajax

-- 
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: Patches for trivial bugs sitting in bugzilla -> trivial patch policy?

[Bruno Wolff III]

On Thu, Jun 26, 2014 at 10:42:17 -0600,
 Kevin Fenzi  wrote:


Another idea that leaps to mind is to add more provenpackagers...
have we set the bar too high so no one wants to apply?


Trivial bug fixing across the project seems to be a reasonable justification 
for giving out proven packager status. As long as people know their 
limitations so that not too many mistakes get made.

--
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: setterm impact changed

[Felix Miata]

On 2014-06-26 13:24 (GMT-0500) Chris Adams composed:


Felix Miata said:



Now that the kernel is no longer putting the display to
sleep and I can start X, I find that setterm command no longer
applies only to the vttys. It's now coloring my Konsoles, which I do
not want, and I don't see a way in the setterm man page to stop it.
:-(



Are you calling it from your .bashrc?  A simple thing like this should
do (basically, only run setterm when connected to /dev/tty[0-9]*):



tty=$(tty)
[ "$tty" != "${tty#/dev/tty[0-9]}" ] && setterm 


Awesome! :-D
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
-- 
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: yum install kernel-devel Installing & dnf install kernel-devel Upgrading

[poma]

On 26.06.2014 09:39, Ales Kozumplik wrote:


Hello,

The globbing mechanism in DNF is still evolving and it is possible you
are running into one of the cases that we omitted to implement. Or
perhaps there is a different problem. Can I ask you to file a bug using

https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=dnf

so the issue is tracked and when the time comes one of us working on DNF
can take a look at it in detail?

For further information kindly take a look at:

http://fedoraproject.org/wiki/How_to_file_a_bug_report

Thanks!

Ales



Of course you can always ask and hope as I have done many times before. ;)
Looks like Batman poking around Rawhide repo. :)
Actually this[1] problem is now identical to the one was with the 
'kernel-modules-extra'.


/etc/yum.repos.d/fedora-rawhide-koji.repo
[rawhide-koji]
name=Fedora $releasever - $basearch - Koji
baseurl=http://koji.fedoraproject.org/repos/f$releasever-build/latest/$basearch/
enabled=0
gpgcheck=0
skip_if_unavailable=True


# yum --disablerepo \* --enablerepo rawhide-koji update kernel\* \*perf
Loaded plugins: langpacks
Resolving Dependencies
--> Running transaction check
---> Package kernel.i686 0:3.16.0-0.rc2.git2.1.fc21 will be installed
---> Package kernel-core.i686 0:3.16.0-0.rc2.git2.1.fc21 will be installed
---> Package kernel-devel.i686 0:3.16.0-0.rc2.git2.1.fc21 will be installed
---> Package kernel-headers.i686 0:3.16.0-0.rc2.git0.1.fc21 will be updated
---> Package kernel-headers.i686 0:3.16.0-0.rc2.git2.1.fc21 will be an update
---> Package kernel-modules.i686 0:3.16.0-0.rc2.git2.1.fc21 will be installed
---> Package kernel-modules-extra.i686 0:3.16.0-0.rc2.git2.1.fc21 will be 
installed
---> Package kernel-tools.i686 0:3.16.0-0.rc2.git0.1.fc21 will be updated
---> Package kernel-tools.i686 0:3.16.0-0.rc2.git2.1.fc21 will be an update
---> Package kernel-tools-libs.i686 0:3.16.0-0.rc2.git0.1.fc21 will be updated
---> Package kernel-tools-libs.i686 0:3.16.0-0.rc2.git2.1.fc21 will be an update
---> Package kernel-tools-libs-devel.i686 0:3.16.0-0.rc2.git0.1.fc21 will be 
updated
---> Package kernel-tools-libs-devel.i686 0:3.16.0-0.rc2.git2.1.fc21 will be an 
update
---> Package perf.i686 0:3.16.0-0.rc2.git0.1.fc21 will be updated
---> Package perf.i686 0:3.16.0-0.rc2.git2.1.fc21 will be an update
---> Package python-perf.i686 0:3.16.0-0.rc2.git0.1.fc21 will be updated
---> Package python-perf.i686 0:3.16.0-0.rc2.git2.1.fc21 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

==
  Package Arch Version  
RepositorySize
==
Installing:
  kernel  i686 3.16.0-0.rc2.git2.1.fc21 
rawhide-koji  86 k
  kernel-core i686 3.16.0-0.rc2.git2.1.fc21 
rawhide-koji  18 M
  kernel-develi686 3.16.0-0.rc2.git2.1.fc21 
rawhide-koji 9.0 M
  kernel-modules  i686 3.16.0-0.rc2.git2.1.fc21 
rawhide-koji  16 M
  kernel-modules-extrai686 3.16.0-0.rc2.git2.1.fc21 
rawhide-koji 2.2 M
Updating:
  kernel-headers  i686 3.16.0-0.rc2.git2.1.fc21 
rawhide-koji 985 k
  kernel-toolsi686 3.16.0-0.rc2.git2.1.fc21 
rawhide-koji 168 k
  kernel-tools-libs   i686 3.16.0-0.rc2.git2.1.fc21 
rawhide-koji  92 k
  kernel-tools-libs-devel i686 3.16.0-0.rc2.git2.1.fc21 
rawhide-koji  88 k
  perfi686 3.16.0-0.rc2.git2.1.fc21 
rawhide-koji 1.0 M
  python-perf i686 3.16.0-0.rc2.git2.1.fc21 
rawhide-koji 179 k

Transaction Summary
==
Install  5 Packages
Upgrade  6 Packages

Total download size: 48 M
Is this ok [y/d/N]: y


# dnf --disablerepo \* --enablerepo rawhide-koji update kernel\* \*perfFailed 
loading plugin: copr
Dependencies resolved.

==
  Package Arch Version  
RepositorySize
==
Installing:
  kernel  i686 3.16.0-0.rc2.git2.1.fc21 
rawhide-koji  86 k
  kernel-core i686 3.16.0-0.rc2.git2.1.fc21 
rawhide-koji  18 M
  kernel-modules  i686 3.16.0-0.rc2.git2.1.fc21 
rawhide-koji  16 M
  kernel-modules-extrai686 3.16.0-0.rc2.git2.1.fc21 
rawhide-koji 2.2 M
Upgrading:
  
~
  ker

Re: setterm impact changed (was: setterm syntax changed)

[Chris Adams]

Once upon a time, Felix Miata  said:
> New problem. Now that the kernel is no longer putting the display to
> sleep and I can start X, I find that setterm command no longer
> applies only to the vttys. It's now coloring my Konsoles, which I do
> not want, and I don't see a way in the setterm man page to stop it.
> :-(

Are you calling it from your .bashrc?  A simple thing like this should
do (basically, only run setterm when connected to /dev/tty[0-9]*):

tty=$(tty)
[ "$tty" != "${tty#/dev/tty[0-9]}" ] && setterm 

-- 
Chris Adams 
-- 
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: Patches for trivial bugs sitting in bugzilla -> trivial patch policy?

[Yaakov Selkowitz]

On 2014-06-26 11:17, Richard Hughes wrote:

On 26 June 2014 17:02, Simone Caronni  wrote:

+1 from me!


If it's a trivial patch then I think it makes sense to just do it.
 From someone that touches hundreds of different projects every month,
I've found it's better to ask forgiveness than permission :)


As previously stated, that only works if you are a provenpackager.  The 
question is for those of us who are not, but are trying to help.


This seems to be particularly needed around mass rebuilds, which IMHO 
should be an "all-hands-on-deck" time.  For example, I've been going 
through the sizable F21FTBFS list[1][2], looking for arm-specific bugs 
and fixing what else I can along the way.  So far most of my ~100 
patches are just bitrotting in bugzilla, while branching is less than 
two weeks away.


As a newcomer to Fedora development, is there something else I should 
doing to get these patches reviewed and committed?



Yaakov Selkowitz

[1] http://ausil.fedorapeople.org/f21-failures.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1105908

--
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: Patches for trivial bugs sitting in bugzilla -> trivial patch policy?

[Sandro Mani]

On 26.06.2014 19:04, Till Maas wrote:

IMHO there is not a huge group needed to handle on-demand provenpackager
tasks (as long as it is only required to review and apply a patch to
dist-git and potential debugging/scratch building is done before).



Good point, adding to the previous conditions I'd add that the user must 
also provide a link to a scratch build.


--
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: Patches for trivial bugs sitting in bugzilla -> trivial patch policy?

[Till Maas]

On Thu, Jun 26, 2014 at 10:42:17AM -0600, Kevin Fenzi wrote:

> I'm not sure the entire group of provenpackagers would like to be
> notified of such trivial patches waiting. Is there a group of
> provenpackagers who would be willing to query for and apply these?

I am.

> Another idea that leaps to mind is to add more provenpackagers... 
> have we set the bar too high so no one wants to apply?

IMHO there is not a huge group needed to handle on-demand provenpackager
tasks (as long as it is only required to review and apply a patch to
dist-git and potential debugging/scratch building is done before).

Regards
Till
-- 
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: setterm impact changed (was: setterm syntax changed)

[Felix Miata]

On 2014-06-26 03:03 (GMT-0400) Felix Miata composed:


On 2014-06-25 23:54 (GMT-0700) Samuel Sieb composed:



Felix Miata wrote:



 setterm --background blue --foreground white --bold --blank 59 --store



That moved the error:



 setterm: argument error: --blank



Perhaps the on/off argument to --bold is no longer optional?



Are you sure your question wasn't rhetorical? No error message following
--bold with on. :-)


New problem. Now that the kernel is no longer putting the display to sleep 
and I can start X, I find that setterm command no longer applies only to the 
vttys. It's now coloring my Konsoles, which I do not want, and I don't see a 
way in the setterm man page to stop it. :-(

--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
--
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: Patches for trivial bugs sitting in bugzilla -> trivial patch policy?

[Sandro Mani]

On 26.06.2014 18:42, Kevin Fenzi wrote:

On Thu, 26 Jun 2014 17:17:07 +0100
Richard Hughes  wrote:


On 26 June 2014 17:02, Simone Caronni  wrote:

+1 from me!

If it's a trivial patch then I think it makes sense to just do it.
 From someone that touches hundreds of different projects every month,
I've found it's better to ask forgiveness than permission :)

Yeah, but the proposal is talking about when someone is not a
provenpackager and doesn't have permissions to just apply them. ;(

I'm not sure the entire group of provenpackagers would like to be
notified of such trivial patches waiting. Is there a group of
provenpackagers who would be willing to query for and apply these?
I'd assume it would be a group of packagers who would volunteer to do 
so. Just to be clear: I'm not a proven packager at this time, but since 
I'm proposing this I'd obviously also be happy to help out.

Another idea that leaps to mind is to add more provenpackagers...
have we set the bar too high so no one wants to apply?
I guess unless you don't have a real reason to do so (i.e. don't work on 
packages which can influence many other components of the distribution), 
you don't see an immediate reason to.




--
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: Patches for trivial bugs sitting in bugzilla -> trivial patch policy?

[Kevin Fenzi]

On Thu, 26 Jun 2014 17:17:07 +0100
Richard Hughes  wrote:

> On 26 June 2014 17:02, Simone Caronni  wrote:
> > +1 from me!
> 
> If it's a trivial patch then I think it makes sense to just do it.
> From someone that touches hundreds of different projects every month,
> I've found it's better to ask forgiveness than permission :)

Yeah, but the proposal is talking about when someone is not a
provenpackager and doesn't have permissions to just apply them. ;( 

I'm not sure the entire group of provenpackagers would like to be
notified of such trivial patches waiting. Is there a group of
provenpackagers who would be willing to query for and apply these?

Another idea that leaps to mind is to add more provenpackagers... 
have we set the bar too high so no one wants to apply?

kevin


signature.asc
Description: 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

Re: Patches for trivial bugs sitting in bugzilla -> trivial patch policy?

[punto...@libero.it]

Il 26/06/2014 18:17, Richard Hughes ha scritto:

On 26 June 2014 17:02, Simone Caronni  wrote:

+1 from me!

If it's a trivial patch then I think it makes sense to just do it.
 From someone that touches hundreds of different projects every month,
I've found it's better to ask forgiveness than permission :)

Richard

+1 for me
gil
<>-- 
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: Patches for trivial bugs sitting in bugzilla -> trivial patch policy?

[Richard Hughes]

On 26 June 2014 17:02, Simone Caronni  wrote:
> +1 from me!

If it's a trivial patch then I think it makes sense to just do it.
From someone that touches hundreds of different projects every month,
I've found it's better to ask forgiveness than permission :)

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

Patches for trivial bugs sitting in bugzilla -> trivial patch policy?

[Sandro Mani]

Hi,

From time to time, I see trivial patches posted in bugzilla which end 
up sitting there because the maintainer is too busy / gets bombarded 
with tons of bugzilla mails and misses that particular one / whatever 
reason. As a packager, sometimes it seems very hard to get such trivial 
patches applied. What you can do is


- You can keep pinging bugzilla
- You can apply for commit rights, which might be excessive for just 
this one patch, and still requires the maintainer to answer.
- You can start the non-responsive maintainer procedure, even if you 
know perfectly well that the maintainer is still active. Or you might 
suspect that the maintainer is inactive, but you'd rather not have to 
wait for an entire month, because this one bug is blocking your work.
- You can start asking on irc for a proven packager to jump in and hope 
a proven packager is online and has time at that moment.
- You can post on -devel, though again, unless someone has time right 
now it gets forgotten an people move on.
- Repeat the above n times until someone shouts at you and flags your 
email as spam :)


So wondering, if there is a way we can improve the situation. One idea 
which comes to mind would be something like "trivial patch policy"
- after i.e. one week of inactivity one can flag such a bug as a trivial 
bug. You can only do so if you are a packager and post a patch (which 
also updates the SPEC, so just a matter of apply patch, fedpkg commit & 
build).
- for anything else than packaging issues, the patch may only be a well 
justified upstream commit backport
- a proven packagers gets notified about the issue, validates the patch 
and if ok fires the update. The entire thing might work similar to how a 
New Package / Package Change request works, by posting something like 
this to the bug:

  Trivial Patch Request
  =
  Patch[branch]:
  Patch[other_branch]:
  Reason:
  Upstream commit:
  Submitter:


From my experience such situations do not occur too frequently, but 
when they happen, they can be hard to deal with.


Comments?

Thanks,
Sandro

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

5tFTw: NetworkManager Feature Explosion, Waartaa Video Chat, Fedora Board on Fedora.next Products, Flock Planning, and Writing for the Magazine (2014-06-24)

[Matthew Miller]

Reposted from .


Fedora is a big project, and it’s hard to follow it all. This series
highlights interesting happenings in five different areas every week.
It isn’t comprehensive news coverage — just quick summaries with links
to each. Here are the five things for June 24th, 2014:


New NetworkManager Release Full of Features
---

NetworkManager, familiar to many of us as “that thing that has a
taskbar icon for getting WiFi”, has always aimed to be much more than
that. With the 0.9.10 release (which will hit Fedora’s “Rawhide”
development tree later this week and be include in Fedora 21 this
fall), there’s a whole host of features to support those broader aims,
including server and cloud-focused improvements. Read more on developer
Dan Williams’ blog.

  * http://blogs.gnome.org/dcbw/2014/06/20/well-build-a-dream-house-of-net/


Waartaa gets Video Chat
---

Waartaa is an open source, web-based chat system — it describes itself
as “IRC as a service”. Since Fedora uses IRC (Internet Relay Chat) as
our chief means of real-time collaboration in Fedora, including for our
various team meetings, this might be something we could use to make our
communications more open and friendly. There is a session about Waartaa
and Fedora at our big Flock conference this fall (August 6-9, in
Prague).

I was interested to learn that there’s a Google Summer of Code project
supporting Fedora contributor Lalit Khattar in improving Waartaa, and
right now he’s working on adding video chat support. This is a long way
from ready, but maybe in the not-too-distant future it will provide us
with a viable alternative to proprietary video chat for high-bandwidth
collaboration.

  * https://www.waartaa.com/
  * https://fedoraproject.org/wiki/How_to_use_IRC
  * https://fedoraproject.org/wiki/Meeting_channel
  * http://flock2014.sched.org/event/ed91d63174a0b3bdd744491beb9824de
  * http://flocktofedora.org/
  * https://www.google-melange.com/gsoc/homepage/google/gsoc2014
  * https://fedoraproject.org/wiki/User:Dne0
  * http://lalitkhattar.wordpress.com/2014/06/11/p2p-video-chat-gsoc-week-3/


Fedora Project Board Discusses Fedora.next Products
---

On Monday, the Fedora Project Board held a public IRC meeting. There
were two main topics: first, guidelines for third-party press releases
(which were approved); and second, general criteria for Fedora Products
— a continuation of a previous meeting on the topic. The criteria we
passed are:

-  Addresses a new, relevant, and broad use case or user base
   that a Fedora Product is not currently serving

-  The use case should be something the Board sees as being a
   long term investment

-  The Product should be coherent with all of Fedora’s foundations

We also talked briefly about the Fedora Plasma Product proposal in
light of these criteria, but did not quite get to a conclusion.
Generally, there is broad Board support for better positioning and
promotion of non-product desktop spins. More discussion will happen on
the public board-discuss mailing list before a future meeting.

View the meeting minutes or, if you like full meeting logs.

  * https://fedorahosted.org/board/ticket/3#comment:3
  * https://fedorahosted.org/board/ticket/4
  * https://fedoraproject.org/wiki/Fedora_Plasma_Product
  * https://admin.fedoraproject.org/mailman/listinfo/board-discuss
  * 
https://lists.fedoraproject.org/pipermail/meetingminutes/2014-June/001266.html
  * 
http://meetbot.fedoraproject.org/fedora-meeting/2014-06-23/board.2014-06-23-17.00.log.html


Flock Planning Meetings
---

Speaking of meetings and of Flock, the Flock planning team is holding
regular IRC meetings (on Tuesdays at 14:00 UTC in `#fedora-meeting` on
Freenode.) This week’s meeting was very short, but last week’s had a
lot of activity. (One interesting tidbit: we’ll reuse the open source
Android / Jolla / BlackBerry mobile app from Red Hat’s DevConf.cz
conference.) Anyway, if you’re interested in helping, stop by next
week.

  * 
http://meetbot.fedoraproject.org/fedora-meeting/2014-06-24/flock_planning.2014-06-24-14.05.html
  * 
http://meetbot.fedoraproject.org/fedora-meeting/2014-06-17/flock_planning.2014-06-17-13.59.html
  * http://www.devconf.cz/
  * https://play.google.com/store/apps/details?id=cz.devconf
  * https://openrepos.net/content/xmlich02/devconfcz
  * 
http://appworld.blackberry.com/webstore/content/47010890/?countrycode=NL&lang=en



Contribute to Fedora Magazine!
--

If you’re reading this on the Fedora Magazine site, you’ll notice a new
“submit an article idea” link in the right column. If you’re not, go to
 to send in
suggestions — either for full articles or for 5tFTW tips.

Fedora Magazine has had a very successful last few months and we’re
looking to build it up even more. Writ

Re: Patches for trivial bugs sitting in bugzilla -> trivial patch policy?

[Simone Caronni]

+1 from me!
On Jun 26, 2014 5:51 PM, "Sandro Mani"  wrote:

> Hi,
>
> From time to time, I see trivial patches posted in bugzilla which end up
> sitting there because the maintainer is too busy / gets bombarded with tons
> of bugzilla mails and misses that particular one / whatever reason. As a
> packager, sometimes it seems very hard to get such trivial patches applied.
> What you can do is
>
> - You can keep pinging bugzilla
> - You can apply for commit rights, which might be excessive for just this
> one patch, and still requires the maintainer to answer.
> - You can start the non-responsive maintainer procedure, even if you know
> perfectly well that the maintainer is still active. Or you might suspect
> that the maintainer is inactive, but you'd rather not have to wait for an
> entire month, because this one bug is blocking your work.
> - You can start asking on irc for a proven packager to jump in and hope a
> proven packager is online and has time at that moment.
> - You can post on -devel, though again, unless someone has time right now
> it gets forgotten an people move on.
> - Repeat the above n times until someone shouts at you and flags your
> email as spam :)
>
> So wondering, if there is a way we can improve the situation. One idea
> which comes to mind would be something like "trivial patch policy"
> - after i.e. one week of inactivity one can flag such a bug as a trivial
> bug. You can only do so if you are a packager and post a patch (which also
> updates the SPEC, so just a matter of apply patch, fedpkg commit & build).
> - for anything else than packaging issues, the patch may only be a well
> justified upstream commit backport
> - a proven packagers gets notified about the issue, validates the patch
> and if ok fires the update. The entire thing might work similar to how a
> New Package / Package Change request works, by posting something like this
> to the bug:
>   Trivial Patch Request
>   =
>   Patch[branch]:
>   Patch[other_branch]:
>   Reason:
>   Upstream commit:
>   Submitter:
>
>
> From my experience such situations do not occur too frequently, but when
> they happen, they can be hard to deal with.
>
> Comments?
>
> Thanks,
> Sandro
>
> --
> 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: GNU GPL licensed alphabet icon set

[Petr Pisar]

On 2014-06-25, Lukas Zapletal  wrote:
>
> https://github.com/lzap/foreman-dummy-icons
>
Just a bug report. The 

-draw "rectangle 0,0,20,20" 

argument is responsible for the frame at the edge of the picture. So if
you paremetrized:

-size ${SIZE}x${SIZE}

argument, you need to change the 20's into ((SIZE-1)).

-- Petr

-- 
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: Attempting to contact three unresponsive maintainers

[Andy Grimm]

On Jun 18, 2014 5:28 PM, "Kevin Fenzi"  wrote:
>
> Greetings, we've been told that the email addresses for three package
> maintainers are no longer valid.  I'm starting the unresponsive
> maintainer policy to find out if they are still interested in
> maintaining their packages (and if so, have them update their email
> addresses in FAS).  If they're not interested in maintaining or we
> can't locate them I'll have FESCo orphan the packages so that others
> can take them over.
>
> If you have a way to contact any of these maintainers, please let them
> know that we'd appreciate knowing what to do with their packages.
> Thanks!
>
> Maintainers:
>
> * tgraf - former email address tg...@redhat.com
>   https://admin.fedoraproject.org/pkgdb/packager/tgraf/
>   Point of contact: 3
>   Co-maintainer:2
>   Watched:  0
>
> * sadmac - former email address cdah...@redhat.com
>   https://admin.fedoraproject.org/pkgdb/packager/sadmac/
>   Point of contact: 1
>   Co-maintainer:0
>   Watched:  1

If you still haven't located cdahlin,  wwoods can probably help.

> * ssp - former email address sandm...@redhat.com
>   https://admin.fedoraproject.org/pkgdb/packager/ssp/
>   Point of contact: 39
>   Co-maintainer:254
>   Watched:  0
>
> If we don't hear anything in a week, we will be removing their acls and
> will need to find new point of contacts, etc.
>
> Thanks,
>
> kevin
>
> --
> 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: [ACTION REQUIRED] Retiring packages for Fedora 21 v3

[Christopher Meng]

I'd like to claim the ownership of blktap and alliance.

What should I do next? DIrectly request the ACL via bugzilla?

Thanks.
-- 
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: [ACTION REQUIRED] Retiring packages for Fedora 21 v3

[Dmitrij S. Kryzhevich]

> On Wed, Jun 25, 2014 at 10:31:18AM +0700, Dmitrij S. Kryzhevich wrote:
> > >   Package(co)maintainers
> > > 
> > > 
> > > ===
> > > NearTree   tmatsuu
> > > 
> > > The following packages require above mentioned packages:
> > > Depending on: NearTree
> > > 
> > >   rasmol (maintained by: krege)
> > >   
> > >   rasmol-2.7.5.2-3.fc21.i686 requires libCNearTree.so.5
> > >   rasmol-2.7.5.2-3.fc21.src requires NearTree-devel = 3.1.1-4.fc18
> > >   rasmol-gtk-2.7.5.2-3.fc21.i686 requires libCNearTree.so.5
> > 
> > Hi!
> > I tried to contact tmatsuu but failed. I did an admin request in PkgDB for
> > NearTree[1], what could I do else?
> > 
> > [1] https://admin.fedoraproject.org/pkgdb/package/NearTree/
> 
> Maybe worth asking for commit rights as well.
> 
> Pierre

Admin rights would grant the posibility to add me into acl commit list by 
myself.
Anyway, done.
Anyway-2, as tmatsuu still unreacheble, what could I do else?

Dmitrij.

-- 
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: yum install kernel = 11 Packages & dnf install kernel = Nothing to do

[Ales Kozumplik]

On 06/24/2014 04:23 AM, poma wrote:


One exemplary example of how to or how to not to.

# yum clean all
Loaded plugins: langpacks
Cleaning repos: rawhide
Cleaning up everything

# yum --enablerepo \* clean all
Loaded plugins: langpacks
Cleaning repos: fedora fedora-debuginfo fedora-rawhide-kernel-nodebug
fedora-rawhide-kernel-nodebug-debuginfo
fedora-rawhide-kernel-nodebug-source
   : fedora-source rawhide rawhide-debuginfo rawhide-koji
rawhide-source updates updates-debuginfo updates-source updates-testing
   : updates-testing-debuginfo updates-testing-source
Cleaning up everything

# yum --disablerepo \* --enablerepo rawhide-koji install
kernel\*3.16.0-0.rc2.git0.1.fc21\* \*perf\*3.16.0-0.rc2.git0.1.fc21\* -x
\*PAE\* -x \*debug\*
Loaded plugins: langpacks
Resolving Dependencies
--> Running transaction check
---> Package kernel.i686 0:3.16.0-0.rc2.git0.1.fc21 will be installed
---> Package kernel-core.i686 0:3.16.0-0.rc2.git0.1.fc21 will be installed
---> Package kernel-devel.i686 0:3.16.0-0.rc2.git0.1.fc21 will be installed
---> Package kernel-headers.i686 0:3.16.0-0.rc2.git0.1.fc21 will be
installed
---> Package kernel-modules.i686 0:3.16.0-0.rc2.git0.1.fc21 will be
installed
---> Package kernel-modules-extra.i686 0:3.16.0-0.rc2.git0.1.fc21 will
be installed
---> Package kernel-tools.i686 0:3.16.0-0.rc2.git0.1.fc21 will be installed
---> Package kernel-tools-libs.i686 0:3.16.0-0.rc2.git0.1.fc21 will be
installed
---> Package kernel-tools-libs-devel.i686 0:3.16.0-0.rc2.git0.1.fc21
will be installed
---> Package perf.i686 0:3.16.0-0.rc2.git0.1.fc21 will be installed
---> Package python-perf.i686 0:3.16.0-0.rc2.git0.1.fc21 will be installed
--> Finished Dependency Resolution

Dependencies Resolved



  PackageArchVersion
Repository   Size


Installing:
  kernel i6863.16.0-0.rc2.git0.1.fc21
rawhide-koji 85 k
  kernel-corei6863.16.0-0.rc2.git0.1.fc21
rawhide-koji 17 M
  kernel-devel   i6863.16.0-0.rc2.git0.1.fc21
rawhide-koji8.9 M
  kernel-headers i6863.16.0-0.rc2.git0.1.fc21
rawhide-koji984 k
  kernel-modules i6863.16.0-0.rc2.git0.1.fc21
rawhide-koji 16 M
  kernel-modules-extra   i6863.16.0-0.rc2.git0.1.fc21
rawhide-koji2.1 M
  kernel-tools   i6863.16.0-0.rc2.git0.1.fc21
rawhide-koji168 k
  kernel-tools-libs  i6863.16.0-0.rc2.git0.1.fc21
rawhide-koji 92 k
  kernel-tools-libs-develi6863.16.0-0.rc2.git0.1.fc21
rawhide-koji 88 k
  perf   i6863.16.0-0.rc2.git0.1.fc21
rawhide-koji1.0 M
  python-perfi6863.16.0-0.rc2.git0.1.fc21
rawhide-koji179 k

Transaction Summary


Install  11 Packages

Total size: 46 M
Total download size: 46 M
Installed size: 95 M
Is this ok [y/d/N]:



# dnf clean all
Cleaning repos: rawhide
Cleaning up Everything

# dnf --enablerepo \* clean all
Cleaning repos: fedora-source rawhide-debuginfo fedora updates-debuginfo
rawhide-source updates-testing-debuginfo fedora-debuginfo
fedora-rawhide-kernel-
   : nodebug-debuginfo fedora-rawhide-kernel-nodebug-source
updates-testing fedora-rawhide-kernel-nodebug rawhide
updates-testing-source updates-
   : source rawhide-koji updates
Cleaning up Everything

# dnf --disablerepo \* --enablerepo rawhide-koji install
kernel\*3.16.0-0.rc2.git0.1.fc21\* \*perf\*3.16.0-0.rc2.git0.1.fc21\* -x
\*PAE\* -x \*debug\*
Fedora 21 - i386 - Koji 609 kB/s |  35
MB 00:59
No package kernel*3.16.0-0.rc2.git0.1.fc21* available.
No package *perf*3.16.0-0.rc2.git0.1.fc21* available.
Error: Nothing to do.

# dnf --disablerepo \* --enablerepo rawhide-koji install
kernel\*3.16.0-0.rc2.git0.1.fc21\* \*perf\*3.16.0-0.rc2.git0.1.fc21\* -x
\*PAE\* -x \*debug\*
Fedora 21 - i386 - Koji 609 kB/s |  35
MB 00:59
No package kernel*3.16.0-0.rc2.git0.1.fc21* available.
No package *perf*3.16.0-0.rc2.git0.1.fc21* available.
Error: Nothing to do.

# dnf --disablerepo \* --enablerepo rawhide-koji install
kernel*3.16.0-0.rc2.git0.1.fc21* *perf*3.16.0-0.rc2.git0.1.fc21* -x
*PAE* -x *debug*
No package kernel*3.16.0-0.rc2.git0.1.fc21* available.
No package *perf*3.16.0-0.rc2.git0.1.fc21* available.
Error: Nothing to do.

# dnf --disablerepo=\* --enablerepo=rawhide-koji install
kernel*3.16.0-0.rc2.git0.1.fc21* *perf*3.16.0-0.rc2.git0.1.fc21* -x
*PAE* -x *debug*
No package kernel*3.16.0-0.rc2.git0.1.fc21* available.
No package *perf*3.16.0-0.rc2.git0.1.fc21* available.
Error: Nothing to do.

# dnf --disablerepo=* --enablerepo=rawhide-koji install
kernel*3.16.0-0.rc2.git0.1.

Re: future contributions and package updates jmarrero

[Nikos Roussos]

Hi Joseph,

On Wed, 2014-06-25 at 22:22 -0400, Joseph Marrero wrote:
> Hello,
> My FAS is : jmarrero
> I can not update any of my packages for the time being, will know If I can 
> continue contributing in about a month. I can pass the ownership to who ever 
> wants to maintain the packages I currently own or we can share ownerships if 
> I can still contributing. But will not know my status until august 1st is my 
> best guess.
> The packages I maintain are:
> Fedora:

I would be glad to co-maintain these two:

> mirall
> owncloud-csync



signature.asc
Description: This is a digitally signed message part
-- 
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: setterm syntax changed

[Felix Miata]

On 2014-06-25 23:54 (GMT-0700) Samuel Sieb composed:


Felix Miata wrote:



I think what's order dependent is a bug in the rewrite to require the
double hyphen where previously a single did the job. I tried this:



 setterm --background blue --foreground white --bold --blank 59 --store



That moved the error:



 setterm: argument error: --blank



Perhaps the on/off argument to --bold is no longer optional?


Are you sure your question wasn't rhetorical? No error message following 
--bold with on. :-)

--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct