date:20140126

On Sun, Jan 26, 2014 at 10:42 AM, Lars E. Pettersson l...@homer.se wrote:
 On 01/23/2014 02:04 PM, Richard Hughes wrote:

 On 23 January 2014 12:37, David Howells dhowe...@redhat.com wrote:

 What constitutes an 'application' in this sense?  Does 'gcc' count for
 instance?  How about 'find'?


 No. In the AppStream and AppData definitions, a program is an
 application if it has a .desktop file that is visible in the menu.
 i.e. not NoDisplay=true and that has at least one valid category.


 How is the user then supposed to find gcc, find, or similar
 programs/rpm-packages if these does not show up in 'software center'? Or am
 I missing something obvious here?

gcc isn't an application in a sense of gui application so there is
to ways to install it
either the user installs an IDE which pulls it in as dep or he/she
installs it using yum/dnf.

 How does 'application' correlates to a rpm-package?

Application means GUI application that has a .desktop file.
-- 
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 or Sponser request: the_silver_searcher

2014-01-26 Thread Matthias Runge

On 01/26/2014 09:09 AM, Kenjiro Nakayama wrote:
 Hi, List
 
 Can anyone swap review or take it as sponsor? 
 
 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1008063
 

Kenjiro,

in order to get a package approved, you must be the reporter of a review
request. When looking for a sponsor, it definitely helps, if you review
other packages as well.

Matthias

-- 
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: RFC - Downgrade BlueZ to v4.101 in Fedora 20

2014-01-26 Thread Ralf Corsepius


On 01/24/2014 03:41 AM, Adam Williamson wrote:

On Thu, 2014-01-23 at 21:35 -0500, Orcan Ogetbil wrote:

On Thu, Jan 23, 2014 at 7:33 PM, Kevin Kofler wrote:

David Sommerseth wrote:

So, I wonder if it can be considered to enable a downgrade path for
bluez and depending packages, as described in the Contingency Plan:
https://fedoraproject.org/wiki/Changes/Bluez5


Officially downgrading BlueZ from 5 to 4 in a shipped release is totally
impractical. It just cannot be done realistically. (Contingency plans are
only intended to be enacted BEFORE the release.)


Right. But is it possible to ship a bluez4 package and rebuild the
dependencies against that after the release?


How does that differ, in practice?


Think about compat packages and parallel installation.

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: Heads up; F22 will require applications to ship appdata to be listed in software center

2014-01-26 Thread Lars E. Pettersson


On 01/26/2014 11:08 AM, drago01 wrote:

gcc isn't an application in a sense of gui application so there is
to ways to install it
either the user installs an IDE which pulls it in as dep or he/she
installs it using yum/dnf.


Would it not be better to have a 'software center' that includes ALL 
software available, be they GUI related or not? Probably based on 
rpm-packages, as that is what our system ultimately relies on. A GUI to 
handle ALL software available would be better, than one only installing 
GUI-related software, in my opinion.



How does 'application' correlates to a rpm-package?


Application means GUI application that has a .desktop file.


That makes the 'software center' of lesser use, as the user will be 
confused when he/she does not find the program/rpm-package/application 
he/she wants to install.


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
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: Heads up; F22 will require applications to ship appdata to be listed in software center

2014-01-26 Thread Heiko Adams

Am Sonntag, den 26.01.2014, 12:14 +0100 schrieb Lars E. Pettersson:
 On 01/26/2014 11:08 AM, drago01 wrote:
  gcc isn't an application in a sense of gui application so there is
  to ways to install it
  either the user installs an IDE which pulls it in as dep or he/she
  installs it using yum/dnf.
 
 Would it not be better to have a 'software center' that includes ALL 
 software available, be they GUI related or not? Probably based on 
 rpm-packages, as that is what our system ultimately relies on. A GUI to 
 handle ALL software available would be better, than one only installing 
 GUI-related software, in my opinion.
 
We already got such a software but its no more installed by default:
gnome-packagekit-installer
-- 
Regards,

Heiko Adams



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: Heads up; F22 will require applications to ship appdata to be listed in software center

2014-01-26 Thread Lars E. Pettersson


On 01/26/2014 12:18 PM, Heiko Adams wrote:

Am Sonntag, den 26.01.2014, 12:14 +0100 schrieb Lars E. Pettersson:

...

Would it not be better to have a 'software center' that includes ALL
software available, be they GUI related or not? Probably based on
rpm-packages, as that is what our system ultimately relies on. A GUI to
handle ALL software available would be better, than one only installing
GUI-related software, in my opinion.


We already got such a software but its no more installed by default:
gnome-packagekit-installer


Why is it not installed by default? Users will normally look for GUIs 
for installing software nowadays, so if 
gnome-packagekit-installer/gpk-application complements 'software center' 
by being a GUI based installer including non-gui packages for install, 
it should perhaps be installed by default


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
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.next in 2014 -- Big Picture and Themes

2014-01-26 Thread Aleksandar Kurtakov

- Original Message -
 From: Alec Leamas leamas.a...@gmail.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Sent: Sunday, January 26, 2014 11:22:36 AM
 Subject: Re: Fedora.next in 2014 -- Big Picture and Themes

 On 1/25/14, Adam Williamson awill...@redhat.com wrote:
  On Sat, 2014-01-25 at 12:04 +0100, Alec Leamas wrote:

  After hacking a simple tool which provides a GUI for a repository file
  it's possible to create repository packages complete with  desktop and
  appdata file. I have some 5-10 such repository packages under way, my
  plan is to push them into rpmfusion.

  http://rpmfusion.org/Contributors#Read_the_packaging_guidelines

 I know this is controversial. I've also heard some rumours about
 Fedora using something they call Packaging Guidelines. Has anyone
 some  information  on this topic? ;)

 Can we just for the sake of discussion leave this formal side of it, for now?

  So I found this point interesting in thinking about these issues this
  morning. There was a post of Hughesie's (I think) in another thread
  which was also illuminating: it suggested the design of Software is to
  be a generic 'software' installer - to provide as much 'software' from
  as many sources as possible, under the 'it's all just software' theory,
  I guess.

  I think the assumption that this is obviously the right design is
  interesting, because I strongly disagree - not just for legal or policy
  reasons, but because that's most definitely *not* what I want. I don't
  want a 'greedy' software installer that just finds every piece of crap
  on the internet and offers it to me. I appreciate the curation that

 I don't know if this is  Hughesie's vision. Anyway, it's certainly not
 mine. Adding whatever software available out there to the repos is a
 Bad Idea. Agreed

 That said,, IMHO  we actually need  to be better on delivering what
 people need. Some of this is not in Fedora's repos. This is already
 acknowledged here and there. E. g., rpmfusion has  list of
 repositories which are known to work with rpmfusion [1]. For fedora,
 we have e. g. jpackage, which is stated s compatible in the Java GL.

I feel obligated to comment on this. JPackage and Fedora have taken different 
routes years ago and installing JPackage rpm on top of Fedora will likely break 
Fedora packages due to:
* additional OSGi metadata Fedora ships but JPackage doesn't
* different places of maven pom and depmap changes
* different major versions of the same package (aka maven package in JPackage 
was 1.x (last I checked) but in Fedora it's 3.x) and etc.

Would you please point to a place where jpackage is stated as compatible? This 
is probably a legacy page which needs to be updated with current state of 
affairs so people don't think they can mix and match freely.

Alexander Kurtakov
Red Hat Eclipse team

 I'm trying to find some middle ground here. Instead of just enabling
 repos, perhaps when installing something else, I'm trying  a process
 where each and every repository added is packaged separately. Hence,
 here is also  separate review for each repository. And even if
 installed, it's not enabled until l explicitly configured by user..

 I see all the problems when using things like pip, gem etc. However,
 this is not anything like this. It's about letting users install
 carefully selected repositories which are known to work with Fedora.
 Doing it this way, we also create a difference to other repositories
 which are not endorsed.  Also this is something we need badly IMHO.

 It's also  task which naturally belongs to rpmfusion, mostly the
 non-free section.

 --alec.

 [1] http://rpmfusion.org/FedoraThirdPartyRepos
 --
 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.next in 2014 -- Big Picture and Themes

2014-01-26 Thread Nikos Roussos



Thorsten Leemhuis fed...@leemhuis.info wrote:
On 25.01.2014 17:35, Adam Williamson wrote:
 On Sat, 2014-01-25 at 11:20 +0100, Thorsten Leemhuis wrote:
 
 Debian, who has a similar stance on
 non-free Software, does a way better job in that area than Fedora
does.
 Well, not really - they don't have a 'similar stance', they have an
 official non-free repository. That's kind of a significant
 difference. :)

Ha, Debian and Fedora, the distributions, are imo not that different
after a standard install (but yes, there are differences as well -
patents strategy, Firmware). But yes, you are right, the Debian project
has a a official non-free repository, which is a significant difference
to the Fedora project. One that leads to a better user experience;
something that afics a lot of Fedora users and some Fedoraproject
developers want to see as well.

Let's avoid personal examples. I also know many users and Fedora contributors
that respect Fedora's foundations and would probably leave Fedora if these were 
to change. 

 That's why I think it would be good if
the the Fedora project might help/guide in that are, even if the
resulting repo and the main work is done outside of the Fedora project.

I agree with guidance. I don't think anyone would object to help them, 
so that *they* can ship their software for Fedora in a more UX friendly way. 

-- 
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: RFC - Downgrade BlueZ to v4.101 in Fedora 20

2014-01-26 Thread Tomasz Torcz

On Sat, Jan 25, 2014 at 05:40:22PM +0100, Tomasz Torcz wrote:
 On Fri, Jan 24, 2014 at 01:33:07AM +0100, Kevin Kofler wrote:
  David Sommerseth wrote:
   So, I wonder if it can be considered to enable a downgrade path for
   bluez and depending packages, as described in the Contingency Plan:
   https://fedoraproject.org/wiki/Changes/Bluez5
  
  Officially downgrading BlueZ from 5 to 4 in a shipped release is totally 
  impractical. It just cannot be done realistically. (Contingency plans are 
  only intended to be enacted BEFORE the release.)
  
 
   I think we need to to upgrade PulseAudio to 5.0. That version, with 
 bluetooth audio A2DP support, is currently at ”Release Candidate” stage:
 http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-January/019858.html
 

  After reading more into it… I was mistaken. A2DP is not two-way bluetooth
audio. PA 5 won't fix the headset issue:

#v+
PulseAudio now supports BlueZ 5, but only the A2DP profile. 
BlueZ 4 is still the only way to make HSP/HFP work.
#v-

-- 
Tomasz TorczThere exists no separation between gods and men:
xmpp: zdzich...@chrome.pl   one blends softly casual into the other.

-- 
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: Heads up; F22 will require applications to ship appdata to be listed in software center

On Sun, Jan 26, 2014 at 12:14 PM, Lars E. Pettersson l...@homer.se wrote:
 On 01/26/2014 11:08 AM, drago01 wrote:

 gcc isn't an application in a sense of gui application so there is
 to ways to install it
 either the user installs an IDE which pulls it in as dep or he/she
 installs it using yum/dnf.


 Would it not be better to have a 'software center' that includes ALL
 software available, be they GUI related or not?

No. Installing a non gui app that is invisible to the user does not
make much sense.
The user that knows about the cmd line can just install it from there as well.

Probably based on
 rpm-packages,

No we had that already. A package is an implementation detail. All the
users care about are the applications.

 as that is what our system ultimately relies on. A GUI to
 handle ALL software available would be better, than one only installing
 GUI-related software, in my opinion.

We have some of them already and the user experience is sub par
compared to other plattforms that don't do that.

 How does 'application' correlates to a rpm-package?


 Application means GUI application that has a .desktop file.


 That makes the 'software center' of lesser use, as the user will be confused
 when he/she does not find the program/rpm-package/application he/she wants
 to install.

Installing an application and then not finding it anywhere is
confusing. So we limit it
to visible apps i.e GUI apps.
-- 
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: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]

2014-01-26 Thread Kevin Kofler

Chris Murphy wrote:
 I wouldn't ever expect this with a minor version or security update. I'd
 consider it a complete betrayal of software versioning to do this. In fact
 in certain instances of major version changes, downward compatibility of
 the file format is expected.

The compatibility is often only one way, i.e. newer versions can read older 
config files just fine, but not the other way round.

Kevin Kofler

-- 
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.next in 2014 -- Big Picture and Themes

2014-01-26 Thread Alec Leamas

On 1/26/14, Aleksandar Kurtakov akurt...@redhat.com wrote:

 I feel obligated to comment on this. JPackage and Fedora have taken
 different routes years ago and installing JPackage rpm on top of Fedora will
 likely break Fedora packages due to:
 * additional OSGi metadata Fedora ships but JPackage doesn't
 * different places of maven pom and depmap changes
 * different major versions of the same package (aka maven package in
 JPackage was 1.x (last I checked) but in Fedora it's 3.x) and etc.

 Would you please point to a place where jpackage is stated as compatible?
 This is probably a legacy page which needs to be updated with current state
 of affairs so people don't think they can mix and match freely.

 Alexander Kurtakov
 Red Hat Eclipse team
Oops, bad example it seems. Had the link at hand yesterday, don't find it now.

Now let's drop jpackage in this discussion. It is obviously a bad
example. But in a way, it's also a good one. Given your statement, I
find it highly unlikely that  a packaged jpackage repo would have
survived a package review, if at all submitted. IMHO, this is really
the important issue here.

--alec
-- 
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: Drawing lessons from fatal SELinux bug #1054350

2014-01-26 Thread Kevin Kofler

Dominick Grift wrote:
 I did not mean to suggest that. I meant to suggest that SELinux would be
 able to contain the damage, referring to fatal in: Drawing lessons
 from fatal SELinux bug

And by what magic would it do that? SELinux cannot by its nature contain any 
damage of the the system is broken type, no matter in what component. The 
ONLY type of damage it can possibly contain is a security hole (and even 
there, not all classes of security holes). All those fatal regressions where 
basic system functionality such as upgrading or even logging in is non-
functional can absolutely NOT be fixed by SELinux.

 Actually it is the other way around. SELinux blocks everything by
 default. Everything needs to be explicitly allowed by means of
 configuration

Yes. This default deny attitude is a big part of the problem. (Whenever a 
program covered by a strict policy gets a new feature, the SELinux policy 
has to be updated to allow it, i.e. a duplication of efforts and a 
maintainability nightmare.) But no matter what you configure SELinux to 
allow, it will only work if the program is coded to do it in the first 
place, so you cannot use SELinux to fix a regression in another critical 
component. The only regressions you can possibly fix with an SELinux update 
are regressions in SELinux itself, i.e., the ones that can trivially be 
avoided by disabling SELinux in the first place.

So I still don't follow when you claim SELinux can fix regressions 
elsewhere. That argument just doesn't make sense, sorry.

Kevin Kofler

-- 
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: Drawing lessons from fatal SELinux bug #1054350

2014-01-26 Thread Kevin Kofler

Reindl Harald wrote:
 i am not entirely sure how that is meant
 
 * disable the automatism to push to stable
 * forget the whole karma system at all

 in case of disable the automatism to push to stable i agree

Even just doing that would be an improvement, but I still think the whole 
karma system should go away entirely and the maintainers should have the 
call.

 in my opinion karma is a indication for the maintainer but not
 the decision - the karma has to be handeled differently for the
 same package and different updates and only the maintainer can
 decide that *as person*
 
 why?
 
 because it depends on the change itself

I totally agree that the maintainer should be the one making the call! 
That's why I want the karma stuff removed. :-)

What's the point of keeping that number if we drop the silly Update 
Policies? Shouldn't the maintainer actually READ the comments instead of 
basing the decision on an arbitrary algebraic sum of unweighted +1 and -1 
terms?

 speaking with my developer hat on: there are updates on software
 inside our company where i do not hestitate a single seconds deploy
 the new CMS version to some hundrets of customers without tell anybody
 there was a update at all because *i know* there can be no bad impact
 
 on the other hand there are updates and changes which needs to prepare
 any singel webhost, rollout a small update to prepare the real one by
 add database colums not used currently but need to be there in the time
 window files are replaced and database scheme can be updated
 
 the second case is for not have any single request going wrong
 
 and there is another category where all the work above has to be done
 and tested thousands of times but still need a keep your eyes open
 after it is done because you can't test and verify every single action
 a complex software may do with every possible input data

+1

Kevin Kofler

-- 
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: Heads up; F22 will require applications to ship appdata to be listed in software center

* Lars E. Pettersson [26/01/2014 12:26] :

 Why is it not installed by default?

The last time I used it, it had a number of bugs that made it
unusable (bugs #883435 and bugs #949907 are the first that come to mind).

Emmanuel
-- 
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: SELinux RPM scriplet issue annoucement

2014-01-26 Thread Michael Schwendt

On Fri, 24 Jan 2014 22:36:02 -0800, Adam Williamson wrote:

 Note there's a GUI tool similar to easy karma called gooey karma, waiting for 
 a package sponsor.


We don't sponsor packages but packagers. ;)

Actually, the review request has stalled, waiting for the reviewer (here
also the sponsor because it's the packager's first package) to answer:
https://bugzilla.redhat.com/1020839

And while some package submitters do attempt at contributing a few reviews,
some don't, which makes the process more difficult if all they offer is a
single package.
-- 
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: Heads up; F22 will require applications to ship appdata to be listed in software center

2014-01-26 Thread Les Howell

On Sun, 2014-01-26 at 12:14 +0100, Lars E. Pettersson wrote:
 On 01/26/2014 11:08 AM, drago01 wrote:
  gcc isn't an application in a sense of gui application so there is
  to ways to install it
  either the user installs an IDE which pulls it in as dep or he/she
  installs it using yum/dnf.
 
 Would it not be better to have a 'software center' that includes ALL 
 software available, be they GUI related or not? Probably based on 
 rpm-packages, as that is what our system ultimately relies on. A GUI to 
 handle ALL software available would be better, than one only installing 
 GUI-related software, in my opinion.
 
  How does 'application' correlates to a rpm-package?
 
  Application means GUI application that has a .desktop file.
 
 That makes the 'software center' of lesser use, as the user will be 
 confused when he/she does not find the program/rpm-package/application 
 he/she wants to install.
 
 Lars
 -- 
 Lars E. Pettersson l...@homer.se
 http://www.sm6rpz.se/

Another issue, I think, deals with useful command line tools, such as
python scripts, grep, or such utilities as are yet to be developed.  Not
all things are gui based, and not being gui based doesn't mean that
users won't want or use them.

Even most gui programs that do exist had lots of code developed before
being transferred to a gui.  Working from a command line, with a
compiler and debugger is also a good introduction to the actual
functioning of a computer and gets one closer to the bare iron, which
permits the leveraging of basic knowledge.  Of course, this is just my
personal opinion.  When I work on developing new stuff, the gui is often
put off until I get basic code working.  The gui essentially clothes the
code to simplify the command interface, cut down on typos, and provide
prompts for arguments etc. all to assist the user manage and benefit
from whatever code is run.
regards,
Les H

-- 
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: Heads up; F22 will require applications to ship appdata to be listed in software center

On Sun, Jan 26, 2014 at 5:27 PM, Les Howell hlhow...@pacbell.net wrote:
 On Sun, 2014-01-26 at 12:14 +0100, Lars E. Pettersson wrote:
 On 01/26/2014 11:08 AM, drago01 wrote:
  gcc isn't an application in a sense of gui application so there is
  to ways to install it
  either the user installs an IDE which pulls it in as dep or he/she
  installs it using yum/dnf.

 Would it not be better to have a 'software center' that includes ALL
 software available, be they GUI related or not? Probably based on
 rpm-packages, as that is what our system ultimately relies on. A GUI to
 handle ALL software available would be better, than one only installing
 GUI-related software, in my opinion.

  How does 'application' correlates to a rpm-package?
 
  Application means GUI application that has a .desktop file.

 That makes the 'software center' of lesser use, as the user will be
 confused when he/she does not find the program/rpm-package/application
 he/she wants to install.

 Lars
 --
 Lars E. Pettersson l...@homer.se
 http://www.sm6rpz.se/

 Another issue, I think, [...]

No this isn't an issue at all. No one is saying that non gui apps are
useless or should be removed.
The point is that gui installer installs gui apps. If you want to
install a command line tool whats wrong with
using the command line for that? If you don't know how to use the
command line there is no point in installing
it in the first place.
-- 
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: Heads up; F22 will require applications to ship appdata to be listed in software center

2014-01-26 Thread Rahul Sundaram

Hi


On Sun, Jan 26, 2014 at 11:57 AM, drago01 wrote:


 No this isn't an issue at all. No one is saying that non gui apps are
 useless or should be removed.
 The point is that gui installer installs gui apps. If you want to
 install a command line tool whats wrong with
 using the command line for that? If you don't know how to use the
 command line there is no point in installing
 it in the first place.


I can use yum just fine but I don't find it convenient to go to the gui for
gui apps and then remember to go use yum to install command line apps.

Rahul
-- 
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: Heads up; F22 will require applications to ship appdata to be listed in software center

Am 26.01.2014 18:01, schrieb Rahul Sundaram:
 On Sun, Jan 26, 2014 at 11:57 AM, drago01 wrote:
 
 No this isn't an issue at all. No one is saying that non gui apps are
 useless or should be removed.
 The point is that gui installer installs gui apps. If you want to
 install a command line tool whats wrong with
 using the command line for that? If you don't know how to use the
 command line there is no point in installing
 it in the first place.
 
 I can use yum just fine but I don't find it convenient to go to the gui for 
 gui apps and then 
 remember to go use yum to install command line apps

additionally:

if you teach new users to the software-center they will not really
aprreciate it reading as example that rsync is a cool tool with
command examples in whatever linux magazine and don't find in
that was told them to install software

that leads easily in oh fedora don't have that

if you don't know how to use the commandline is a bad attitude

how do you learn to use it from scratch?
by find examples and commands somewhere in the internet or magazines
___

summary:

a good software-center simply would have two tabs

* graphical software (default)
* command line tools

the command line tools in doubt does not need more than
the description of the RPM packages already present
___

do not forget how *you* learned to deal with your linux system
do not build barriers that complete new users have the same chance



signature.asc
Description: OpenPGP digital 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: Heads up; F22 will require applications to ship appdata to be listed in software center

2014-01-26 Thread Heiko Adams

Am Sonntag, den 26.01.2014, 12:01 -0500 schrieb Rahul Sundaram:
 Hi
 
 
 On Sun, Jan 26, 2014 at 11:57 AM, drago01 wrote:
 
 No this isn't an issue at all. No one is saying that non gui
 apps are
 useless or should be removed.
 The point is that gui installer installs gui apps. If you want
 to
 install a command line tool whats wrong with
 using the command line for that? If you don't know how to use
 the
 command line there is no point in installing
 it in the first place.
 
 
 I can use yum just fine but I don't find it convenient to go to the
 gui for gui apps and then remember to go use yum to install command
 line apps.  
 
Following this logic users have to use yum, dnf, yumex oder
gnome-packagekit-installer to install i.e. additional GUI-Themes or
mouse-cursors because they are no apps and for that reason not listed in
gnome-software, right? If yes, that's IMHO absolute bullshit!

-- 
Regards,

Heiko Adams



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: Heads up; F22 will require applications to ship appdata to be listed in software center

2014-01-26 Thread Michael Scherer

Le dimanche 26 janvier 2014 à 18:14 +0100, Heiko Adams a écrit :
 Am Sonntag, den 26.01.2014, 12:01 -0500 schrieb Rahul Sundaram:
  Hi
  
  
  On Sun, Jan 26, 2014 at 11:57 AM, drago01 wrote:
  
  No this isn't an issue at all. No one is saying that non gui
  apps are
  useless or should be removed.
  The point is that gui installer installs gui apps. If you want
  to
  install a command line tool whats wrong with
  using the command line for that? If you don't know how to use
  the
  command line there is no point in installing
  it in the first place.
  
  
  I can use yum just fine but I don't find it convenient to go to the
  gui for gui apps and then remember to go use yum to install command
  line apps.  
  
 Following this logic users have to use yum, dnf, yumex oder
 gnome-packagekit-installer to install i.e. additional GUI-Themes or
 mouse-cursors because they are no apps and for that reason not listed in
 gnome-software, right? If yes, that's IMHO absolute bullshit!

It would make more sense to install them directly from the tool that set
the mouse cursors, or the theme. Why switch to a different tool ( ie, a
software installer ) to install something that is not a software ?

-- 
Michael Scherer

-- 
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: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]

On Sat, 2014-01-25 at 17:28 -0700, Chris Murphy wrote:
 On Jan 25, 2014, at 12:55 PM, Simo Sorce s...@redhat.com wrote:
 
  The reason is simple: lot's of software *changes* data as part of its
  normal functioning, including and often in rollback-incompatible ways.
  
  You cannot assume that upgrading a program that uses a database X from
  version A to B can still work if you keep database X unchanged and then
  rollback from B to A. Lot of applications apply changes to database at
  upgrade time, either in the rpm scriplets or automatically as soon as a
  new version binary is run.
 
 I wouldn't ever expect this with a minor version or security update.
 I'd consider it a complete betrayal of software versioning to do this.
 In fact in certain instances of major version changes, downward
 compatibility of the file format is expected.

And who ever said 'minor' version ?

However I've done this with minor versions too with internal databases.
There is no betrayal whatsoever, major versions are introduced when you
make user-visible changes or you break an API/ABI, you do not
necessarily change major version for some internal change.

  It is basically impossible to find applications that handle the case
  where you downgrade, in any more graceful way than punting and
 failing
  to start in the *good* case. In the bad case they start and trash
 the
  database.
 
 I guess I'm not really following. Do you have a for instance?

At least 3 or 4 applications I am involved with did this kind of
internal changes.

  Because off hand this sounds like a kind of sabotage to me.

No, it is just normal, everyday, software development.

  If it's throw away database info that can simply be reconstructed I'd
 probably tolerate it. But for that matter, such things should go in an
 defined cache location so that it's not even being backed up.

In some cases it is data that can be reconstructed, so all you need to
do is to manually blow away the files and let the app rebuild them. In
some cases that also have additional inconveniences. In some cases it is
not data you can or want to throw away.

 But important user data having it's format updated in a way that makes
 it incompatible with the previous minor version (same major version)?

So ?
It is only visible if you downgrade which a lot of software do not
support and explicitly so.

  I'm snickering at the language that would ensue in the proprietary
 software world, if I'm not totally confused about what it is you're
 suggested is fair game. It'd be the sort of language you wouldn't want
 your teenager or grandmother to hear.

??

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
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: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]

On Sat, 2014-01-25 at 17:54 -0700, Chris Murphy wrote:
 On Jan 25, 2014, at 4:12 PM, Adam Williamson awill...@redhat.com wrote:
  
  * Do an offline update that includes Foo v2.0
  * Boot the updated system, run Foo, it migrates its configuration to
  some new scheme
  * Realize there was something wrong with the update, roll it back
  * Run Foo again, find it doesn't work because it's been migrated to the
  new config scheme which the old version of Foo doesn't work with
 
 I would grumble, but a configuration file being updated and made
 incompatible with the prior version would be tolerated. Ideally the
 application makes an unmodified copy. If it doesn't, new school
 restore with --reflink from snapshot, regular cp if using LVM thinp
 snapshots, and old school just restore the file from a conventional
 backup. Not such a big deal.
 
 If it's something far less throw away than configuration files being
 changed, it's a bit more complicated how badly and quickly the
 conversation degrades. But I can hardly recall a recent example of
 this happening. It's just not that common in my experience.

What about mail application change the format of the mail folders ?

It happens, and it is *not* data you want to risk throwing away. There
are many other examples like this especially on the server side.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
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: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]

On Sat, 2014-01-25 at 15:04 -0500, Colin Walters wrote:
Hi Simo,

On Sat, 2014-01-25 at 14:55 -0500, Simo Sorce wrote:

The reason is simple: lot's of software *changes* data as part of its
normal functioning, including and often in rollback-incompatible ways.

I wrote and maintain a system that has been doing continuous deployment
of GNOME. It's been running for over a year, and is nearing it's
1th build.

I have rolled back many times - both on the server side, and on the
client side. Here's one I *just did* a few minutes ago because vala git
master broke the build of gnome-calculator:

https://git.gnome.org/browse/gnome-continuous/commit/?id=32a52e53100e92aad5d2dfae969be82227322f49

That's me telling the system please stop building git master, and
freeze to this specific commit. All clients get that change when they
upgrade - OSTree cares not at all for version numbers.

The vala maintainers continue to work out the issue in git master, and I
continue to ship a working system. Double win.

Now it's true, programs in GNOME do sometimes make the type of data
format transition you're talking about. Evolution has done it at least
twice.

But you know what? My real world experience has been that having the
ability to roll back has *far* *far* *far* outweighed the downsides when
applications do format transitions. It's comparatively rare.

Far more people are bit by things like hardware-specific issues where
gnome-shell fails to render on this particular card - and rollback works
beautifully for that.

I never said it won't work in absolute, it probably will work ok in many
cases, just to cause incredible issues in others.

It is a fine tool in the hands of an expert that knows how to check
whether reverting to a snapshot is safe.

It is not going to be a good solution for non-expert users though
*unless* you provide system APIs that *all* applications use to signal
when they are doing irreversible changes so that the user can be warned
about potential data loss right when he asks the system to revert a
snapshot.

Simo.

--
Simo Sorce * Red Hat, Inc * New York

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

Libreoffice-voikko licensing change

2014-01-26 Thread Ville-Pekka Vainio


Hi,

The licensing guidelines say that license changes should be announced on 
this list. In version 4.0 libreoffice-voikko changed from GPLv3+ to dual 
licensing, GPLv3+ or MPLv2.0.


Libreoffice-voikko 4.0 requires libvoikko 3.7 which I built today, so it 
should be in tomorrow Rawhide compose. I will build libreoffice-voikko 
4.0 some time next week.


--
Ville-Pekka Vainio
--
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: glyphicons-halflings-fonts RHBZ#1050805

2014-01-26 Thread Pete Travis


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi, I'd like to swap reviews with someone for a font I've packaged up[1] .

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1050805

- -- 
- -- Pete Travis
 - Fedora Docs Project Leader
 - 'randomuser' on freenode
 - immanet...@fedoraproject.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS5WrhAAoJEL1wZM0+jj2ZxXMH/jV3psuoT5RexCdh8VEHkGnR
80KxAaUAFedRS4807SwGML7bLuUQX8X46jjK1ZAEExivNmgBcvBXdpe8RokEtuUQ
NnRDA5pUrURm0Ku9fJCHYIiK5Zp+QAcb05D9EhVdQV6JkiPL2sSFF/uYKBwchLI7
CHynWxkUnaR7K1H1Sf/lW0NB8FvCMHFlohzSNZgh/3cIk4fZ9WYw0H5orxSbOiSW
bA+jqW0PsUFNWHzTZpLxRGL41e5fapwHV1Rm8KB2PaTUBpDkl4OXFzyQa2GVDS3f
ZxACJjd20Vs+0PhK7PA7maSICAzonQmZgDUlcHjgP92NeqH1ikfzmxR4/MTN7ms=
=bZYU
-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: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]

Am 26.01.2014 20:56, schrieb Chris Murphy:
 What about mail application change the format of the mail folders ?
 
 Good question because I experienced this recently. So the way Apple does this 
 on OS X with Mail, 
 there is no such thing as a mail format change during the life of a major OS 
 version. So major 
 OS versions are 10.7, 10.8, and now 10.9

and you have a warranty for that?

 So it's impossible the mail format would change between 10.7.1 and 10.7.2 in 
 such a way that 10.7.2 
 mail could not be read by the 10.7.1 or 10.7.0 mail application

and you have a warranty for that?
no you do *not*

 I can upgrade and downgrade all along 10.7.x and the file format is the same.

you *think* that

 Recently I learned that there are two mail formats. There's the every day 
 used format that 
 is apparently completely incompatible between major versions of Mail
 I can export 10.8 Mail in this format, and 10.7 Mail can also read it. And 
 even this pissed 
 me off as well as several thousand users (at least) based on Apple's 
 community forums on the 
 subject because most of us expect to be able to directly import 10.7 mail 
 into 10.8 Mail. 

where you prove that what you said above is wrong

 Well, the mail servers regularly get updated by the company I pay for such 
 things, and I've 
 never noticed the change. It uses IMAP so I don't think the server even 
 cares, its just a bunch 
 of folders and files

blabla - nobody talks about the mailserver

the topic is *internal* data of *local* software
you may have luck and nothing happens

with bad luck you even won't realize that there are new mails you never face
because of happy upgrade/downgrade internal caches are accessed with
*undefined bahvior*

any software on that planet will recognize upgrades and convert *internal* data
but nobody will give you a warranty how the same software behaves after a 
downgrade

yes, in most cases nothing bad happens
in rare cases you recognize the problem and find a solution
in some cases you even don't recognize that internal things are slightly going 
wrong



signature.asc
Description: OpenPGP digital 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: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]


On Jan 26, 2014, at 11:41 AM, Simo Sorce s...@redhat.com wrote:

 I never said it won't work in absolute, it probably will work ok in many
 cases, just to cause incredible issues in others.
 
 It is a fine tool in the hands of an expert that knows how to check
 whether reverting to a snapshot is safe.

Why is the snapshot case any different from a user who reverts doing a clean 
install or yum downgrade?


 
 It is not going to be a good solution for non-expert users though
 *unless* you provide system APIs that *all* applications use to signal
 when they are doing irreversible changes so that the user can be warned
 about potential data loss right when he asks the system to revert a
 snapshot.

Developers should not be sneak attacking non-expert users with file format 
changes that aren't well announced in advance of consequences they probably 
won't be able to read their data if they downgrade the application.



Chris Murphy

-- 
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: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]



Am 26.01.2014 21:13, schrieb Chris Murphy:
 On Jan 26, 2014, at 11:41 AM, Simo Sorce s...@redhat.com wrote:
 
 I never said it won't work in absolute, it probably will work ok in many
 cases, just to cause incredible issues in others.

 It is a fine tool in the hands of an expert that knows how to check
 whether reverting to a snapshot is safe.
 
 Why is the snapshot case any different from a user who reverts doing a clean 
 install or yum downgrade?

because the snapshot restores *a whole filesystem* and not only the affected 
application?

* restore a snapshot of /usr and you have fun with /var/lib/rpm
* restore a snapshot of /var/lib/ without /usr and you have fun with the rpmdb 
and others
* restore a snapshot of /usr without /etc and you *may have* random fun

and there are *hundrets* of such combinations where the last thing you
really would want is restore a snapshot because you have no plan about
the real-world impact in doing so

 It is not going to be a good solution for non-expert users though
 *unless* you provide system APIs that *all* applications use to signal
 when they are doing irreversible changes so that the user can be warned
 about potential data loss right when he asks the system to revert a
 snapshot.
 
 Developers should not be sneak attacking non-expert users with file format 
 changes that aren't well 
 announced in advance of consequences they probably won't be able to read 
 their data if they downgrade 
 the application

the perfect world won't happen, sad but true



signature.asc
Description: OpenPGP digital 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: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]

On Sun, 2014-01-26 at 13:13 -0700, Chris Murphy wrote:
 On Jan 26, 2014, at 11:41 AM, Simo Sorce s...@redhat.com wrote:
 
  I never said it won't work in absolute, it probably will work ok in many
  cases, just to cause incredible issues in others.
  
  It is a fine tool in the hands of an expert that knows how to check
  whether reverting to a snapshot is safe.
 
 Why is the snapshot case any different from a user who reverts doing a
 clean install or yum downgrade?

It is not.

  It is not going to be a good solution for non-expert users though
  *unless* you provide system APIs that *all* applications use to signal
  when they are doing irreversible changes so that the user can be warned
  about potential data loss right when he asks the system to revert a
  snapshot.
 
 Developers should not be sneak attacking non-expert users with file
 format changes that aren't well announced in advance of consequences
 they probably won't be able to read their data if they downgrade the
 application.

Users should not expect miracles either.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
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: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]


On Jan 26, 2014, at 12:51 PM, Reindl Harald h.rei...@thelounge.net wrote:

 
 Am 26.01.2014 20:45, schrieb Chris Murphy:
 So ?
 It is only visible if you downgrade which a lot of software do not
 support and explicitly so
 
 The right way to do file format changes is you design the new format. 
 And in a minor version update, the application gains the ability to 
 read the new file format, but still writes the old file format. 
 The major version upgrade of the application is enabled to write the 
 new file format, while it can read either old or new formats.
 
 please look at the hidden folders in your userhome and /var/lib/
 to get a picture about what we are talking here

This sounds like FUD and there's no actual real world example. You're 
suggesting that if I have gnome-shell 3.10.3 and I either yum downgrade to 
3.10.1, or I do a clean install of Fedora 20 and get gnome-shell 3.10.0, that 
I'm going to see explosions? What's going to happen? Surely there aren't such 
significant configuration format changes between such minor versions, and 
surely the development teams anticipate this very use case where uses have a 
/home with such files, and have no choice but to revert to an older system with 
the same major version but lower minor version.

This is why changing configuration formats is hopefully a conscientious 
decision and not done willy nilly. From many years of experience I know I can 
reliably upgrade and downgrade at will, within minor versions of OS X - that is 
all versions of 10.7.x configuration file wise are expected to be compatible. 
And I'd exclude disposable cache files which by default aren't even backed up 
anyway as they're expected to be rebuilt on a restore.

Chris Murphy

-- 
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: I want to turn on a part of the kernel to make SELinux checking more stringent.

2014-01-26 Thread Richard W.M. Jones

Slightly OT, but is SELinux stopping programs from executing code at
address zero?  (And how can I stop it doing that?)

JONESFORTH, a public domain FORTH I wrote, is written in x86 assembler
and prefers to put its threaded interpreter at address 0.  This worked
fine before, but has now stopped working, and this is reported to be
due to SELinux.

http://rwmj.wordpress.com/2010/08/07/jonesforth-git-repository/#comment-6591


Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
-- 
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: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]



Am 26.01.2014 21:30, schrieb Chris Murphy:
 On Jan 26, 2014, at 12:51 PM, Reindl Harald h.rei...@thelounge.net wrote:
 Am 26.01.2014 20:45, schrieb Chris Murphy:
 So ?
 It is only visible if you downgrade which a lot of software do not
 support and explicitly so

 The right way to do file format changes is you design the new format. 
 And in a minor version update, the application gains the ability to 
 read the new file format, but still writes the old file format. 
 The major version upgrade of the application is enabled to write the 
 new file format, while it can read either old or new formats.

 please look at the hidden folders in your userhome and /var/lib/
 to get a picture about what we are talking here
 
 This sounds like FUD and there's no actual real world example

* i do not know what *may happen* by restore a snapshot
* you do not know what *may* happen by restore a snapshot
* nobody knows

why?

because nobody *can* know what exactly packages, versions are installed
in which combination or which *user specific* data may exist on exactly
the FS which is restored *additionally* to what the system sofware knows

frankly you can have your kwallet or the files your browser stores
passwords you recently created and thought they are safe on exactly
that FS, and they *maybe* saved *between* upgrade, realize a problem
and restore the snapshot

again: *nobody* knows for sure the *complete possible impact* on the
users computer by restore a snapshot because a upgrade should be
rolled back

surely, you can do that, i and many other people won't do this now
nor in the future for good reasons and not knowing *exactly* any
possible impact of a operation is a *damned good* reason

nothing more to say about that topic because

* i *never* won't do that
* i *never* would use LVM
* i *never* use BTRFS
* so my environment even does not support that snapshots

why i won#t use BTRFS/LVM?

because my drives are a Linux RAID10 and i never re-installed my system from
scratch nor would i do that in the future and *because* not everybody is using
a storage even supports snapshots it would be a bad idea to rely on that



signature.asc
Description: OpenPGP digital 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: I want to turn on a part of the kernel to make SELinux checking more stringent.

2014-01-26 Thread Andrew Lutomirski

On Sun, Jan 26, 2014 at 12:38 PM, Richard W.M. Jones rjo...@redhat.com wrote:
 Slightly OT, but is SELinux stopping programs from executing code at
 address zero?  (And how can I stop it doing that?)

 JONESFORTH, a public domain FORTH I wrote, is written in x86 assembler
 and prefers to put its threaded interpreter at address 0.  This worked
 fine before, but has now stopped working, and this is reported to be
 due to SELinux.

IIRC, in new kernels, /proc/sys/vm/mmap_min_addr and MAC policy both
have to allow the mmap call.  In older kernels, only one of them had
to allow it.

Maybe some day SMAP-capable machines (e.g. Haswell, I think) will
ignore these settings entirely -- I think that SMAP covers all the
cases that mmap_min_addr was meant to pretect against.

--Andy


 http://rwmj.wordpress.com/2010/08/07/jonesforth-git-repository/#comment-6591


 Rich.

 --
 Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
 virt-df lists disk usage of guests without needing to install any
 software inside the virtual machine.  Supports Linux and Windows.
 http://people.redhat.com/~rjones/virt-df/
 --
 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: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]

On Sun, 2014-01-26 at 12:45 -0700, Chris Murphy wrote:
 I still really have no idea what sorts of changes you're talking
 about.

I think you made it abundantly clear :-)

I am also sure what I wanted to convey to people that understand what I
am talking about is also clear. So I think the matter has been expressed
well enough for devel and I do not think we need to further pollute the
list.

Thank you,
Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
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: I want to turn on a part of the kernel to make SELinux checking more stringent.

On Sun, Jan 26, 2014 at 9:38 PM, Richard W.M. Jones rjo...@redhat.com wrote:
 Slightly OT, but is SELinux stopping programs from executing code at
 address zero?  (And how can I stop it doing that?)

 JONESFORTH, a public domain FORTH I wrote, is written in x86 assembler
 and prefers to put its threaded interpreter at address 0.  This worked
 fine before, but has now stopped working, and this is reported to be
 due to SELinux.

 http://rwmj.wordpress.com/2010/08/07/jonesforth-git-repository/#comment-6591

Maybe you just need to set /proc/sys/vm/mmap_min_addr to 0 ? But
that's a bad idea as it makes kernel bugs (null pointer deference)
easy to exploit.
-- 
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: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]


On Jan 26, 2014, at 1:07 PM, Reindl Harald h.rei...@thelounge.net wrote:

 Am 26.01.2014 20:56, schrieb Chris Murphy:
 What about mail application change the format of the mail folders ?
 
 Good question because I experienced this recently. So the way Apple does 
 this on OS X with Mail, 
 there is no such thing as a mail format change during the life of a major OS 
 version. So major 
 OS versions are 10.7, 10.8, and now 10.9
 
 and you have a warranty for that?

It's a long standing expectation and tradition, and considering millions of 
users had this sort of behavior occurred by now no doubt I'd have heard about 
it.

 
 I can upgrade and downgrade all along 10.7.x and the file format is the same.
 
 you *think* that

If there is a change, it's not a downward incompatible change.

 
 Recently I learned that there are two mail formats. There's the every day 
 used format that 
 is apparently completely incompatible between major versions of Mail
 I can export 10.8 Mail in this format, and 10.7 Mail can also read it. And 
 even this pissed 
 me off as well as several thousand users (at least) based on Apple's 
 community forums on the 
 subject because most of us expect to be able to directly import 10.7 mail 
 into 10.8 Mail. 
 
 where you prove that what you said above is wrong

No you just have reading comprehension problem. The minor versions are 
compatible. The major versions aren't.


 Well, the mail servers regularly get updated by the company I pay for such 
 things, and I've 
 never noticed the change. It uses IMAP so I don't think the server even 
 cares, its just a bunch 
 of folders and files
 
 blabla - nobody talks about the mailserver

Jerk. Simo said, in the line right above this that you cut: There are many 
other examples like this especially on the server side.



 the topic is *internal* data of *local* software
 you may have luck and nothing happens

This was not at all made clear from the start, it was assumed by people who 
understood. I explicitly asked if I was on the same page or not. Instead of 
bringing me up to speed, you decide to be condescending. Congratulations on 
your rudeness.


 with bad luck you even won't realize that there are new mails you never face
 because of happy upgrade/downgrade internal caches are accessed with
 *undefined bahvior*

Email are user documents the same as a Libreoffice document. You do not get to 
say that just because it's a semi-hidden database, that its file format is 
allowed to change in a downward incompatible manner. I will disagree with that 
position at every possible turn as something between sloppy programming and 
dereliction.

 
 any software on that planet will recognize upgrades and convert *internal* 
 data
 but nobody will give you a warranty how the same software behaves after a 
 downgrade

Well insofar as the whole software EULA paradigm basically says for any reason, 
willful or not, they can blow up your data in any direction possible and there 
is no liability claim whatsoever… what you're saying doesn't even apply to 
upgrades.

 yes, in most cases nothing bad happens
 in rare cases you recognize the problem and find a solution
 in some cases you even don't recognize that internal things are slightly 
 going wrong

It's no worse a risk than a conventional reversion with a clean install. So I 
fail to see how any of this relates to snapshots.


Chris Murphy
-- 
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: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]



Am 26.01.2014 21:56, schrieb Chris Murphy:
 On Jan 26, 2014, at 1:07 PM, Reindl Harald h.rei...@thelounge.net wrote:
 Well, the mail servers regularly get updated by the company I pay for such 
 things, and I've 
 never noticed the change. It uses IMAP so I don't think the server even 
 cares, its just a bunch 
 of folders and files

 blabla - nobody talks about the mailserver
 
 Jerk. Simo said, in the line right above this that you cut: There are many 
 other examples like this especially on the server side.

be careful in which context you somebody calls a Jerk

 the topic is *internal* data of *local* software
 you may have luck and nothing happens
 
 This was not at all made clear from the start, it was assumed by people who 
 understood

because that people thought somebody with that much replies
to the thread would have understodd the topic

 I explicitly asked if I was on the same page or not. Instead of bringing me 
 up to speed, 
 you decide to be condescending. Congratulations on your rudeness

as you can see some lines above you needed *exactly* that way of comminucation
to understand what we are talking about in this thread - this is the *dvel* list
and so technical understanding is implicit in a discussion

 with bad luck you even won't realize that there are new mails you never face
 because of happy upgrade/downgrade internal caches are accessed with
 *undefined bahvior*
 
 Email are user documents the same as a Libreoffice document. You do not get 
 to say that just 
 because it's a semi-hidden database, that its file format is allowed to 
 change in a downward 
 incompatible manner

what exactly did you not understand in the two words internal caches
frankly i faced mail clients where you needed to remove the complete
IMAP account to stop not display any new or moved message in specific
folders

 any software on that planet will recognize upgrades and convert *internal* 
 data
 but nobody will give you a warranty how the same software behaves after a 
 downgrade
 
 Well insofar as the whole software EULA paradigm basically says for any 
 reason, willful 
 or not, they can blow up your data in any direction possible and there is no 
 liability 
 claim whatsoever… what you're saying doesn't even apply to upgrades.

google for undefined behavior

 yes, in most cases nothing bad happens
 in rare cases you recognize the problem and find a solution
 in some cases you even don't recognize that internal things are slightly 
 going wrong
 
 It's no worse a risk than a conventional reversion with a clean install

well, i never re-installed any linux system in my life for good reasons
the same reasons i never would restore a snapshot of my whole filesystem
or even more worse *a complete tree* alone of it

 So I fail to see how any of this relates to snapshots

that you fail to see the possible impact of a snapshot-restore is obviously
and you do not need to repeat that again and again




signature.asc
Description: OpenPGP digital 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: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]



Am 26.01.2014 21:56, schrieb Chris Murphy:
 No you just have reading comprehension problem. The minor versions are 
 compatible. The major versions aren't

one last question: what are firefox updates 25-26-27
minor, major, dunno?

more and more software has no minor/major splitting at all
systemd, firefox, chrome..

what warranties do you have?
none!

what warranties did you ever have?
none as long the specific devloper did not make any promises
luck is no warranty as well as until now is not



signature.asc
Description: OpenPGP digital 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: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]


On Jan 26, 2014, at 1:18 PM, Reindl Harald h.rei...@thelounge.net wrote:

 
 
 Am 26.01.2014 21:13, schrieb Chris Murphy:
 On Jan 26, 2014, at 11:41 AM, Simo Sorce s...@redhat.com wrote:
 
 I never said it won't work in absolute, it probably will work ok in many
 cases, just to cause incredible issues in others.
 
 It is a fine tool in the hands of an expert that knows how to check
 whether reverting to a snapshot is safe.
 
 Why is the snapshot case any different from a user who reverts doing a clean 
 install or yum downgrade?
 
 because the snapshot restores *a whole filesystem* and not only the affected 
 application?

If I knew the problem was with a particular affected application, why would I 
be using a snapshot rollback approach or clean install rather than a yum 
downgrade app approach?
 
 * restore a snapshot of /usr and you have fun with /var/lib/rpm
 * restore a snapshot of /var/lib/ without /usr and you have fun with the 
 rpmdb and others
 * restore a snapshot of /usr without /etc and you *may have* random fun
 
 and there are *hundrets* of such combinations where the last thing you
 really would want is restore a snapshot because you have no plan about
 the real-world impact in doing so

Well what sort of moron would do rollbacks like this? You're saying if someone 
puts a stick of dynamite in their mouth then ZOMG! going to die!, but not 
accounting for why they would put dynamite in their mouth in the first place. 
This is simply not how rollbacks are done. Yes there are hundreds of 
mindnumbingly stupid ways a user could break their system. No one is 
recommending rollbacks that work the way you describe.


Chris Murphy

-- 
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: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]



Am 27.01.2014 00:26, schrieb Chris Murphy:
 On Jan 26, 2014, at 1:18 PM, Reindl Harald h.rei...@thelounge.net wrote:
 Am 26.01.2014 21:13, schrieb Chris Murphy:
 On Jan 26, 2014, at 11:41 AM, Simo Sorce s...@redhat.com wrote:

 I never said it won't work in absolute, it probably will work ok in many
 cases, just to cause incredible issues in others.

 It is a fine tool in the hands of an expert that knows how to check
 whether reverting to a snapshot is safe.

 Why is the snapshot case any different from a user who reverts doing a 
 clean install or yum downgrade?

 because the snapshot restores *a whole filesystem* and not only the affected 
 application?
 
 If I knew the problem was with a particular affected application, why would I 
 be using a snapshot rollback approach or clean install rather than a yum 
 downgrade app approach?

 * restore a snapshot of /usr and you have fun with /var/lib/rpm
 * restore a snapshot of /var/lib/ without /usr and you have fun with the 
 rpmdb and others
 * restore a snapshot of /usr without /etc and you *may have* random fun

 and there are *hundrets* of such combinations where the last thing you
 really would want is restore a snapshot because you have no plan about
 the real-world impact in doing so
 
 Well what sort of moron would do rollbacks like this? You're saying if 
 someone puts a stick of dynamite in their mouth then ZOMG! going to die!, but 
 not accounting for why they would put dynamite in their mouth in the first 
 place. This is simply not how rollbacks are done. Yes there are hundreds of 
 mindnumbingly stupid ways a user could break their system. No one is 
 recommending rollbacks that work the way you describe.

do yourself and everybody a favour and

* don't claim others are rude while you talk like above and worser half of the 
thread
* don't talk about things above your technical scope
* discuss with software engineers while lacking basic understanding of the topic

posts like yours in that thread belongs to the users list and *not* to a 
development list



signature.asc
Description: OpenPGP digital 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: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]


On Jan 26, 2014, at 1:40 PM, Reindl Harald h.rei...@thelounge.net wrote:

 
 
 Am 26.01.2014 21:30, schrieb Chris Murphy:
 On Jan 26, 2014, at 12:51 PM, Reindl Harald h.rei...@thelounge.net wrote:
 Am 26.01.2014 20:45, schrieb Chris Murphy:
 So ?
 It is only visible if you downgrade which a lot of software do not
 support and explicitly so
 
 The right way to do file format changes is you design the new format. 
 And in a minor version update, the application gains the ability to 
 read the new file format, but still writes the old file format. 
 The major version upgrade of the application is enabled to write the 
 new file format, while it can read either old or new formats.
 
 please look at the hidden folders in your userhome and /var/lib/
 to get a picture about what we are talking here
 
 This sounds like FUD and there's no actual real world example
 
 * i do not know what *may happen* by restore a snapshot
 * you do not know what *may* happen by restore a snapshot
 * nobody knows

Great, well I'll tell you what. I will just keep living dangerously, and when I 
find a real world case of this, I'll file a bug. How about that?

 because nobody *can* know what exactly packages, versions are installed
 in which combination or which *user specific* data may exist on exactly
 the FS which is restored *additionally* to what the system sofware knows
 
 frankly you can have your kwallet or the files your browser stores
 passwords you recently created and thought they are safe on exactly
 that FS, and they *maybe* saved *between* upgrade, realize a problem
 and restore the snapshot

Oh for f's sake. And *maybe* the next time I take a shower I'll slip and fall, 
so I'll just decide now to not bathe ever again. This hysterical paranoia 
you're going on about is even less hypothetical than slipping in the bathroom. 
I read this buttkiss nonsense and feel like someone has injected my brain with 
novocaine. 


 again: *nobody* knows for sure the *complete possible impact* on the
 users computer by restore a snapshot because a upgrade should be
 rolled back.

Well you know what I think, is that applications should largely be self 
contained instead of sneezing all kinds of crap all over my file system. It's 
one of the best examples of why I prefer using OS X compared to Windows, which 
are drag and drop installation of applications that don't install weird junk 
all over my computer. Very very easy to rollback from this.



 
 surely, you can do that, i and many other people won't do this now
 nor in the future for good reasons and not knowing *exactly* any
 possible impact of a operation is a *damned good* reason
 
 nothing more to say about that topic because
 
 * i *never* won't do that
 * i *never* would use LVM
 * i *never* use BTRFS
 * so my environment even does not support that snapshots

Uh huh. So this is sort like a user coming onto this forum and talking trash 
about all of linux and Fedora and what all is broken and doesn't fit their use 
case or workflow at all, and then after 50 f'n emails they say they never use 
linux or Fedora. Even for you this is an especially egregious waste of time and 
brain cells. I can even feel the rot occurring in my brain from reading this 
mindnumbing   nonsense you've written in this whole thread, and the icing on 
the cake is that you don't even use the technologies you're bitching about. 
Bitch, bitch, bitch. That's the only thing you've accomplished. You're just 
bitching. It's f'n annoying.

 
 why i won#t use BTRFS/LVM?
 
 because my drives are a Linux RAID10 and i never re-installed my system from
 scratch nor would i do that in the future and *because* not everybody is using
 a storage even supports snapshots it would be a bad idea to rely on that

I think you having access to a computer with internet access is a bad idea.


Chris Murphy

-- 
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: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]


Am 27.01.2014 00:41, schrieb Chris Murphy:
 Great, well I'll tell you what. I will just keep living dangerously, and when 
 I find a real world case of this, I'll file a bug. How about that?

do that, your problem

 because nobody *can* know what exactly packages, versions are installed
 in which combination or which *user specific* data may exist on exactly
 the FS which is restored *additionally* to what the system sofware knows

 frankly you can have your kwallet or the files your browser stores
 passwords you recently created and thought they are safe on exactly
 that FS, and they *maybe* saved *between* upgrade, realize a problem
 and restore the snapshot
 
 Oh for f's sake. And *maybe* the next time I take a shower I'll slip and fall

off-topic

you do not understand anything this theard is about so why not leaves us in 
peace?

 It's one of the best examples of why I prefer using OS X compared to Windows

then use it

 nothing more to say about that topic because

 * i *never* won't do that
 * i *never* would use LVM
 * i *never* use BTRFS
 * so my environment even does not support that snapshots
 
 Uh huh. So this is sort like a user coming onto this forum and talking trash 
 about all of linux and Fedora and what all is broken and doesn't fit their 
 use 
 case or workflow at all, and then after 50 f'n emails they say they never use 
 linux or Fedora

you do not understand the intention of that thread at all
so why you don't just listen and be quite?

 I think you having access to a computer with internet access is a bad idea

must be why i get paid for server-adminstration and security for a decade...
please bother the users-lists where i am no longer subscribed because people
like you leading to get upset again and again




signature.asc
Description: OpenPGP digital 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: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]


On Jan 26, 2014, at 4:29 PM, Reindl Harald h.rei...@thelounge.net wrote:

 do yourself and everybody a favour and
 
 * don't claim others are rude while you talk like above and worser half of 
 the thread
 * don't talk about things above your technical scope
 * discuss with software engineers while lacking basic understanding of the 
 topic
 
 posts like yours in that thread belongs to the users list and *not* to a 
 development list

Request declined.

You are the only person who has suggested a method of rollbacks that 
fundamentally would not work, and then argued against it. You created what's 
referred to as, a strawman argument. Also known as being full of crap. So you 
can take your silly logical fallacies and mock victimization and stick 'em 
where the sun don't shine, Reindl. Put it all right back where you got your 
ridiculous snapshot-rollback concept.

Chris Murphy

-- 
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: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]



Am 27.01.2014 00:51, schrieb Chris Murphy:
 On Jan 26, 2014, at 4:29 PM, Reindl Harald h.rei...@thelounge.net wrote:
 
 do yourself and everybody a favour and

 * don't claim others are rude while you talk like above and worser half of 
 the thread
 * don't talk about things above your technical scope
 * discuss with software engineers while lacking basic understanding of the 
 topic

 posts like yours in that thread belongs to the users list and *not* to a 
 development list
 
 Request declined.
 
 You are the only person who has suggested a method of rollbacks that 
 fundamentally would not work

are you drunken?

i have *not* requested any method of rollback

i just gave a few warnings what problems has to be considered if rollbacks
of snapshots are taken as possible solution - so *stop* talk to threads if
you have no clue about the topic and about who said what

* read what others said
* start at the begin of the thread doing that
* try to understand what you read before commetn any word
* look at the *context* of several posts becaus eoyu need that information to 
understand
* after that claim what people suggested or in reality you would say nothing at 
all




signature.asc
Description: OpenPGP digital 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: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]

2014-01-26 Thread Kevin Fenzi

I don't think this subthread is being particularly useful... 

And the personal attacks are undesirable. 

Please stop or at least take it to private email. 

Thanks,

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: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]


On Jan 26, 2014, at 4:47 PM, Reindl Harald h.rei...@thelounge.net wrote:

 
 Am 27.01.2014 00:41, schrieb Chris Murphy:
 Great, well I'll tell you what. I will just keep living dangerously, and 
 when I find a real world case of this, I'll file a bug. How about that?
 
 do that, your problem
 
 because nobody *can* know what exactly packages, versions are installed
 in which combination or which *user specific* data may exist on exactly
 the FS which is restored *additionally* to what the system sofware knows
 
 frankly you can have your kwallet or the files your browser stores
 passwords you recently created and thought they are safe on exactly
 that FS, and they *maybe* saved *between* upgrade, realize a problem
 and restore the snapshot
 
 Oh for f's sake. And *maybe* the next time I take a shower I'll slip and fall
 
 off-topic
 
 you do not understand anything this theard is about so why not leaves us in 
 peace?

I'll add rampant hyperbole to your list of personal attributes. I'm the one who 
doesn't understand anything even though you don't use or have any use for 
snapshots, and you also want no one to have them or it'll make developers 
careless:

On Jan 25, 2014, at 6:10 PM, Reindl Harald h.rei...@thelounge.net wrote:

 the short version of ahwat you said could have been forget snapshots at all 
 to solve
 such problems to not lead dvelopers into temptation of i can be less caeful 
 because
 we have snapshots
 
 in other words: don't work around problems by create new ones 


And then you propose a ridonkulous snapshot-rollback strategy that would for 
certain cause major problems if the rollback were actually done, and then use 
that as fait accompli for why the entire concept of fs rollbacks are stupid. 
Your arguments are asinine. Your emails belong in a kill file.


Chris Murphy

-- 
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: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]



Am 27.01.2014 01:07, schrieb Chris Murphy:

 And then you propose a ridonkulous snapshot-rollback strategy that would for 
 certain cause major problems 
 if the rollback were actually done

*the opposite is true because i WARNED of doing snapshots*



signature.asc
Description: OpenPGP digital 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: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]



Am 27.01.2014 00:57, schrieb Kevin Fenzi:
 I don't think this subthread is being particularly useful... 
 
 And the personal attacks are undesirable. 
 Please stop or at least take it to private email

*sorry* for not early enough realize trolling in first start with
the same argumentation as Simon and me to later fight against it
while now claim i came up with the idea of snapshots while
warning all the time and tried to explain Chris *why* i
warn

 Original-Nachricht 
Betreff: Re: Drawing lessons from fatal SELinux bug #1054350
Datum: Sat, 25 Jan 2014 16:42:13 -0700
Von: Chris Murphy li...@colorremedies.com
Antwort an: Development discussions related to Fedora 
devel@lists.fedoraproject.org
An: Development discussions related to Fedora devel@lists.fedoraproject.org

I don't follow this. The realization an update is bad doesn't necessarily occur 
right away. So we still need a way
to separate system domain vs user domain, at least, so that system files are 
rolled back separately from user files

___

can someone *please stop that troll telling lies*

 And then you propose a ridonkulous snapshot-rollback strategy that would for 
 certain cause
 major problems if the rollback were actually done, and then use that as fait 
 accompli for
 why the entire concept of fs rollbacks are stupid. Your arguments are 
 asinine. Your emails
 belong in a kill file.



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

guided/interactive/scripted tutorials

2014-01-26 Thread Ian Malone

I'm looking for something and not quite sure what it's called.
In thinking about what the music SIG can do to add value I've hit on
wondering whether it's possible to write desktop-based guided
tutorials without having to interfere in the application in question
itself (otherwise you have to persuade every upstream to build it
separately in their codebase, even if it's in their interest to do so
that's a massive duplication of effort). You may have used this kind
of thing - it tells you 'click this next' and waits until you do.
As you might expect, googling for anything along these lines without
having a very precise set of keywords only returns pages of tutorials.
Any suggestions what to look for or, even better, tools in Fedora that
can already do this appreciated.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]


On Jan 26, 2014, at 4:55 PM, Reindl Harald h.rei...@thelounge.net wrote:

 
 
 Am 27.01.2014 00:51, schrieb Chris Murphy:
 On Jan 26, 2014, at 4:29 PM, Reindl Harald h.rei...@thelounge.net wrote:
 
 do yourself and everybody a favour and
 
 * don't claim others are rude while you talk like above and worser half of 
 the thread
 * don't talk about things above your technical scope
 * discuss with software engineers while lacking basic understanding of the 
 topic
 
 posts like yours in that thread belongs to the users list and *not* to a 
 development list
 
 Request declined.
 
 You are the only person who has suggested a method of rollbacks that 
 fundamentally would not work
 
 are you drunken?

I haven't had anything to drink in 24+ hours, but this seems off topic.
 
 i have *not* requested any method of rollback

You gave several examples of rollback-snapshot methods - same thing as you 
suggested them. I never said you requested them.

 
 i just gave a few warnings what problems has to be considered if rollbacks
 of snapshots are taken as possible solution - so *stop* talk to threads if
 you have no clue about the topic and about who said what

Yes, problems as a result of improper rollback methods. I will not stop 
challenging junk suggestions which you then use to cast a wide net to argue 
against all forms of snapshotting and rollback. It's absurd argumentation.


 * read what others said
 * start at the begin of the thread doing that
 * try to understand what you read before commetn any word
 * look at the *context* of several posts becaus eoyu need that information to 
 understand
 * after that claim what people suggested or in reality you would say nothing 
 at all

Take your own advice. I've been following the thread from the very start, and 
your snapshot-rollback examples are all junk. Just for instance:

On Jan 26, 2014, at 1:18 PM, Reindl Harald h.rei...@thelounge.net wrote:

 * restore a snapshot of /usr and you have fun with /var/lib/rpm
 * restore a snapshot of /var/lib/ without /usr and you have fun with the 
 rpmdb and others
 * restore a snapshot of /usr without /etc and you *may have* random fun


Only you have come up with such utterly implausible examples of 
snapshot-rollback behavior and then chosen to argue against *all* possible 
snapshot-rollbacks in general. No one would do rollbacks the way you describe 
above. It would almost certainly break the system.


Chris Murphy

-- 
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: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]



Am 27.01.2014 01:18, schrieb Chris Murphy:
 On Jan 26, 2014, at 4:55 PM, Reindl Harald h.rei...@thelounge.net wrote:
 Am 27.01.2014 00:51, schrieb Chris Murphy:
 On Jan 26, 2014, at 4:29 PM, Reindl Harald h.rei...@thelounge.net wrote:

 do yourself and everybody a favour and

 * don't claim others are rude while you talk like above and worser half of 
 the thread
 * don't talk about things above your technical scope
 * discuss with software engineers while lacking basic understanding of the 
 topic

 posts like yours in that thread belongs to the users list and *not* to a 
 development list

 Request declined.

 You are the only person who has suggested a method of rollbacks that 
 fundamentally would not work

 are you drunken?
 
 I haven't had anything to drink in 24+ hours, but this seems off topic.

 i have *not* requested any method of rollback
 
 You gave several examples of rollback-snapshot methods - same thing as you 
 suggested them. I never said you requested them

oh my god - i gave several examples *what could be dangerous* in doing that
i *never* ever suggested them
please re-read the thread and then come back with an excuse



signature.asc
Description: OpenPGP digital 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: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]


On Jan 26, 2014, at 5:10 PM, Reindl Harald h.rei...@thelounge.net wrote:

 
 
 Am 27.01.2014 01:07, schrieb Chris Murphy:
 
 And then you propose a ridonkulous snapshot-rollback strategy that would for 
 certain cause major problems 
 if the rollback were actually done
 
 *the opposite is true because i WARNED of doing snapshots*

Yes, you argued against the general case of snapshot-rollbacks while using bad 
examples of rollback methods that would obviously cause problems.


Chris Murphy

-- 
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: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]


On Jan 26, 2014, at 5:20 PM, Reindl Harald h.rei...@thelounge.net wrote:

 
 
 Am 27.01.2014 01:18, schrieb Chris Murphy:
 On Jan 26, 2014, at 4:55 PM, Reindl Harald h.rei...@thelounge.net wrote:
 Am 27.01.2014 00:51, schrieb Chris Murphy:
 On Jan 26, 2014, at 4:29 PM, Reindl Harald h.rei...@thelounge.net wrote:
 
 do yourself and everybody a favour and
 
 * don't claim others are rude while you talk like above and worser half 
 of the thread
 * don't talk about things above your technical scope
 * discuss with software engineers while lacking basic understanding of 
 the topic
 
 posts like yours in that thread belongs to the users list and *not* to a 
 development list
 
 Request declined.
 
 You are the only person who has suggested a method of rollbacks that 
 fundamentally would not work
 
 are you drunken?
 
 I haven't had anything to drink in 24+ hours, but this seems off topic.
 
 i have *not* requested any method of rollback
 
 You gave several examples of rollback-snapshot methods - same thing as you 
 suggested them. I never said you requested them
 
 oh my god - i gave several examples *what could be dangerous* in doing that
 i *never* ever suggested them
 please re-read the thread and then come back with an excuse


suggested them can mean two things in English: you recommend them, or they 
are examples. I mean the 2nd case. I understand that you were not ever 
recommending your examples. You were suggesting them as examples why snapshots 
in general are bad.

The problem is that your examples are crap. They're bad examples because they 
would break the system, therefore no one would actually do snapshots-rollbacks 
per your examples, unless they wanted to blow up their system.


Chris Murphy
-- 
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: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]



Am 27.01.2014 01:32, schrieb Chris Murphy:
 On Jan 26, 2014, at 5:20 PM, Reindl Harald h.rei...@thelounge.net wrote:
 Am 27.01.2014 01:18, schrieb Chris Murphy:
 You gave several examples of rollback-snapshot methods - same thing as you 
 suggested them. I never said you requested them

 oh my god - i gave several examples *what could be dangerous* in doing that
 i *never* ever suggested them
 please re-read the thread and then come back with an excuse
 
 suggested them can mean two things in English: you recommend them, or they 
 are examples. I mean the 2nd case. I understand that you were not ever 
 recommending your examples. You were suggesting them as examples why 
 snapshots in general are bad.
 
 The problem is that your examples are crap. They're bad examples because they 
 would break the system, therefore no one would actually do 
 snapshots-rollbacks per your examples, unless they wanted to blow up their 
 system.

boah the fact therefore no one would actually do snapshots-rollbacks per your 
examples needs to be proven
i only just warned about cases where a rollback would do harm and to *make 
sure* that really no one would
do it without take care

so where is now the point you started a flamewar against me instead
be quite or say ok, that would be bad and hopefully does not happen

this is a *dvelopent dicussion* and the goal of it is to *prevent*
mistakes ever happen *before* they are implemented or widely used



signature.asc
Description: OpenPGP digital 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: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]


On Jan 26, 2014, at 5:37 PM, Reindl Harald h.rei...@thelounge.net wrote:

 
 
 Am 27.01.2014 01:32, schrieb Chris Murphy:
 On Jan 26, 2014, at 5:20 PM, Reindl Harald h.rei...@thelounge.net wrote:
 Am 27.01.2014 01:18, schrieb Chris Murphy:
 You gave several examples of rollback-snapshot methods - same thing as you 
 suggested them. I never said you requested them
 
 oh my god - i gave several examples *what could be dangerous* in doing that
 i *never* ever suggested them
 please re-read the thread and then come back with an excuse
 
 suggested them can mean two things in English: you recommend them, or they 
 are examples. I mean the 2nd case. I understand that you were not ever 
 recommending your examples. You were suggesting them as examples why 
 snapshots in general are bad.
 
 The problem is that your examples are crap. They're bad examples because 
 they would break the system, therefore no one would actually do 
 snapshots-rollbacks per your examples, unless they wanted to blow up their 
 system.
 
 boah the fact therefore no one would actually do snapshots-rollbacks per 
 your examples needs to be proven

Really? That seems like saying no one would stick dynamite in their mouth 
unless they wanted to die needs to be proven. I think it will only take a 
handful of such instances to convince most rational people this isn't a good 
course of action.


 i only just warned about cases where a rollback would do harm and to *make 
 sure* that really no one would
 do it without take care

That was my *entire* point going back around 36 hours ago…

 Chris Murphy wrote:
 If there is a directory that contains update and non-update related file
 changes, that's a problem. If there's segmentation, then this can be done.
 
 Clearly /home needs to be separate (it's OK to take a snapshot but just
 don't use it by default in a rollback) or we lose changes in /home in a
 rollback from the time of the snapshot to the time of the decision to
 rollback.
 
 Another possible case it's /etc/ where the either a package or the user
 could make changes during the update.



 so where is now the point you started a flamewar against me instead
 be quite or say ok, that would be bad and hopefully does not happen

I did in fact state your examples were FUD. Where the flaming starts is when 
you said blabla - nobody talks about the mailserver when Simo *had* just 
mentioned server side changes which is what I was responding to. And blabla 
is just f'n rude from the outset, so yeah I'm going to be a bit of a dick when 
someone is a.) condescending, b.) says no one said X when someone did in fact 
say X; and c.) deletes the reply where someone said X; and d.) proceeds with a 
dozen emails about how I'm the one not paying attention when I asked for 
context clarification and you decided to jump down my throat and it went 
downhill quickly from there.

I do mostly just monitor this list, for several years. When people jump on you, 
are you quiet? No, you jump right back and you argue like hell. So don't tell 
me that I should be quiet, or how I should respond. From my perspective you 
were picking a fight, so I decide to play along and maybe mine was a little bit 
disproportionate of a response, but don't play victim just because you got 
burned.



 this is a *dvelopent dicussion* and the goal of it is to *prevent*
 mistakes ever happen *before* they are implemented or widely used

Which is exactly why I've involved myself in a thread on snapshotting because 
unlike you, I have been doing snapshots and rollbacks with LVM and Btrfs for 
quite a few years. I'm aware that there are some challenges that users will 
likely face and development needs to account for these things so they aren't 
easily getting into trouble or confused about where their data is.

Snapshots are a reality, simply sticking our head in the sand for a feature 
people have been asking for is simply not the way forward. I am not suggesting 
at all that your workflow should change to include snapshots, so I ask that you 
have the courtesy to not claim with bad examples that snapshots generally are a 
bad idea that will hose user's systems and make developers lazy and careless. 
This is an entirely voluntary project, you are not required to participate in 
some aspect of its technology you don't use and seem to not even care about.



Chris Murphy

-- 
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: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]

Am 27.01.2014 02:11, schrieb Chris Murphy:
 i only just warned about cases where a rollback would do harm and to *make 
 sure* that really no one would
 do it without take care

 That was my *entire* point going back around 36 hours ago

and that is why i do not understand your turn around 180 degree
against Simo and me beause *we both supported* your initial
viewpoint until you started to claim all the cases are invalid

 I did in fact state your examples were FUD

with no reason to do so

 Where the flaming starts is when you said blabla - nobody talks about the 
 mailserver
 when Simo *had* just mentioned server side changes which is what I was 
 responding to

hmpf - read again - server side changes != mailservers
after that you told about Apple Mail and what not and then switeched to 
mailservers
my problem was that you truned 180 degree and fighted against any argument going
in the direction where restore of snapshots may be tricky and dangerous while 
you
orginally before the subject changed even said the same

 And blabla is just f'n rude from the outset

because i had already enough of the turn 180 degree around and your
again and again argumentation about user documents and that they
don't change their format while never said that with a single line

 so yeah I'm going to be a bit of a dick when someone is a.) condescending, 
 b.) says
 no one said X when someone did in fact say X

still: nobody said mailserver, but forget it

 and c.) deletes the reply where someone said X

server side changes doe snot imply change *the format* how mails itself are 
stored

 and d.) proceeds with a dozen emails about how I'm the one not paying 
 attention when I
 asked for context clarification and you decided to jump down my throat and it 
 went
 downhill quickly from there.

then you maybe should have asked *only* about clarification instead start
calling developers names if they would change the format of user documents
which was *never* part of the context

 I do mostly just monitor this list, for several years. When people jump on 
 you,
 are you quiet?

no, but i am not a dickhead and listen if people telling me that
talking about user documents is not any part of the discussion
in case of downgrades and internal environment data of applications
may have changed unnoticed

 No, you jump right back and you argue like hell. So don't tell me that I
 should be quiet, or how I should respond

and if you really would look you have noticed a difference

 From my perspective you were picking a fight

if that would be true i have called you a lot of names in the public
which i *really* avoided while with some replies you begged for it

 so I decide to play along

why?

 and maybe mine was a little bit disproportionate of a response

a little? come on!

 but don't play victim just because you got burned

please calm more down and re-read the whole thread including the point
Simo even gave up completly to try explain you the context

 Which is exactly why I've involved myself in a thread on snapshotting because 
 unlike you, I have been doing snapshots and rollbacks with LVM and Btrfs for 
 quite a few years. 

i statet that i do not use snapshots nor the graphical stuf fnor gnome to make
clear *i am not affected* of any decision in that direction but *care* about
others, otherwise the whole sub-thread would not have been relevant for me

 I'm aware that there are some challenges that users will likely face and 
 development
 needs to account for these things so they aren't easily getting into trouble 
 or confused 
 about where their data is.

which was my whole point

 Snapshots are a reality, simply sticking our head in the sand for a feature 
 people 
 have been asking for is simply not the way forward. I am not suggesting at 
 all that 
 your workflow should change to include snapshots, so I ask that you have the 
 courtesy 
 to not claim with bad examples that snapshots generally are a bad idea that 
 will hose 
 user's systems and make developers lazy and careless

i did not say anything about snapshots in general
the topic is snapshots in case of updates and make it easy to roll them back
this needs *a lot of special care* that is my whole point

 This is an entirely voluntary project, you are not required to participate in 
 some 
 aspect of its technology you don't use and seem to not even care about

sorry that i case about the project in general



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

icecat or/and firefox?

2014-01-26 Thread Christopher Meng

Hi,

Here is an interesting package icecat[1], which is a more free
version firefox.

Do we allow this in Fedora now?

Thanks.

[1]--https://bugzilla.redhat.com/show_bug.cgi?id=1048493
--

Yours sincerely,
Christopher Meng

Noob here.

http://cicku.me
-- 
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: icecat or/and firefox?

2014-01-26 Thread punto...@libero.it


Il 27/01/2014 05:08, Christopher Meng ha scritto:

Hi,

Here is an interesting package icecat[1], which is a more free
version firefox.

Do we allow this in Fedora now?

Thanks.

[1]--https://bugzilla.redhat.com/show_bug.cgi?id=1048493
--

Yours sincerely,
Christopher Meng

Noob here.

http://cicku.me

hi

've tried, i prefer firefox...

regards
gil


attachment: puntogil.vcf-- 
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: I want to turn on a part of the kernel to make SELinux checking more stringent.

2014-01-26 Thread Matthew Garrett

On Sun, Jan 26, 2014 at 08:38:25PM +, Richard W.M. Jones wrote:

 JONESFORTH, a public domain FORTH I wrote, is written in x86 assembler
 and prefers to put its threaded interpreter at address 0.

Can you change its preference? Permitting the mapping of executable code 
at address 0 makes it much easier to exploit null pointer 
vulnerabilities in the kernel. Recent (within the past few years…) 
kernels will refuse to let you mmap stuff below 64K or so regardless of 
selinux policy, so this may break on other distributions as well.

-- 
Matthew Garrett | mj...@srcf.ucam.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

Re: icecat or/and firefox?

2014-01-26 Thread Kenjiro Nakayama

 've tried, i prefer firefox... 

Actually firefox is easy to use and quick in developing. 
But please read [1]. 
icecat solves it, and that is why I want to use icecat in Fedora.

[1] http://www.gnu.org/philosophy/javascript-trap.html

Kenjiro

- 元のメッセージ -
差出人: punto...@libero.it
宛先: devel@lists.fedoraproject.org
送信済み: 2014年1月27日, 月曜日 午後 1:26:42
件名: Re: icecat or/and firefox?

Il 27/01/2014 05:08, Christopher Meng ha scritto: 



Hi,

Here is an interesting package icecat[1], which is a more free
version firefox.

Do we allow this in Fedora now?

Thanks.

[1]--https://bugzilla.redhat.com/show_bug.cgi?id=1048493
--

Yours sincerely,
Christopher Meng

Noob here. http://cicku.me 
hi 


've tried, i prefer firefox... 

regards 
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
-- 
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: icecat or/and firefox?

2014-01-26 Thread Rahul Sundaram

Hi


On Sun, Jan 26, 2014 at 11:08 PM, Christopher Meng cicku...@gmail.comwrote:

 Hi,

 Here is an interesting package icecat[1], which is a more free
 version firefox.

 Do we allow this in Fedora now?

 Thanks.

 [1]--https://bugzilla.redhat.com/show_bug.cgi?id=1048493
 --


I would say we do but if you are in doubt, file a ticket with packaging
committee

Rahul
-- 
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: icecat or/and firefox?

2014-01-26 Thread Ralf Corsepius


On 01/27/2014 05:08 AM, Christopher Meng wrote:

Hi,

Here is an interesting package icecat[1], which is a more free
version firefox.

Do we allow this in Fedora now?


My view:  It's a package like any arbitrary other. So, if it complies 
to the rules applied elsewhere, I don't see much reasons why it can not 
be part of Fedora.


I am having doubts on whether it's long-term maintainable (esp. 
security-wise) and would not want to exclude their may exist legal 
issues, but these are different stories.


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: Source string contextualization

2014-01-26 Thread पराग़

Hi Nilamdyuti,


On Fri, Jan 24, 2014 at 5:52 PM, Nilamdyuti Goswami ngosw...@redhat.comwrote:

 Hi all,

 While translating some of the fedora packages we often come across some
 source strings whose context or meaning is not clear. This results in wrong
 translations which is discovered later while using the actual application.
 This in turn effects the concerned application.

 To solve this issue, we have formed a Fedora SIG named Source String
 Contextualizing Group [1] aimed at
 providing concise yet meaningful description of the concerned source
 strings in the source code itself to ensure the correctness and quality in
 the resulting translations.


I see iok project have many locales available for translations in iok
package so maybe you people can help in improving source translation
strings by providing patches in bugzilla or upstream tracker. This is
really helpful to let translators understand the exact context of the
source string. This will help to have more accurate translations.

Regards,
Parag.
-- 
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: Source string contextualization

2014-01-26 Thread Nilamdyuti Goswami



On 27-01-2014 12:34 অপৰাহ্ন, Parag N(पराग़) wrote:

Hi Nilamdyuti,


On Fri, Jan 24, 2014 at 5:52 PM, Nilamdyuti Goswami 
ngosw...@redhat.com mailto:ngosw...@redhat.com wrote:


Hi all,

While translating some of the fedora packages we often come across
some source strings whose context or meaning is not clear. This
results in wrong translations which is discovered later while
using the actual application. This in turn effects the concerned
application.

To solve this issue, we have formed a Fedora SIG named Source
String Contextualizing Group [1] aimed at
providing concise yet meaningful description of the concerned
source strings in the source code itself to ensure the correctness
and quality in the resulting translations.


I see iok project have many locales available for translations in iok 
package so maybe you people can help in improving source translation 
strings by providing patches in bugzilla or upstream tracker. This is 
really helpful to let translators understand the exact context of the 
source string. This will help to have more accurate translations.

Regards,
Parag.
Thanks Parag for pointing out a package and providing your valuable 
suggestion. We shall work on the same.


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

File Future-0.23.tar.gz uploaded to lookaside cache by eseyman

A file has been added to the lookaside cache for perl-Future:

8a7e7909cf2906fe785474e6a24bf314  Future-0.23.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Future] Update to 0.23

commit e41c0c50a23fb60b21dd05146300e58b46490aaf
Author: Emmanuel Seyman emman...@seyman.fr
Date:   Sun Jan 26 11:08:10 2014 +0100

Update to 0.23

 .gitignore   |1 +
 perl-Future.spec |5 -
 sources  |2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index bf83136..0303771 100644
--- a/.gitignore
+++ b/.gitignore
@@ -8,3 +8,4 @@
 /Future-0.20.tar.gz
 /Future-0.21.tar.gz
 /Future-0.22.tar.gz
+/Future-0.23.tar.gz
diff --git a/perl-Future.spec b/perl-Future.spec
index 72dfaae..c47ed76 100644
--- a/perl-Future.spec
+++ b/perl-Future.spec
@@ -1,5 +1,5 @@
 Name:   perl-Future
-Version:0.22
+Version:0.23
 Release:1%{?dist}
 Summary:Perl object system to represent an operation awaiting 
completion
 License:GPL+ or Artistic
@@ -46,6 +46,9 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 
2/dev/null \;
 %{_mandir}/man3/*
 
 %changelog
+* Sun Jan 26 2014 Emmanuel Seyman emman...@seyman.fr - 0.23-1
+- Update to 0.23
+
 * Sun Jan 12 2014 Emmanuel Seyman emman...@seyman.fr - 0.22-1
 - Update to 0.22
 
diff --git a/sources b/sources
index da3e042..5388cd8 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-d18a1a16ab1bba18a1a0a5e2efadb2d3  Future-0.22.tar.gz
+8a7e7909cf2906fe785474e6a24bf314  Future-0.23.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

File Mojolicious-4.69.tar.gz uploaded to lookaside cache by eseyman

A file has been added to the lookaside cache for perl-Mojolicious:

4ed78d660f0fb705dff2a32ba77cef68  Mojolicious-4.69.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Mojolicious] Update to 4.69

commit 3f934b4c41191a7799062442601d62abed4ba814
Author: Emmanuel Seyman emman...@seyman.fr
Date:   Sun Jan 26 11:17:00 2014 +0100

Update to 4.69

 .gitignore|1 +
 perl-Mojolicious.spec |5 -
 sources   |2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index b6a767b..9e224eb 100644
--- a/.gitignore
+++ b/.gitignore
@@ -113,3 +113,4 @@ Mojolicious-0.26.tar.gz
 /Mojolicious-4.63.tar.gz
 /Mojolicious-4.66.tar.gz
 /Mojolicious-4.67.tar.gz
+/Mojolicious-4.69.tar.gz
diff --git a/perl-Mojolicious.spec b/perl-Mojolicious.spec
index ee0e7d9..272579f 100644
--- a/perl-Mojolicious.spec
+++ b/perl-Mojolicious.spec
@@ -1,5 +1,5 @@
 Name:   perl-Mojolicious
-Version:4.67
+Version:4.69
 Release:1%{?dist}
 Summary:A next generation web framework for Perl
 License:Artistic 2.0
@@ -60,6 +60,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Sun Jan 26 2014 Emmanuel Seyman emman...@seyman.fr - 4.69-1
+- Update to 4.69
+
 * Sun Jan 12 2014 Emmanuel Seyman emman...@seyman.fr - 4.67-1
 - Update to 4.67
 
diff --git a/sources b/sources
index 206c6e3..4321d24 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-7b830a89b0639391df193d0ed774881b  Mojolicious-4.67.tar.gz
+4ed78d660f0fb705dff2a32ba77cef68  Mojolicious-4.69.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

File URI-Escape-XS-0.11.tar.gz uploaded to lookaside cache by eseyman

A file has been added to the lookaside cache for perl-URI-Escape-XS:

712fa7dea1e3dc6852bbb87c16a1fb26  URI-Escape-XS-0.11.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-URI-Escape-XS] Update to 0.11

commit d9f461c13fc88b5f3b56a0ba775cd8f11a2344e5
Author: Emmanuel Seyman emman...@seyman.fr
Date:   Sun Jan 26 11:22:02 2014 +0100

Update to 0.11

 .gitignore  |1 +
 perl-URI-Escape-XS.spec |7 +--
 sources |2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 3111afa..5c97614 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
 /URI-Escape-XS-0.10.tar.gz
+/URI-Escape-XS-0.11.tar.gz
diff --git a/perl-URI-Escape-XS.spec b/perl-URI-Escape-XS.spec
index b946e22..fc9ca4b 100644
--- a/perl-URI-Escape-XS.spec
+++ b/perl-URI-Escape-XS.spec
@@ -1,6 +1,6 @@
 Name:   perl-URI-Escape-XS
-Version:0.10
-Release:5%{?dist}
+Version:0.11
+Release:1%{?dist}
 Summary:Drop-In replacement for URI::Escape
 License:GPL+ or Artistic
 
@@ -49,6 +49,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Sun Jan 26 2014 Emmanuel Seyman emman...@seyman.fr - 0.11-1
+- Update to 0.11
+
 * Sun Aug 04 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 0.10-5
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
 
diff --git a/sources b/sources
index 23caf82..8b4cab4 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-23453334534498de37a758de3b077793  URI-Escape-XS-0.10.tar.gz
+712fa7dea1e3dc6852bbb87c16a1fb26  URI-Escape-XS-0.11.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

File Locale-Maketext-Lexicon-0.98.tar.gz uploaded to lookaside cache by corsepiu

2014-01-26 Thread corsepiu

A file has been added to the lookaside cache for perl-Locale-Maketext-Lexicon:

d7011e111e945251ebdaad9a73910eea  Locale-Maketext-Lexicon-0.98.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Locale-Maketext-Lexicon] Upstream update.

2014-01-26 Thread corsepiu

commit a2b93b9a8ef5d455517ea14c5426709878e0dce8
Author: Ralf Corsépius corse...@fedoraproject.org
Date:   Sun Jan 26 11:47:51 2014 +0100

Upstream update.

 .gitignore|2 +-
 perl-Locale-Maketext-Lexicon.spec |7 +--
 sources   |2 +-
 3 files changed, 7 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index ec9ebee..360e11b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/Locale-Maketext-Lexicon-0.97.tar.gz
+/Locale-Maketext-Lexicon-0.98.tar.gz
diff --git a/perl-Locale-Maketext-Lexicon.spec 
b/perl-Locale-Maketext-Lexicon.spec
index 8b47633..288cb2e 100644
--- a/perl-Locale-Maketext-Lexicon.spec
+++ b/perl-Locale-Maketext-Lexicon.spec
@@ -1,6 +1,6 @@
 Name:  perl-Locale-Maketext-Lexicon
-Version:   0.97
-Release:   2%{?dist}
+Version:   0.98
+Release:   1%{?dist}
 Summary:   Extract translatable strings from source
 License:   MIT
 Group: Development/Libraries
@@ -65,6 +65,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Sun Jan 26 2014 Ralf Corsépius corse...@fedoraproject.org - 0.98-1
+- Upstream update.
+
 * Wed Jan 22 2014 Ralf Corsépius corse...@fedoraproject.org - 0.97-2
 - Reflect Lingua::EN::Sentence having made it into Fedora.
 
diff --git a/sources b/sources
index c515549..1d5d98b 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-88d779875c8986cfba998363cb73be77  Locale-Maketext-Lexicon-0.97.tar.gz
+d7011e111e945251ebdaad9a73910eea  Locale-Maketext-Lexicon-0.98.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Catalyst-Controller-HTML-FormFu



perl-Catalyst-Controller-HTML-FormFu has broken dependencies in the rawhide 
tree:
On x86_64:
perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires 
perl(HTML::FormFu::MultiForm)
On i386:
perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires 
perl(HTML::FormFu::MultiForm)
On armhfp:
perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires 
perl(HTML::FormFu::MultiForm)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-qpid_proton



perl-qpid_proton has broken dependencies in the rawhide tree:
On x86_64:
perl-qpid_proton-0.6-1.fc21.x86_64 requires perl(qpid_proton)
perl-qpid_proton-0.6-1.fc21.x86_64 requires 
perl(qpid::proton::ExceptionHandling)
On i386:
perl-qpid_proton-0.6-1.fc21.i686 requires perl(qpid_proton)
perl-qpid_proton-0.6-1.fc21.i686 requires 
perl(qpid::proton::ExceptionHandling)
On armhfp:
perl-qpid_proton-0.6-1.fc21.armv7hl requires perl(qpid_proton)
perl-qpid_proton-0.6-1.fc21.armv7hl requires 
perl(qpid::proton::ExceptionHandling)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: mojomojo



mojomojo has broken dependencies in the rawhide tree:
On x86_64:
mojomojo-1.10-1.fc20.noarch requires 
perl(HTML::FormFu::Element::reCAPTCHA)
On i386:
mojomojo-1.10-1.fc20.noarch requires 
perl(HTML::FormFu::Element::reCAPTCHA)
On armhfp:
mojomojo-1.10-1.fc20.noarch requires 
perl(HTML::FormFu::Element::reCAPTCHA)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Language-Expr



perl-Language-Expr has broken dependencies in the rawhide tree:
On x86_64:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
On i386:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
On armhfp:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1058004] New: perl-Event-RPC-1.04 is available

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

Bug ID: 1058004
   Summary: perl-Event-RPC-1.04 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Event-RPC
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 1.04
Current version/release in Fedora Rawhide: 1.03-3.fc20
URL: http://search.cpan.org/dist/Event-RPC/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=0K8mW0BjaEa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1058005] New: perl-File-Fetch-0.48 is available

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

Bug ID: 1058005
   Summary: perl-File-Fetch-0.48 is available
   Product: Fedora
   Version: rawhide
 Component: perl-File-Fetch
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 0.48
Current version/release in Fedora Rawhide: 0.46-1.fc21
URL: http://search.cpan.org/dist/File-Fetch/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=xobTTqENqWa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1058007] New: perl-Module-Load-Conditional-0.62 is available

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

Bug ID: 1058007
   Summary: perl-Module-Load-Conditional-0.62 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Module-Load-Conditional
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 0.62
Current version/release in Fedora Rawhide: 0.60-1.fc21
URL: http://search.cpan.org/dist/Module-Load-Conditional/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=D87bO0hYzka=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1058006] New: perl-Module-Load-0.30 is available

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

Bug ID: 1058006
   Summary: perl-Module-Load-0.30 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Module-Load
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 0.30
Current version/release in Fedora Rawhide: 0.28-1.fc21
URL: http://search.cpan.org/dist/Module-Load/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=NfgWDAHleDa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1058009] New: perl-Text-CSV_XS-1.03 is available

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

Bug ID: 1058009
   Summary: perl-Text-CSV_XS-1.03 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Text-CSV_XS
  Keywords: FutureFeature, Triaged
  Assignee: psab...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org, psab...@redhat.com



Latest upstream release: 1.03
Current version/release in Fedora Rawhide: 1.02-1.fc21
URL: http://search.cpan.org/dist/Text-CSV_XS/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=sD3g8yg4SUa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Array-Diff] Get rid of pointless in-place edit flag in perl filter invocation

commit 50739827cfe5c1b4a14a4aaa16b10f73173ed6c1
Author: Paul Howarth p...@city-fan.org
Date:   Sun Jan 26 13:33:14 2014 +

Get rid of pointless in-place edit flag in perl filter invocation

 perl-Array-Diff.spec |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
---
diff --git a/perl-Array-Diff.spec b/perl-Array-Diff.spec
index 4d1f6c7..4b9fe35 100644
--- a/perl-Array-Diff.spec
+++ b/perl-Array-Diff.spec
@@ -1,5 +1,5 @@
 # Only need manual requires for use base XXX; prior to rpm 4.9
-%global rpm49 %(rpm --version | perl -pi -e 's/^.* 
(\\d+)\\.(\\d+).*/sprintf(%d.%03d,$1,$2) ge 4.009 ? 1 : 0/e')
+%global rpm49 %(rpm --version | perl -p -e 's/^.* 
(\\d+)\\.(\\d+).*/sprintf(%d.%03d,$1,$2) ge 4.009 ? 1 : 0/e')
 
 Name:   perl-Array-Diff
 Version:0.07
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-File-chdir/el6] (16 commits) ...Merge branch 'master' (early part) into el6

Summary of changes:

  67c10db... Fix typo that causes a failure to update the common directo (*)
  419207d... - rebuild against perl 5.10.1 (*)
  2ce0679... - Mass rebuild with perl-5.12.0 (*)
  7d5fa1b... - Mass rebuild with perl-5.12.0 (*)
  331023d... dist-git conversion (*)
  b74b87c... - 661697 rebuild for fixing problems with vendorach/lib (*)
  7d194c5... - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass (*)
  3e98401... Perl mass rebuild (*)
  9165e12... update to 0.1003 to fix perl-5.14 FTBFS (*)
  055da92... 0.1006 bump (*)
  ab8e8bd... Perl 5.16 rebuild (*)
  c7c9a9d... - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass (*)
  ac252aa... 1.007 bump (*)
  fdd82be... Correct changelog entry (*)
  4531d0f... 0.1008 bump (*)
  6dcec53... Merge branch 'master' (early part) into el6

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-File-chdir/el6: 16/16] Merge branch 'master' (early part) into el6

commit 6dcec5345e8789fb548e449ad1d05377677e354c
Merge: a32694e 4531d0f
Author: Paul Howarth p...@city-fan.org
Date:   Sun Jan 26 14:00:36 2014 +

Merge branch 'master' (early part) into el6

Conflicts:
.gitignore

 .gitignore   |2 +-
 perl-File-chdir.spec |   68 +
 sources  |2 +-
 3 files changed, 53 insertions(+), 19 deletions(-)
---
diff --cc .gitignore
index 8e8f8b7,8f299ae..75a9c44
--- a/.gitignore
+++ b/.gitignore
@@@ -1,1 -1,5 +1,1 @@@
--File-chdir-0.09.tar.gz
 -/File-chdir-0.1003.tar.gz
 -/File-chdir-0.1006.tar.gz
 -/File-chdir-0.1007.tar.gz
 -/File-chdir-0.1008.tar.gz
++/File-chdir-[0-9.]*.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-File-chdir] Created tag perl-File-chdir-0.1008-1.el6

The lightweight tag 'perl-File-chdir-0.1008-1.el6' was created pointing to:

 6dcec53... Merge branch 'master' (early part) into el6
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1033515] Retire perl-Class-Data-Inheritable in EPEL6

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

Paul Howarth p...@city-fan.org changed:

   What|Removed |Added

 CC||p...@city-fan.org
  Flags||fedora-cvs?



--- Comment #2 from Paul Howarth p...@city-fan.org ---
Package Change Request
==
Package Name: perl-Class-Data-Inheritable
New Branches: el6
Owners: pghmcfc
InitialCC: perl-sig

Unretirement request as per https://fedorahosted.org/rel-eng/ticket/5842

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=DbUxiQg7Aza=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1033514] Retire perl-Class-Accessor in EPEL6