Re: I want to turn on a part of the kernel to make SELinux checking more stringent.

[Till Maas]

On Fri, Jan 24, 2014 at 04:32:54PM +0100, Lennart Poettering wrote:

> Do we really need a service for this? Can't this be done instead via a
> tmpfiles snippet that uses "f" and the extra argument at the end?
> 
> I mean I am not convinced it's worth involving shell here. Also the
> canonical way to write things to /proc or /sys is
> {/etc,/usr/lib/}/sysctl.d/ and {/etc,/usr/lib/}/tmpfiles.d/ if it's
> simple and static. And I don't see why we shouldn't do this differently
> in this case than in all others...

Using tmpfiles.d for this is not very obvious. Who would expect that a
service intended to handle temporary files is used for configuration?
For example the man page says:

| tmpfiles.d — Configuration for creation, deletion and cleaning of
| volatile and temporary files

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

Review swap or Sponser request: the_silver_searcher

[Kenjiro Nakayama]

Hi, List

Can anyone swap review or take it as sponsor? 

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

Regards,

Kenjiro Nakayama 
Red Hat K.K.
Ebisu Neonato 8F, 1-18 Ebisu 4-chome,
Shibuya-ku, Tokyo, Japan 150-0013

-- 
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

[Alec Leamas]

On 1/25/14, Adam Williamson  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'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

Re: Heads up; F22 will require applications to ship appdata to be listed in software center

[Lars E. Pettersson]

On 01/23/2014 02:04 PM, Richard Hughes wrote:

On 23 January 2014 12:37, David Howells  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?


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

Lars
--
Lars E. Pettersson 
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

[drago01]

On Sun, Jan 26, 2014 at 10:42 AM, Lars E. Pettersson  wrote:
> On 01/23/2014 02:04 PM, Richard Hughes wrote:
>>
>> On 23 January 2014 12:37, David Howells  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

[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

[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":



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

[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 
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

[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

[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 
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

[Aleksandar Kurtakov]

- Original Message -
> From: "Alec Leamas" 
> To: "Development discussions related to Fedora" 
> 
> 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  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

[Nikos Roussos]

Thorsten Leemhuis  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

[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":
> > > 
> > 
> > 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

[drago01]

On Sun, Jan 26, 2014 at 12:14 PM, 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?

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]

[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

[Alec Leamas]

On 1/26/14, Aleksandar Kurtakov  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

[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

[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

[Emmanuel Seyman]

* 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

[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

[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 
> 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

[drago01]

On Sun, Jan 26, 2014 at 5:27 PM, Les Howell  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 
>> 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

[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

[Reindl Harald]

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

[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

[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]

[Simo Sorce]

On Sat, 2014-01-25 at 17:28 -0700, Chris Murphy wrote:
> On Jan 25, 2014, at 12:55 PM, 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.
> > 
> > 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]

[Simo Sorce]

On Sat, 2014-01-25 at 17:54 -0700, Chris Murphy wrote:
> On Jan 25, 2014, at 4:12 PM, Adam Williamson  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]

[Simo Sorce]

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

[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

Re: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]

[Chris Murphy]

On Jan 26, 2014, at 11:35 AM, Simo Sorce  wrote:

> On Sat, 2014-01-25 at 17:28 -0700, Chris Murphy wrote:
>> On Jan 25, 2014, at 12:55 PM, 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.
>>> 
>>> 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 ?

I'm saying it. I don't expect the behavior you describe with minor version or 
security updates.
> 
> 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.

Again, are we talking user data or configuration files? 

If a minor version update of LibreOffice were to read my documents and write 
them out in a new format that the prior version could not read? I'm actually 
confused by how I'd react - honestly. I'm not sure if I'd file a bug with "this 
must be a bug, is it intended" or if I'd come out a public list with guns 
blazing and accuse the development team of gross incompetency (and that, 
honestly, would be kind language).


>>> 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.


I still really have no idea what sorts of changes you're talking about. Maybe 
database people are really tolerant of format changes compared to average Joe 
user's expectations of downward compatibility with music, movie, and various 
document formats? If so, we're talking about different contexts.

> 
>> 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.


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.


>> 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.
> 
> ??

If Adobe Photoshop version n.1.0 started to write out Photoshop documents in a 
manner that n.0.0 could not read, 100% of users would call it a major bug, and 
it would escalate into vicious name calling - not just of Adobe the company and 
its shareholders, but specific individuals would get called out like an old 
Western gun fight. It would be nasty. It's a scary and hilarious mental 
exercise to think of what might happen but also ridiculous because of that. It 
simply wouldn't happen because of the holy hellfire that would ensue. New swear 
words would be invented by end users.

About the closest thing I can think of was almost 10 years ago when Nikon 
"encrypted" their white balance metadata in Raw files, instigated after a 
camera firmware update. The language used by professional photographers started 
out with "WTF this is bullshit" and escalated from there. If I repeated some of 
the common phrases from respected professional photographer colleagues of mine 
on this list, I'd probably

Re: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]

[Reindl Harald]

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

> If Adobe Photoshop version n.1.0 started to write out Photoshop documents 
> in a manner that n.0.0 could not read, 100% of users would call it a major 
> bug, 
> and it would escalate into vicious name calling

nobody but you is talking about documents the user really visualizes

> Breaking downward compatibility in file formats for regular Joe user is 
> courting 
> public relations disaster. It can kill a product. Even Microsoft doesn't do 
> this lightly

nobody but you is talking about documents the user really visualizes



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

[Josh Stone]

On 01/25/2014 12:15 PM, Chris Murphy wrote:
> OK, so is the fact it's persistently available the problem? Because
> if I were to have a persistent backup of sysroot mounted, I've got
> the same attack vector available. By default for even an unprivileged
> user gnome-shell mounts with By default, gnome-shell mounts volumes
> with rw,nosuid,nodev,relatime,seclabel,uhelper=udisks2.

Right, it's having a persistent and usable copy of a vulnerability.

> So another possibility is to have a "snapshots" subvolume
> persistently mounted, with noexec, and always place snapshots in that
> subvolume.

That sounds good -- even might be just nosuid on that.


Josh
-- 
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]

[Chris Murphy]

On Jan 26, 2014, at 11:38 AM, Simo Sorce  wrote:

> On Sat, 2014-01-25 at 17:54 -0700, Chris Murphy wrote:
>> On Jan 25, 2014, at 4:12 PM, Adam Williamson  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 ?

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. 
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. I can upgrade and downgrade all along 10.7.x and the file format 
is the same.

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. That is, 10.8.x Mail will not read (or write) 10.7.x Mail. I must first 
do an export from 10.7 Mail, to an intermediate format, that 10.8 Mail can 
read. Likewise, 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. But at least 
there is a means to downgrade even to a major version of Mail should I wish.

> 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.

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. Apple Mail and the 
Android phone read mails from the same server, files and folders without 
problems. So from my perspective nothing has changed format wise.


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]

[Reindl Harald]

Am 26.01.2014 20:51, schrieb Reindl Harald:
> 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
> 
>> If Adobe Photoshop version n.1.0 started to write out Photoshop documents 
>> in a manner that n.0.0 could not read, 100% of users would call it a major 
>> bug, 
>> and it would escalate into vicious name calling
> 
> nobody but you is talking about documents the user really visualizes
> 
>> Breaking downward compatibility in file formats for regular Joe user is 
>> courting 
>> public relations disaster. It can kill a product. Even Microsoft doesn't do 
>> this lightly
> 
> nobody but you is talking about documents the user really visualizes

you may also read http://en.wikipedia.org/wiki/SQLite

* sqlite is used by a lot of software to store data
* a new feature in a new version may change the scheme
* you do not need care about that
* the new software version recognizes the old format and applies changes
* the old software version may ignore new tables and columns
* it continues to ignore them and don't donwgrade the version info stored 
somewhere
* the new version after the next update expects consistent data in the new 
format
* your downgrade and still work with the sqlite database may lead to regret 
doing so months later

again: *nobody* is talking about documents

and the same which is done with sqlite may be *whatever* format of store 
internal data
but is affected by the same problematic - *nobody* really supports downgrades

they *may* work fine, there *maybe* are no changes
nobody is telling you so - why? - because what you are doing is not supported

so *please* stop talking about document formats in *that* thread



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

Review swap: glyphicons-halflings-fonts RHBZ#1050805

[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]

[Reindl Harald]

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]

[Chris Murphy]

On Jan 26, 2014, at 11:41 AM, Simo Sorce  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]

[Reindl Harald]

Am 26.01.2014 21:13, schrieb Chris Murphy:
> On Jan 26, 2014, at 11:41 AM, Simo Sorce  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]

[Simo Sorce]

On Sun, 2014-01-26 at 13:13 -0700, Chris Murphy wrote:
> On Jan 26, 2014, at 11:41 AM, Simo Sorce  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]

[Chris Murphy]

On Jan 26, 2014, at 12:51 PM, Reindl Harald  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.

[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]

[Reindl Harald]

Am 26.01.2014 21:30, schrieb Chris Murphy:
> On Jan 26, 2014, at 12:51 PM, Reindl Harald  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.

[Andrew Lutomirski]

On Sun, Jan 26, 2014 at 12:38 PM, Richard W.M. Jones  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]

[Simo Sorce]

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.

[drago01]

On Sun, Jan 26, 2014 at 9:38 PM, Richard W.M. Jones  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]

[Chris Murphy]

On Jan 26, 2014, at 1:07 PM, Reindl Harald  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]

[Reindl Harald]

Am 26.01.2014 21:56, schrieb Chris Murphy:
> On Jan 26, 2014, at 1:07 PM, Reindl Harald  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]

[Reindl Harald]

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]

[Chris Murphy]

On Jan 26, 2014, at 1:18 PM, Reindl Harald  wrote:

> 
> 
> Am 26.01.2014 21:13, schrieb Chris Murphy:
>> On Jan 26, 2014, at 11:41 AM, Simo Sorce  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  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]

[Reindl Harald]

Am 27.01.2014 00:26, schrieb Chris Murphy:
> On Jan 26, 2014, at 1:18 PM, Reindl Harald  wrote:
>> Am 26.01.2014 21:13, schrieb Chris Murphy:
>>> On Jan 26, 2014, at 11:41 AM, Simo Sorce  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  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]

[Chris Murphy]

On Jan 26, 2014, at 1:40 PM, Reindl Harald  wrote:

> 
> 
> Am 26.01.2014 21:30, schrieb Chris Murphy:
>> On Jan 26, 2014, at 12:51 PM, Reindl Harald  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]

[Reindl Harald]

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]

[Chris Murphy]

On Jan 26, 2014, at 4:29 PM, Reindl Harald  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]

[Reindl Harald]

Am 27.01.2014 00:51, schrieb Chris Murphy:
> On Jan 26, 2014, at 4:29 PM, Reindl Harald  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]

[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]

[Chris Murphy]

On Jan 26, 2014, at 4:47 PM, Reindl Harald  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  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]

[Reindl Harald]

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]

[Reindl Harald]

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 
Antwort an: Development discussions related to Fedora 

An: Development discussions related to Fedora 

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

[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]

[Chris Murphy]

On Jan 26, 2014, at 4:55 PM, Reindl Harald  wrote:

> 
> 
> Am 27.01.2014 00:51, schrieb Chris Murphy:
>> On Jan 26, 2014, at 4:29 PM, Reindl Harald  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  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]

[Reindl Harald]

Am 27.01.2014 01:18, schrieb Chris Murphy:
> On Jan 26, 2014, at 4:55 PM, Reindl Harald  wrote:
>> Am 27.01.2014 00:51, schrieb Chris Murphy:
>>> On Jan 26, 2014, at 4:29 PM, Reindl Harald  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]

[Chris Murphy]

On Jan 26, 2014, at 5:10 PM, Reindl Harald  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]

[Chris Murphy]

On Jan 26, 2014, at 5:20 PM, Reindl Harald  wrote:

> 
> 
> Am 27.01.2014 01:18, schrieb Chris Murphy:
>> On Jan 26, 2014, at 4:55 PM, Reindl Harald  wrote:
>>> Am 27.01.2014 00:51, schrieb Chris Murphy:
 On Jan 26, 2014, at 4:29 PM, Reindl Harald  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]

[Reindl Harald]

Am 27.01.2014 01:32, schrieb Chris Murphy:
> On Jan 26, 2014, at 5:20 PM, Reindl Harald  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]

[Chris Murphy]

On Jan 26, 2014, at 5:37 PM, Reindl Harald  wrote:

> 
> 
> Am 27.01.2014 01:32, schrieb Chris Murphy:
>> On Jan 26, 2014, at 5:20 PM, Reindl Harald  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]

[Reindl Harald]

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?

[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?

[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


<>-- 
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.

[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?

[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?

[Rahul Sundaram]

Hi


On Sun, Jan 26, 2014 at 11:08 PM, 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?
>
> 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?

[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

[पराग़]

Hi Nilamdyuti,


On Fri, Jan 24, 2014 at 5:52 PM, Nilamdyuti Goswami 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.
-- 
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

[Nilamdyuti Goswami]

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

Hi Nilamdyuti,


On Fri, Jan 24, 2014 at 5:52 PM, Nilamdyuti Goswami 
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