Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Reindl Harald]

Am 24.03.2014 13:26, schrieb Florian Weimer:
> On 03/24/2014 01:23 PM, Reindl Harald wrote:
> 
>>> It's still very difficult to securely process uploaded files under a 
>>> different user account.  Some SFTP clients set
>>> restrictive permissions on upload, and the OpenSSH implementation does not 
>>> allow to bypass that.
>>
>> man umask
>>
>> [root@rh:/downloads]$ cat /etc/ssh/sshd_config  | grep internal-sftp
>> Subsystem sftp internal-sftp -u 006
> 
> umask doesn't apply to explicit chmod

besides that we get way too off-topic and my first reply was in context
of "because ssh is giving too much access" which is a wrong anecdote:

fine, the same applies for samba, ftp and any other file transfer protocol
if you want 100% defined permissions you need to use inotify and handmade
daemons in any case because the client can fire always a chmod of files
he own



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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Reindl Harald]

Am 24.03.2014 13:21, schrieb Florian Weimer:
> On 03/24/2014 01:06 PM, Reindl Harald wrote:
> 
>> Am 24.03.2014 12:57, schrieb Nicolas Mailhot:
>>> Le Sam 22 mars 2014 01:20, Miloslav Trmač a écrit :
>>>
>>>> The RHEL documentation, apart from fully describing the abilities,
>>>> specifically describes two uses: a ftpd banner
>>>
>>> Surprisingly, ftp is still widely used entreprise-side, because ssh is
>>> giving too much access
>>
>> no, it is easy to restrict ssh to ONLY sftp and chroot and with
>> simple bind-mounts you can completly replace ftp, doing that here
>> in production over years with 3 simple scripts
> 
> It's still very difficult to securely process uploaded files under a 
> different user account.  Some SFTP clients set
> restrictive permissions on upload, and the OpenSSH implementation does not 
> allow to bypass that.

man umask

[root@rh:/downloads]$ cat /etc/ssh/sshd_config  | grep internal-sftp
Subsystem sftp internal-sftp -u 006



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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Reindl Harald]

Am 24.03.2014 12:57, schrieb Nicolas Mailhot:
> Le Sam 22 mars 2014 01:20, Miloslav Trmač a écrit :
> 
>> The RHEL documentation, apart from fully describing the abilities,
>> specifically describes two uses: a ftpd banner
> 
> Surprisingly, ftp is still widely used entreprise-side, because ssh is
> giving too much access

no, it is easy to restrict ssh to ONLY sftp and chroot and with
simple bind-mounts you can completly replace ftp, doing that here
in production over years with 3 simple scripts

[root@localhost:~]$ mount | grep sftp-homes | wc -l
168

* create and maintain the mountpoints from the backend
* mount all bind-mounts at boot
* unmount them before shutdown
* internally you can use the same for userbased smb shares

that's why i go that angry by the broken coreutils "df"
behavior which now luckily no longer lists all bind-mounts
but is still a mess and nobody cares

https://bugzilla.redhat.com/show_bug.cgi?id=1042840
https://bugzilla.redhat.com/show_bug.cgi?id=1001092#c12




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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Reindl Harald]

Am 22.03.2014 07:15, schrieb Reindl Harald:
> Am 22.03.2014 03:21, schrieb Lennart Poettering:
>> On Sat, 22.03.14 01:20, Miloslav Trmač (m...@volny.cz) wrote:
>>> DNS queries can't really be done within the firewall (and due to the
>>> circular dependency between having the firewall up before allowing access
>>> to the network and needing access to the network to resolve DNS names, they
>>> can't even be used in the on-disk firewall configuration).  Having a single
>>> centralized name->IP address repository instead of having a redundant copy
>>> in each host, and having the configuration use readable names instead of IP
>>> addresses, makes some difference in usability and management overhead.
>>
>> This is supposedly security functionality. You shouldn't build your
>> security functionality on top of DNS. If you do, then you gain no
>> security
> 
> in your world one thing rules all true
> in the world of *layered* security not true

and i will give an example what layered security means

* years ago played around with SELinux
* after boot SELinux blocked iptables to start
* my smb.conf has "hosts allow" on any machine
* i recognized the failed iptables by messages in the samba log about not 
allowed hosts
* guess what happens if you have a guest-share in that case without another 
security layer

so if you propose to remove things which really may not be the best soultion
but are a solution in context of layered security you should at the same time
propose a replacement which does it better - in context of tcpwrappers a
replacement wokring with hosts.allow and hosts.deny and go ahead propose
this to be linked with any network aware software in the distribution

*that* would be a smart proposal and gains a lot

propose to declare things as deprectated while demand from the whole world 
adopt the
changes is a sloppy attitude, frankly can you imagine what people all over the 
world
could have developed on top of Fedora with the time wasted the last few years 
by adopt
changes with no backward compatibility?

make proposals and deprecations is easy as long the person who does has not to
chew the result by cherry picking what makes the own development easier and
cleaner and not care about existing usecases just working until someone breaks
them willingly

and *please* as long as you don't understand layered security and think a single
point of defense resulting in a single point of failure with no additional
safety net don't talk too much about security




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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Reindl Harald]

Am 22.03.2014 03:21, schrieb Lennart Poettering:
> On Sat, 22.03.14 01:20, Miloslav Trmač (m...@volny.cz) wrote:
>> DNS queries can't really be done within the firewall (and due to the
>> circular dependency between having the firewall up before allowing access
>> to the network and needing access to the network to resolve DNS names, they
>> can't even be used in the on-disk firewall configuration).  Having a single
>> centralized name->IP address repository instead of having a redundant copy
>> in each host, and having the configuration use readable names instead of IP
>> addresses, makes some difference in usability and management overhead.
> 
> This is supposedly security functionality. You shouldn't build your
> security functionality on top of DNS. If you do, then you gain no
> security

in your world one thing rules all true
in the world of *layered* security not 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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Reindl Harald]

Am 22.03.2014 03:05, schrieb Lennart Poettering:
> On Fri, 21.03.14 23:35, Reindl Harald (h.rei...@thelounge.net) wrote:
> 
>>> In other words you are telling us that now to get something implemented or 
>>> removed in Fedora we have to not only
>>> deal with our usual politics and bureaucracy but also all the downstream 
>>> distribution to us as well...
>>
>> no, in other words he told you that whe world is not turning around
>> a few people deperecating anything which does not get a update for
>> the sake of a update and what some people calling  "legacy" might
>> be things not needing updates because they just works and update
>> and replace/drop for the sake of a change does not make things
>> better for no good reason
>>
>> the author of tcpwrapper is Wietse Venema, the perosn who created
>> and maintains postfix - frankly if only 1% of the software out
> 
> So, you do realise that the same Wietse Venema who wrote and then
> stopped maintaining tcpwrappers is the one who didn't add *any*
> tcpwrappers support to Postfix? To this day Postfix doesn't do
> tcpwrappers. Probably for a good reason, don't you think?

until you managed the same stability of interfaces for a couple
of years like postfix don't strip quotes

>> most of the replacements in the last few years could have been
>> becakward compatible if the developers would not be too lazy
>> to care about
> 
> Wietse is such a lazy person that he didn't had hosts.allow/.deny
> compatibility support to Postfix, isn't he?

ask him why



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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Reindl Harald]

Am 22.03.2014 03:07, schrieb Lennart Poettering:
> On Fri, 21.03.14 23:46, Reindl Harald (h.rei...@thelounge.net) wrote:
> 
>> if you believe it or not: there exists code which don't neeed
>> updates and reweites all te time because it just works and given
> 
> You do realize that if software engineering has shown something then
> yes, software development is never finished, it's a process. You do need
> maintains for such things

i do not need maintains for things just working
you do because it's your passion to replace, change and deprecate

many others and i need working systems to do my work on them






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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Reindl Harald]

Am 21.03.2014 23:37, schrieb Jóhann B. Guðmundsson:
> 
> On 03/21/2014 10:35 PM, Reindl Harald wrote:
>> the author of tcpwrapper is Wietse Venema,
> 
> You do realize when he wrote this and what he was trying to overcome at that 
> time so I have to ask have you spoken
> to him about how useful he thinks his creation is today and why he stopped 
> maintaining it?
> 
> If not I suggest you do and hear what he thinks and says about it...

let hear

most things deprecated the past years are deprecated because they don't
receive a upstrea update every weak and people depcrate them doing
so because they can't imagine that things just work

if you believe it or not: there exists code which don't neeed
updates and reweites all te time because it just works and given
the amount of bugs in systemd Fedora 20/Rawhide, well, better
there would have been no improvement after Fedora 19

does this care upstream: no it does not

but hey, propose other peoples code to be deprecatd is so much easier



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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Reindl Harald]

Am 21.03.2014 23:31, schrieb Jóhann B. Guðmundsson:
> 
> On 03/21/2014 10:30 PM, Martin Langhoff wrote:
>> On Fri, Mar 21, 2014 at 6:16 PM, "Jóhann B. Guðmundsson" > > wrote:
>>
>> In other words you are telling us that now to get something implemented 
>> or removed in Fedora we have to not
>> only deal with our usual politics and bureaucracy but also all the 
>> downstream distribution to us as well...
>>
>>
>> One way to avoid those pesky details is to not have users... :-)
> 
> One way to prevent advancement and innovation within Fedora is precisely 
> what's taking place here.
> 
> Three layers to get things done... 

you call it "innovation"

others call it bad names to break every day compatibility and force
anybody to follow changes nobobody asked for because only if changes
have a great impact to anybody they are recognized

the whole environment moves in circles with less to zero gain
the last past years but hey you are cool if you change things



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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Reindl Harald]

Am 21.03.2014 23:16, schrieb Jóhann B. Guðmundsson:
> On 03/21/2014 02:05 PM, Matthew Miller wrote:
>> On Thu, Mar 20, 2014 at 06:34:22PM +0100, Lennart Poettering wrote:
>>> >I wonder whether it wouldn't be time to say goodbye to tcpwrappers in
>>> >Fedora. There has been a request in systemd upstream to disable support
>> I talked to some of the RHEL planning people, and they're okay
>> with marking it deprecated in RHEL7. That allays some of my concerns about
>> downstream enterprise needs -- although there was also the comment that the
>> libwrap2 approach would be a good one.
>>
>> I'm also collecting some feedback from CentOS users. I'll wait to report on
>> that for a little bit, but I think in general the majority response is okay
>> with it, with a significantly vocal "why change things that work?"
> 
> In other words you are telling us that now to get something implemented or 
> removed in Fedora we have to not only
> deal with our usual politics and bureaucracy but also all the downstream 
> distribution to us as well...

no, in other words he told you that whe world is not turning around
a few people deperecating anything which does not get a update for
the sake of a update and what some people calling  "legacy" might
be things not needing updates because they just works and update
and replace/drop for the sake of a change does not make things
better for no good reason

the author of tcpwrapper is Wietse Venema, the perosn who created
and maintains postfix - frankly if only 1% of the software out
there would provide his stability and backwards compatibility
a lot of peole could do better things with their time than creat
day for day in case of deprecations and incompatible replacemnets

most of the replacements in the last few years could have been
becakward compatible if the developers would not be too lazy
to care about




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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Reindl Harald]

Am 21.03.2014 20:02, schrieb Florian Weimer:
> * Lennart Poettering:
> 
>>> So offer something with equivalent functionality (and config file
>>> syntax compatibility), with a nice modern clean API and then systemd
>>> and others can be moved over to that 1 by 1, and once we've no more
>>> users left we can kill of the old beast ?
>>
>> Nope. In systemd we already support one subsystem for filtering just
>> fine, it's called a firewall.
> 
> Does this subsystem support DNS-based rules?

and even if it does you do *not* want dns-resolution based
on packets instead connections - guess how many users would
make the mistake resulting in a selfDOS



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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Reindl Harald]

Am 21.03.2014 01:17, schrieb Lennart Poettering:
> On Thu, 20.03.14 20:55, Hans de Goede (hdego...@redhat.com) wrote:
>> So offer something with equivalent functionality (and config file
>> syntax compatibility), with a nice modern clean API and then systemd
>> and others can be moved over to that 1 by 1, and once we've no more
>> users left we can kill of the old beast ?
> 
> Nope. In systemd we already support one subsystem for filtering just
> fine, it's called a firewall. I am looking for a way to simplify things,
> and remove unnecessary redundancies. And just rewriting something that
> is redundant and a bad idea in the first place, certainly doesn't help
> there...

http://en.wikipedia.org/wiki/Defence_in_depth#Non-military_examples



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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Reindl Harald]

Am 21.03.2014 01:00, schrieb Lennart Poettering:
> On Thu, 20.03.14 13:44, Stephen John Smoogen (smo...@gmail.com) wrote:
> 
>>> Well, all mails servers as well as sshd have much better ways to do
>>> such filtering. sshd has "Match",  Postfix for example has
>>> "smtpd_client_restrictions=", and so on.
>>>
>> And now I need to have X number applications special syntax to
>> whitelist/blacklist a site. I need to change X files to make that change.
>> Each of those could be a separate change control process depending on the
>> size of the organization. Or I have 1 file that I can make a change to
>> which has usually one syntax and one set of reviews.
> 
> Well, if you filter in postfix or ssh, then you have a domain-specific,
> powerful language there. You can not only match on source addresses, but
> also on user names, groups, authentication methods, connection features
> SASL schemes, crypto algorithms

what has this to do with "I have 1 file that I can make a change to
which has usually one syntax and one set of reviews"?




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: fail2ban + firewalld suggestions needed

[Reindl Harald]

Am 19.03.2014 20:21, schrieb Jonathan Underwood:
> On 19 March 2014 19:16, Reindl Harald  wrote:
>> but with not take care of it you would end in having firewalld as mandatory
>> dependency which is the main point of that thread - there are still way
>> too much circular dependencies making it hard to strip down a setup
> 
> I didn't advocate having fail2ban having a hard Requires for
> firewalld, nor anything else creating a "circular dependence". I was
> simply advocating having a configuration file that would work for the
> most common case

and what installs that config file is the question and how
sub-packages are done with care since there are no soft
Requires



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: fail2ban + firewalld suggestions needed

[Reindl Harald]

Am 19.03.2014 20:14, schrieb Jonathan Underwood:
> On 19 March 2014 15:10, Orion Poplawski  wrote:
>> See https://bugzilla.redhat.com/show_bug.cgi?id=1046816
>> You are going to need fail2ban-0.9-2 - f20 build is here 
>> http://koji.fedoraproject.org/koji/taskinfo?taskID=6651548.  More testing 
>> would be much appreciated.
> 
> On a default F20 install with that package I had to do the following
> to get a minimal ssh jail up and running (this is info for those
> following along, not Orion who no doubt knows this)...
> 
> In /etc/fail2ban/jail.d/ajil.local
> 
> [DEFAULT]
> bantime = 3600
> banaction = firewallcmd-ipset
> backend = systemd
> 
> [sshd]
> enabled = true
> 
> So, it seems to me that at the very least we should set backend =
> systemd in the Fedora, else it's not going to work out of the box (or,
> more ugly, require rsyslog).
> 
> As to the original question I'd favour enabling the firewalld support
> in Fedora by default. Anyone disabling (or chosing not to install)
> firewalld and installing fail2ban should know enough to configure
> things appropriately

but with not take care of it you would end in having firewalld as mandatory
dependency which is the main point of that thread - there are still way
too much circular dependencies making it hard to strip down a setup



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: F21 Self Contained Change: Security Policy In The Installer

[Reindl Harald]

Am 14.03.2014 20:51, schrieb Miloslav Trmač:
> 2014-03-14 20:47 GMT+01:00 Reindl Harald  <mailto:h.rei...@thelounge.net>>:
> 
> why is only the average user relevant?
> 
> how do usesers get "advanced"?
> by notice things which sounds interesting, ignore them the
> first time, use Google and doing the same again no longer
> skip things
> 
> Offering the user to use one of the pre-defined SCAP policies during 
> installation does not educate them much—all
> they learn is the names of the pre-defined policies.  /Reading and modifying/ 
> the policies would very likely be a
> great way to learn, but that definitely shouldn't happen within the installer.

only mention the pure existence and lead to the one or another
after the install types "SCAP policies" in Google would be a
gain - that is how you make people interested

a few years ago i also did not know the word SCAP until i tried to
setup a security scanner for our internal network (OpenVAS) and
so i learned all my current advanced knowledge by plug such random
pieces faced here and there together and finally started working in
the IT and cintuned to learn every single day



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: F21 Self Contained Change: Security Policy In The Installer

[Reindl Harald]

Am 14.03.2014 20:31, schrieb Matthew Garrett:
> On Fri, Mar 14, 2014 at 02:39:51PM -0400, Eric H. Christensen wrote:
>> On Fri, Mar 14, 2014 at 03:00:20PM +, Matthew Garrett wrote:
>>> If there's a default policy that would make sense for most workstation 
>>> users, we should just make that the default. If there isn't, how are we 
>>> going to educate users as to which choice they should be making? *I* 
>>> don't understand the terms used in the proposed UI, so I'd be willing to 
>>> put money on the number of potential users who do being pretty close to 
>>> statistically indistinguishable from 0.
>>
>> I'm all for creating a recommended hardening policy that users can opt 
>> into at install time.  This feature would allow us to provide that 
>> kind of data to the end user.  If the user decides to not implement a 
>> policy that would simply yield the same outcome as we have today.
> 
> How does the average user make an informed decision about whether an 
> available security policy is appropriate for them?

why is only the average user relevant?

how do usesers get "advanced"?
by notice things which sounds interesting, ignore them the
first time, use Google and doing the same again no longer
skip things

my whole IT education and anything i am doing in ym current
job for the last 11 years was learnt that way - by doing
and *while* doing read details, but first it needs a start




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: packages which require the kernel package

[Reindl Harald]

Am 10.03.2014 21:06, schrieb Matthew Miller:
> On Mon, Mar 10, 2014 at 03:22:02PM -0400, Matthew Miller wrote:
>> I propose that (in Rawhide) we simply drop the requires line from all of
>> the ones that are simply trying to state that they need a kernel version
>> greater than the kernel version currently in Rawhide (right now, 3.14 rc).
> 
> Require a kernel version greater than a number which is _less_ than what we
> actually already have, I mean. I case that wasn't clear

i wonder which packages at all require a kernel because "package-cleanup"
has the opinion the kernel is a leaves packages at all - even the running


[root@localhost:~]$ package-cleanup --leaves --all | grep kernel
kernel-3.13.5-103.fc19.x86_64

[root@localhost:~]$ uname -r
3.13.5-103.fc19.x86_64 #1 SMP Mon Mar 3 18:46:36 UTC 2014


one reason more that the yum-behavior below is essential
there is only that one kernel package installed

[root@localhost:~]$ yum remove kernel
Loaded plugins: protectbase, tsflags
Skipping the running kernel: kernel-3.13.5-103.fc19.x86_64



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: exclude people from giving karma?

[Reindl Harald]

Am 10.03.2014 20:40, schrieb drago01:
> On Mon, Mar 10, 2014 at 8:35 PM, Reindl Harald  wrote:
>>
>> Am 10.03.2014 20:18, schrieb drago01:
>>> On Sun, Feb 23, 2014 at 6:12 PM, Reindl Harald  
>>> wrote:
>>>> https://admin.fedoraproject.org/updates/FEDORA-2014-2922/libreoffice-4.2.1.1-1.fc20?_csrf_token=a6a024f6e2d35ad3fb8666c1244e215a6aa2
>>>>
>>>> how can people pretend "installation went smoothly, no issue detected 
>>>> during basic
>>>> document manipulation" for packages which are not installable at all due
>>>> dependencie problems?
>>>
>>> https://admin.fedoraproject.org/updates/mesa-10.0.3-1.20140206.fc20
>>> ... again broken dep and someone gave it +1 regardless.  You should
>>> know that "someone" very well ;)
>>>
>>> Now seriously auto qa detected the broken dep. Maybe it should give
>>> negative karma even if there are false positives a wrong negative
>>> karma is not the end of the world ...
>>
>> yes i know that one well, that's why that one notified
>> here that rebuilds are needed
>> https://bugzilla.redhat.com/show_bug.cgi?id=1066718
> 
> OK, but then you should undo your +1 by adding a -1 (which means 0
> instead of +1)

maybe, the main difference is that i installed the packages, tried all sorts
of graphical applications, KDE desktop effetcs and gave karma with
"fedora-easy-karma" and that is a total different story than "uhm that
is broken and i need to seek a completly different build"



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: exclude people from giving karma?

[Reindl Harald]

Am 10.03.2014 20:35, schrieb Reindl Harald:
> 
> 
> Am 10.03.2014 20:18, schrieb drago01:
>> On Sun, Feb 23, 2014 at 6:12 PM, Reindl Harald  
>> wrote:
>>> https://admin.fedoraproject.org/updates/FEDORA-2014-2922/libreoffice-4.2.1.1-1.fc20?_csrf_token=a6a024f6e2d35ad3fb8666c1244e215a6aa2
>>>
>>> how can people pretend "installation went smoothly, no issue detected 
>>> during basic
>>> document manipulation" for packages which are not installable at all due
>>> dependencie problems?
>>
>> https://admin.fedoraproject.org/updates/mesa-10.0.3-1.20140206.fc20
>> ... again broken dep and someone gave it +1 regardless.  You should
>> know that "someone" very well ;)
>>
>> Now seriously auto qa detected the broken dep. Maybe it should give
>> negative karma even if there are false positives a wrong negative
>> karma is not the end of the world ...
> 
> yes i know that one well, that's why that one notified
> here that rebuilds are needed
> https://bugzilla.redhat.com/show_bug.cgi?id=1066718
> 
> the difference is:
> 
> * that packages install and are running here the whole day
> * now downloads from other builds required
> * the openoffice one did *not* install from the build alone
>   in no case at all

and no that is not a false positive

> works for me on Intel SandyBridge with recent KDE and desktop effects

Mar 10 14:15:29 Updated: mesa-libglapi-10.0.3-1.20140206.fc20.x86_64
Mar 10 14:15:29 Updated: mesa-libgbm-10.0.3-1.20140206.fc20.x86_64
Mar 10 14:15:29 Updated: mesa-filesystem-10.0.3-1.20140206.fc20.x86_64
Mar 10 14:15:31 Updated: mesa-dri-drivers-10.0.3-1.20140206.fc20.x86_64
Mar 10 14:15:31 Updated: mesa-libEGL-10.0.3-1.20140206.fc20.x86_64
Mar 10 14:15:31 Updated: mesa-libGL-10.0.3-1.20140206.fc20.x86_64
Mar 10 14:34:19 Updated: libudisks2-2.1.2-2.fc20.x86_64
Mar 10 14:34:20 Updated: udisks2-2.1.2-2.fc20.x86_64
Mar 10 15:35:48 Updated: wireshark-1.10.6-1.fc20.x86_64
Mar 10 15:35:48 Updated: gdisk-0.8.10-2.fc20.x86_64
Mar 10 15:35:50 Updated: cantata-1.3.2-2.fc20.20140310.rh.x86_64
__

no vmware driver installed on a bare metal machine

[root@srv-rhsoft:~]$ rpm -qa | grep xorg
xorg-x11-drv-evdev-2.8.2-1.fc20.x86_64
xorg-x11-drv-fbdev-0.4.3-10.fc20.x86_64
xorg-x11-xinit-1.3.2-9.fc20.x86_64
xorg-x11-drv-keyboard-1.7.0-2.fc20.x86_64
xorg-x11-drv-void-1.4.0-19.fc20.x86_64
xorg-x11-xauth-1.0.7-4.fc20.x86_64
xorg-x11-server-Xorg-1.14.4-7.fc20.x86_64
xorg-x11-xdm-1.1.11-6.fc20.x86_64
xorg-x11-drv-dummy-0.3.6-11.fc20.x86_64
xorg-x11-drv-intel-2.21.15-5.fc20.x86_64
xorg-x11-server-common-1.14.4-7.fc20.x86_64
xorg-x11-utils-7.5-13.fc20.x86_64
xorg-x11-drv-v4l-0.2.0-31.fc20.x86_64
xorg-x11-xkb-utils-7.7-8.fc20.x86_64
xorg-x11-drv-mouse-1.9.0-2.fc20.x86_64
xorg-x11-font-utils-7.5-18.fc20.x86_64
xorg-x11-server-utils-7.7-2.fc20.x86_64
xorg-x11-fonts-Type1-7.5-9.fc20.noarch
[root@srv-rhsoft:~]$
__

[root@srv-rhsoft:~]$ ps aux | grep kde
root39  0.0  0.0  0 0 ?SMär08   0:00 [kdevtmpfs]
harry12995  0.1  0.2 713380 33112 ?Sl   20:09   0:01 kdeinit4: 
konsole [kdeinit]
harry20184  0.0  0.3 2945924 59004 ?   Sl   20:12   0:00 kdeinit4: kate 
[kdeinit] --graphicssystem nat
harry23596  0.0  0.0 113108  1540 ?Ss   18:46   0:00 /bin/sh 
/usr/bin/startkde
harry23617  0.0  0.0  55496  1044 ?Ss   18:46   0:00 
/usr/bin/ssh-agent /bin/sh -c exec -l
/usr/bin/bash -c "/usr/bin/startkde"
root 23635  0.0  0.0 112684   956 pts/1S<+  20:39   0:00 /usr/bin/grep 
--color kde
harry23680  0.0  0.0   415284 ?S18:46   0:00 
/usr/libexec/kde4/start_kdeinit +kcminit_startup
harry23681  0.0  0.1 522360 25092 ?Ss   18:46   0:00 kdeinit4: 
kdeinit4 Running...
harry23683  0.0  0.0 526196 13524 ?S18:46   0:00 kdeinit4: 
klauncher [kdeinit] --fd=9
harry23685  0.0  0.1 1356776 30568 ?   Sl   18:46   0:00 kdeinit4: 
kded4 [kdeinit]
harry23701  0.0  0.1 616148 22732 ?S18:46   0:00 kdeinit4: 
kglobalaccel [kdeinit]
harry23706  0.0  0.1 696608 22632 ?Sl   18:46   0:00 kdeinit4: 
ksmserver [kdeinit]
harry23721  0.0  0.2 822416 33232 ?Sl   18:46   0:01 kdeinit4: 
krunner [kdeinit]
harry23725  3.3  0.8 3416016 138172 ?  Sl   18:46   3:45 kdeinit4: 
plasma-desktop [kdeinit]
harry23766  0.0  0.1 614392 20736 ?S18:46   0:00 kdeinit4: 
kaccess [kdeinit]
harry23794  0.0  0.1 643640 30816 ?S18:46   0:00 kdeinit4: 
konqueror [kdeinit] --preload
harry23803  0.0  0.1 621036 21768 ?S18:46   0:00 kdeinit4: 
klipper [kdeinit]
harry23807  0.0  0.1 856504 30124 ?Sl   18:46   0:00 kdeinit4

Re: exclude people from giving karma?

[Reindl Harald]

Am 10.03.2014 20:18, schrieb drago01:
> On Sun, Feb 23, 2014 at 6:12 PM, Reindl Harald  wrote:
>> https://admin.fedoraproject.org/updates/FEDORA-2014-2922/libreoffice-4.2.1.1-1.fc20?_csrf_token=a6a024f6e2d35ad3fb8666c1244e215a6aa2
>>
>> how can people pretend "installation went smoothly, no issue detected during 
>> basic
>> document manipulation" for packages which are not installable at all due
>> dependencie problems?
> 
> https://admin.fedoraproject.org/updates/mesa-10.0.3-1.20140206.fc20
> ... again broken dep and someone gave it +1 regardless.  You should
> know that "someone" very well ;)
> 
> Now seriously auto qa detected the broken dep. Maybe it should give
> negative karma even if there are false positives a wrong negative
> karma is not the end of the world ...

yes i know that one well, that's why that one notified
here that rebuilds are needed
https://bugzilla.redhat.com/show_bug.cgi?id=1066718

the difference is:

* that packages install and are running here the whole day
* now downloads from other builds required
* the openoffice one did *not* install from the build alone
  in no case 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: [Guidelines Change] Changes to the Packaging Guidelines

[Reindl Harald]

Am 10.03.2014 03:35, schrieb Kevin Kofler:
> Reindl Harald wrote:
>> in fact *nothing* at all should refer to /bin and /sbin after UsrMove
>> as the waeking of the package guidelines is a sign of missing courage
>> in the context of such invasive changes - well, looks like i need
>> to continue fix the still extsinting mess of that half-baken change
>> becaue my SPEC files are all-or-nothing and after nobody cared about
>> my warnings to do UsrMove it is a bad sign that it *never* was finished
> 
> Unfortunately, the guidelines actually got "fixed" to condone the broken 
> practice of still installing files to /bin and /sbin. :-(

"waeking" should have been "weaking" and point exactly to that
major mistake, that we we suffer the next 10 years of UsrMove

at least glibc and perl should be fixed to provide both
currently i do that on private meta-packages to prevent
big troubles each dist-upgrade in case of packages using
both involved in the transaction

Provides:  %{_bindir}/perl
Provides:  %{_sbindir}/ldconfig



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: [Guidelines Change] Changes to the Packaging Guidelines

[Reindl Harald]

Am 09.03.2014 20:05, schrieb Panu Matilainen:
> On 03/09/2014 04:49 PM, Kevin Kofler wrote:
>> Toshio Kuratomi wrote:
>>> Directory and file interaction is a hard problem. There's no right thing
>>> to do in this case.  The many possible things we could do all have one
>>> drawback or another in certain cases.
>>
>> The right thing is clear: If all the files inside the directory are owned by
>> packages about to be removed in the transaction, just rm -rf the directory
>> (or rather the equivalent in C code), otherwise rename it with a suffix
>> (.rpmsave, if necessary .rpmsave0, .rpmsave1, … , .rpmsave10, …) and only
>> delete the files owned by packages about to be removed in the transaction.
> 
> Right. CLEARLY this would've been Just The Thing to do when /bin changed from 
> a directory to a /usr/bin symlink.
> Right?

in fact *nothing* at all should refer to /bin and /sbin after UsrMove
as the waeking of the package guidelines is a sign of missing courage
in the context of such invasive changes - well, looks like i need
to continue fix the still extsinting mess of that half-baken change
becaue my SPEC files are all-or-nothing and after nobody cared about
my warnings to do UsrMove it is a bad sign that it *never* was finished



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: Summary/Minutes from today's FESCo Meeting (2014-03-05)

[Reindl Harald]

Am 07.03.2014 23:33, schrieb Adam Williamson:
> On Fri, 2014-03-07 at 22:52 +0100, drago01 wrote:
>>> There is at least one starkly obvious difference there, which is that
>>> you choose your religious beliefs and affiliations; you do not choose
>>> your race/color/general genetic origin.
>>
>> Well people can choose to not be offended by random images / texts / 
>> whatever.
>> There is is the option of "just ignore".
> 
> That is not a true choice. "Ignoring" the effect of marginalization that
> such offensive texts ignore is, effectively, opting into it.
> 
> I'm gay. I can "choose to ignore it" when people yell 'faggot!' at me,
> but it's not a choice I should be forced, required or expected to make,
> and in a sense, it feels like a betrayal to the group being
> discriminated against to do so. Not speaking out is, in a sense,
> tantamount to accepting that sort of treatment as OK. (Not to criticize
> those in this or other commonly-discriminated-against groups who do
> choose to ignore offensive acts; there *are* valid reasons to make that
> choice in some circumstances, but it is not OK to say "well, that's just
> what you should always do.")
> 
>> But unfortunatly a lot of people don't think that way.
> 
> There are reasons why

not really good ones

it is indeed a amercian phenomenon always feel personally abused
by anything and if there is no actual reason people feel abused
because they are ignored - if i seek for a reason to feel abused
i will find one - mailing lists with english speakers prove that

that is the same as german people are not allowed to criticize
isreal even if they are 100% right because of "their" history
while most where even not born at that time

what about people live their live and just ignore things they
don't like? life would be too easy? so hwat





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: Proposal: Don't show applications in the software center with XPM icons

[Reindl Harald]

Am 07.03.2014 20:42, schrieb Przemek Klosowski:
> On 03/07/2014 11:21 AM, Richard Hughes wrote:
>> On 7 March 2014 14:08, Michael Catanzaro  wrote:
>>> Microsoft, Apple, and Google set requirements that apps must follow if
>>> they want to appear in the software center in order to ensure a good
>>> user experience.
>> This is something I absolutely want to do. We already rate the
>> applications in GNOME 3.12 depending on how many positive attributes
>> they have (the star ratings) and I think it's fine to set a minimum
>> standard and slowly raise the bar over time. Showing 500 applications
>> that hits some absolute minimum level is much better than showing an
>> additional 500 basically crap applications.
>>
> This decision should belong to the user, though. It's one thing to default to 
> showing only five-star applications
> (GTK2, icon with transparency, AppData with translations) while allowing the 
> user to widen the criteria to show
> more applications. It is quite another thing to make an unilateral decision 
> to take out an entire class that fails
> to satisfy some arbitrary requirement.
> 
> I do realize that the app installer becomes more complex, with the 'number of 
> stars' selector, and having to make
> up application data that the app itself failed to provide, but I think 
> cost/benefit justifies that effort.
> 
> I feel old and cranky arguing this point but the app markets for portable 
> devices are a _counterexample_ to a
> thesis that pretty metadata guarantees better application quality. At least 
> on portable devices the old-line stuff
> simply does not install so it is irrelevant; on Fedora it can be installed 
> and would be useful to someone, if only
> they can discover its existence when using the pretty, default application 
> installer. As another data point, I just
> introduced 'units' to another person that missed it in spite of being in the 
> business of scientific
> data/calculations. Fedora should make it easier, not more difficult, for 
> people to discover such useful things.

*exactly* my point and even if i do not use any GUI for install/update
packages i care about because others should have the same options as
i had many years ago to find their *alternative* to Windows/OSX



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: Read this if your package includes a status notifier / system tray icon

[Reindl Harald]

Am 07.03.2014 18:33, schrieb Rahul Sundaram:
> On Fri, Mar 7, 2014 at 12:22 PM, Reindl Harald wrote:
> 
> in case of changes gaining less to zero -> YES
> 
> If a single desktop environment wants to just implement something, they can 
> go ahead and do so but that doesn't
> make it a real specification.  For other desktop environments to adopt it, it 
> needs to be a collaborative and
> shared effort.  Part of that is addressing concerns and bringing more clarity 
> so that multiple implementations are
> compatible.  Unstated assumptions lead precisely to the kind of problems you 
> are talking about

i know that all and aware that it is not perfect but if others "adopt"
something existing and already widely used they hardly can demand to
change all existing code

if you take the word "specification" strong you need also to refuse any RFC
because "request for comments" is not a spacification by it's meaning and
at least you have to forget any draft RFC, some of them are used for decades
and where never finished but nobody changes them and say "and that is now
the standard, anyhting out there with different behavior is no longer
standard confrom"

honestly you should be careful in general with "specification" and "standard"
because there are only a few institutions world wide in the position to define
a standard at all

the rest are de-facto standards



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: Proposal: Don't show applications in the software center with XPM icons

[Reindl Harald]

Am 07.03.2014 18:16, schrieb Ryan Lerch:
> IMHO, the proposal was less of
> 
> "let's remove ugly icons"
> 
> and more
> 
> "lets hide applications that use icons in this particular format that doesn't 
> support the features of the software
> application"

IMHO you did not read the proposal itself
scroll down - i pasted it again in this message

> It is still possible to have ugly icons, they just have to be in PNG, GIF or 
> SVG format

and that is why "and look very bad" defined by the format is flawed

 Original-Nachricht 
Betreff: Proposal: Don't show applications in the software center with XPM icons
Datum: Thu, 6 Mar 2014 15:41:00 +
Von: Richard Hughes 
An: Development discussions related to Fedora 

XPM is an old standard for icons used by a very small number of
desktop packages in Fedora. The XPM icons are normally small, mostly 8
bit, and usually without an alpha channel and look very bad in the
software center.

I'm going to propose for F21 that we drop support for XPM in the
metadata extractor and only show apps with GIF, PNG and SVG icons. The
list of affected GUI applications is here:

TeXmacs
cycle
flamerobin
gnurobots
linsmith
mup
pari-gp
pgadmin3
qtel
qucs
xsensors

As usual, I'd like to push packagers to get upstream to ship a more
modern (and high resolution, *with* alpha channel) icon in PNG or SVG
format, but packagers can also just replace the icon referenced in the
.desktop file if upstream is unwilling / dead and a good replacement
is available.

Comments welcome,



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: Read this if your package includes a status notifier / system tray icon

[Reindl Harald]

Am 07.03.2014 18:16, schrieb Dan Williams:
> On Fri, 2014-03-07 at 00:18 +0100, Kevin Kofler wrote:
>> * change requests that would have broken compatibility with the existing 
>> implementations of the protocol already in wide use for little to no 
>> practical benefit, such as nitpicking about the names of some D-Bus methods.
> 
> So just because something is in use, but hasn't been standardized or
> been through any kind of standardization discussion, it should
> automatically be adopted as-is?  I think not...

in case of changes gaining less to zero -> YES

you can't make vague specifications not forbid naming things in
a way, wait months and years until it is widely used and then
come out and say "oh and now we strictly say how to use it and
expect everybody out there to change any existing code"

that happens way too often in the open source world while in
a company you get instantly fired acting that way and demand
all others to sped their time for changes you enforce if you
can't prove a very good reason for doing so



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: Proposal: Don't show applications in the software center with XPM icons

[Reindl Harald]

Am 07.03.2014 15:08, schrieb Michael Catanzaro:
> Ancient icons are a good heuristic that the app is unmaintained 
> and not something the user really wants to install

Ancient icons are a good heuristic that a app if it does what i
need the next week or month does not get a complete rewrite
with a total different UI and that i want to use it *because*
of that to prevent my personal workflow changing all the time
by random decisions



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: Proposal: Don't show applications in the software center with XPM icons

[Reindl Harald]

Am 07.03.2014 15:08, schrieb Michael Catanzaro:
> On Fri, 2014-03-07 at 13:19 +0100, Reindl Harald wrote:
>> says who?
>>
>> as long GTK1 is not forbidden in Fedora there is no valid
>> reason for that statement - you may prefer not having a
>> function at all if it is not beautiful enough for you
>>
>> *but*
>>
>> * beautiful is in the eye of the beholder
>> * you should hestitate make such proposals based on your eyes
> 
> Microsoft, Apple, and Google set requirements that apps must follow if
> they want to appear in the software center in order to ensure a good
> user experience. I absolutely think we need to do the same to be
> competitive. Ancient icons are a good heuristic that the app is
> unmaintained and not something the user really wants to install

if i want it the Apple and Microsoft way i just install Windows
or go out an buy a Mac - i am using Linux because it is *not*
Windows and *not *OSX*

speaking of freedom and freedom of choice and then come with
restrictions here and there is somehow strange

you hardly can call "i do not show an app because i do not like
the icon" a good user expierience - where do you draw the line?

that may end in "there is no app for what i current need to do
and so i can't use that operating system at all" while the app
was there but someone decided to hide it



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: F20 Self Contained Change: Snapshot and Rollback Tool

[Reindl Harald]

Am 07.03.2014 14:31, schrieb Josh Boyer:
> On Thu, Mar 6, 2014 at 6:52 PM, Chris Murphy  wrote:
>>> I this project dead?  I'm casting about to tools to manage lvm snapshots 
>>> and roller-derby sounded promising.  Any other tools out there?
>>
>> There's a recent snapshot/rollback thread on the desktop list that relates 
>> to this. LVM thin provisioning support is in the Fedora 20 installer (it 
>> fails to produce a bootable system, the post-install fix for which is listed 
>> in Fedora 20 common bugs).
>>
>> However, if OSTree is used, then there isn't a hard requirement on either 
>> LVM Thin Provisioning or Btrfs.
> 
> I don't think that's accurate.  OSTree doesn't touch /home from what I
> remember.  It is only concerned with /usr and to as minimal a degree
> as possible /etc.  People likely still want snapshot and rollback for
> their actual _data_ as well

i don't think people *really* like to restore a snapshot of /usr
without /var/lib/rpm if they only know what that means at the end



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: Proposal: Don't show applications in the software center with XPM icons

[Reindl Harald]

Am 07.03.2014 13:15, schrieb Richard Hughes:
> On 7 March 2014 11:57, Tim Lauridsen  wrote:
>> what will be the next ?  qt apps ? gtk2 apps
> 
> No, because that would be ridiculous. Hiding applications using GTK1
> would of course be okay

says who?

as long GTK1 is not forbidden in Fedora there is no valid
reason for that statement - you may prefer not having a
function at all if it is not beautiful enough for you

*but*

* beautiful is in the eye of the beholder
* you should hestitate make such proposals based on your eyes



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: Proposal: Don't show applications in the software center with XPM icons

[Reindl Harald]

Am 07.03.2014 12:57, schrieb Tim Lauridsen:
> On Fri, Mar 7, 2014 at 6:50 AM, Satyajit Sahoo  > wrote:
> 
>  Apps with ugly icons and ugly design results in bad user experience
>  IMO. They should not be displayed in the software center
> 
> The quaility of an application has nothing todo, with at fancy icon, not 
> showning the 
> icon is ok, but don't show the application is not IMO what will be the next?  
> qt apps? gtk2 apps 

+1000

this new age "function follows form" is ridiculous, some people seems really
to prefer a horrible buggy but shiny application to a perfect working one



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: Modular Kernel Packaging for Cloud -> glibc-common

[Reindl Harald]

Am 05.03.2014 16:02, schrieb Josh Boyer:
> FWIW, the existing kernel package installed today (a debug kernel
> even) is ~142 MB.  123MB of that is the /lib/modules content.  ~6MB of
> that is vmlinuz.  The remaining 13MB is the initramfs, which is
> actually something that composes on the system during install and not
> something we can shrink from a packaging standpoint

honestly "glibc-common" would be more useful and less critical
to split into subpackages

* missing a locale and fallback to english leaves the option
  install whatever package - i would not miss anything than
  "de" and "en" on all machines i maintain - cloud or not

* missing a kernel module and refuse to boot is critical

because of that CC to @devel


114,08 MB  glibc-common
132,60 MB  kernel

[harry@rh]$ rpm -q --filesbypkg glibc-common | grep locale | wc -l
419

[harry@rh]$ rpm -q --filesbypkg glibc-common | grep -v locale | wc -l
257




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: fedpkg build failing (due to NSS?)

[Reindl Harald]

Am 03.03.2014 09:14, schrieb Mathieu Bridon:
> On Mon, 2014-03-03 at 16:06 +0800, Christopher Meng wrote:
>> I've left a negative karma there, they forgot to add the new nss-util
>> into overrides list.
> 
> No, it's been added, but then it was expired:
> https://admin.fedoraproject.org/updates/override/edit?build=nss-util-3.15.5-1.fc20
> https://admin.fedoraproject.org/updates/override/edit?build=nss-softokn-3.15.5-1.fc20
> 
> That's not the problem at all.
> 
> The problem is that **some** of these 3 overrides were epired, but not
> all.
> 
> The three packages need to always be in overrides together, or none of
> them.
> 
> Leaving a negative karma to the update won't help fix the problem
> either

i simply do not get why they are not built from the same srpm

https://fedoraproject.org/wiki/Features/SplitSoftoknFromNSS
is invalid - if there are no hard dependencies between the
subpackages then this is no valid reason no just build
all of them at once because finally it happens anyways
that they are available in the same version

https://bugzilla.redhat.com/show_bug.cgi?id=1066877#c4



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: default file system, was: Comparison to Workstation Technical Specification

[Reindl Harald]

Am 02.03.2014 19:38, schrieb Chris Murphy:
> Is it reasonable to expose untested features in the UI? RAID 1 and RAID 10 
> are probably 
> reasonably well tested because they meet the requirements (and then some) for 
> many use 
> cases. We have test cases for them. There are no RAID 4 or RAID 6 test cases, 
> so should 
> users be permitted to choose untested options?

wrong direction - if we are talk about Fedora.next the main question is why
are they not tested and not "don't use them because we don't test"

as said: if Fedora wants to compete with commercial solutions where nobody
spends a second to consider if RAID5/RAID6 is supported for whatever because
it is unconditional clear you argue the wrong direction

there are people using RAID6 for *anything* because it is *common knowledge*
that after one disk fails the chance due rebuild have another one fails is
way too high and RAID10 does *not* help here if it comes to important data

the problem of RAID10 is that the right one second disks needs to fail and
you can hardly chose that - in case of important data you must not need to
hope, you need safety



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: Major release number bump is lower than beta for html5lib module.

[Reindl Harald]

Am 02.03.2014 03:35, schrieb Christopher Meng:
> You should ask upstream if this is a mistake or a misleading naming.
> Remember try not to use epoch for packages, it's dirty hack

yes it is a hack but better than fake version numbers to
satisfy RPM and that is *the* reason epoch exists 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: default file system, was: Comparison to Workstation Technical Specification

[Reindl Harald]

Am 02.03.2014 02:11, schrieb Chris Murphy:
> On Mar 1, 2014, at 5:44 PM, Reindl Harald  wrote:
>> Am 02.03.2014 01:36, schrieb Chris Murphy:
>>> On Mar 1, 2014, at 4:51 PM, Reindl Harald  wrote:
>>>
>>>> Am 02.03.2014 00:42, schrieb Chris Murphy:
>>>>>
>>>>> On Mar 1, 2014, at 4:26 PM, Chris Murphy  wrote:
>>>>>
>>>>>>
>>>>>> On Mar 1, 2014, at 2:16 PM, Matthew Miller  
>>>>>> wrote:
>>>>>>
>>>>>>> On Fri, Feb 28, 2014 at 11:29:30PM -0700, Chris Murphy wrote:
>>>>>>>> - There needs to be a mandate to remove features from custom 
>>>>>>>> partitioning
>>>>>>>> that quite frankly don't make sense like rootfs on raid4, raid5 or
>>>>>>>> raid6. OK maybe raid5. But not raid 4 or raid 6. There are other
>>>>>>>
>>>>>>> Okay, I'll bite. Why not rootfs on raid6?
>>>>>>
>>>>>> It's pathological. There are too many simpler, faster, more resilient 
>>>>>> options considering rootfs at most isn't bigger than the average SSD: 
>>>>>> Two or three SSDs + n-way mirroring. RAID 10. Or RAID 1 + linear + XFS 
>>>>>> for deterministic workloads.
>>>>>
>>>>> Those three examples are simpler, more resilient, easier to configure and 
>>>>> maintain, perform better, with faster rebuild times than RAID 6 which 
>>>>> also has a high read-modify-write penalty. I left that part out.
>>>>
>>>> yes, but RAID6 allows a disk-fault *while* rebuild the RAID after the 
>>>> first one
>>>> RADID 10 *may* do the same if the *right* second disk fails
>>>
>>> If you need two disk failure tolerance use n-way mirroring with three 
>>> disks, anaconda supports this
>>
>> and if you need failure tolerance *and* performance?
> 
> You need better rootfs performance than what's provided by SSD?

no, i don't use SSD at all and many don't for good reasons

if you do not have endless disk slots and need a lot of storage you
have to decide and no place for rootfs on SSD

>> yes, then use commercial SAN storages…
> 
> OK, but it sounds expensive and demeaning

but it works and has 365/7/24 support in case of troubles
*that* is the place where Fedora has to fight in case of storage

> Yet, I'll grant that it's more sane than rootfs on software RAID 6

and that is why my 30 Fedora production servers are running on top
of VMware vSphere and a HP SAN storage with RAID6 for many years

in that case i do not need to care what Fedora supports "sane" for
rootfs and that is what Fedora needs to beat or the storage area
will continue to run commercial storage area of it comes to business



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: default file system, was: Comparison to Workstation Technical Specification

[Reindl Harald]

Am 02.03.2014 01:36, schrieb Chris Murphy:
> On Mar 1, 2014, at 4:51 PM, Reindl Harald  wrote:
> 
>> Am 02.03.2014 00:42, schrieb Chris Murphy:
>>>
>>> On Mar 1, 2014, at 4:26 PM, Chris Murphy  wrote:
>>>
>>>>
>>>> On Mar 1, 2014, at 2:16 PM, Matthew Miller  
>>>> wrote:
>>>>
>>>>> On Fri, Feb 28, 2014 at 11:29:30PM -0700, Chris Murphy wrote:
>>>>>> - There needs to be a mandate to remove features from custom partitioning
>>>>>> that quite frankly don't make sense like rootfs on raid4, raid5 or
>>>>>> raid6. OK maybe raid5. But not raid 4 or raid 6. There are other
>>>>>
>>>>> Okay, I'll bite. Why not rootfs on raid6?
>>>>
>>>> It's pathological. There are too many simpler, faster, more resilient 
>>>> options considering rootfs at most isn't bigger than the average SSD: Two 
>>>> or three SSDs + n-way mirroring. RAID 10. Or RAID 1 + linear + XFS for 
>>>> deterministic workloads.
>>>
>>> Those three examples are simpler, more resilient, easier to configure and 
>>> maintain, perform better, with faster rebuild times than RAID 6 which also 
>>> has a high read-modify-write penalty. I left that part out.
>>
>> yes, but RAID6 allows a disk-fault *while* rebuild the RAID after the first 
>> one
>> RADID 10 *may* do the same if the *right* second disk fails
> 
> If you need two disk failure tolerance use n-way mirroring with three disks, 
> anaconda supports this

and if you need failure tolerance *and* performance?
yes, then use commercial SAN storages...



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: default file system, was: Comparison to Workstation Technical Specification

[Reindl Harald]

Am 02.03.2014 00:42, schrieb Chris Murphy:
> 
> On Mar 1, 2014, at 4:26 PM, Chris Murphy  wrote:
> 
>>
>> On Mar 1, 2014, at 2:16 PM, Matthew Miller  wrote:
>>
>>> On Fri, Feb 28, 2014 at 11:29:30PM -0700, Chris Murphy wrote:
 - There needs to be a mandate to remove features from custom partitioning
 that quite frankly don't make sense like rootfs on raid4, raid5 or
 raid6. OK maybe raid5. But not raid 4 or raid 6. There are other
>>>
>>> Okay, I'll bite. Why not rootfs on raid6?
>>
>> It's pathological. There are too many simpler, faster, more resilient 
>> options considering rootfs at most isn't bigger than the average SSD: Two or 
>> three SSDs + n-way mirroring. RAID 10. Or RAID 1 + linear + XFS for 
>> deterministic workloads.
> 
> Those three examples are simpler, more resilient, easier to configure and 
> maintain, perform better, with faster rebuild times than RAID 6 which also 
> has a high read-modify-write penalty. I left that part out.

yes, but RAID6 allows a disk-fault *while* rebuild the RAID after the first one
RADID 10 *may* do the same if the *right* second disk fails

in real life disks are mostly identical old and in case one fails the chance
that anotehr one fails within a short timeframe is high and the rebuild makes
it even more likely

frankly i saw SAN configurations where after remove 20 disks the system said
"if now anotehr one fails *we maybe* have a problem" and in real life the
performance penalty is meaningless compared to a complete fail of the array



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: default file system, was: Comparison to Workstation Technical Specification

[Reindl Harald]

Am 01.03.2014 22:55, schrieb poma:
> On 27.02.2014 01:33, Josef Bacik wrote:
> 
>> Just popping in here to say that btrfs is not ready to be default in Fedora
>> yet.  Optional is fine but not default.  Thanks,
>>
> This is actually a good news.
> Thanks.
> 
> Now all we need is fair support in the installer.
> BTRFS as alternative scheme:
> +1 "F-Server"
> +1 "F-Workstation"

one of the BTRFS maintainers explains is is *not* ready
and you start "we need" in context of BTRFS? strange logic



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: default file system, was: Comparison to Workstation Technical Specification

[Reindl Harald]

Am 01.03.2014 16:42, schrieb Orion Poplawski:
> On 03/01/2014 05:04 AM, Ian Malone wrote:
>>
>> As you say they are 'plain' filesystems. Though I now regret not
>> sending my small datapoint in before the Server WG decision. That's
>> that a while ago, after using XFS for a long time we started putting
>> new filesystems onto ext4 and in the past month we moved probably our
>> largest remaining dataset (1.1TB) from XFS to ext4, the main reason
>> has been flexibility with resizing. Particularly the XFS 32bit inode
>> ceiling, (inode64 not working well with NFS).
> 
> Could you speak more to the inode64/NFS issue?

https://www.google.com/search?q=inode64+nfs



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: Major release number bump is lower than beta for html5lib module.

[Reindl Harald]

Am 01.03.2014 15:36, schrieb Praveen Kumar:
> Recently Dan filled bug[0] against html5lib[1] module about new
> upstream release but upstream put major version 0.999 which is lower
> that it's beta version 1.0b3.
> 
> Now If I update spec file according to upstream release version should
> yum able to identify that 0.999 > 1.0b3? or should I go ahead and make
> change as Dan suggested to use version 1.0b3-0.999?
> 
> [0] https://bugzilla.redhat.com/show_bug.cgi?id=1070082
> [1] https://pypi.python.org/pypi/html5lib

that's why Epoch exists



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: exclude people from giving karma?

[Reindl Harald]

Am 28.02.2014 03:54, schrieb Michael Catanzaro:
> On Thu, 2014-02-27 at 02:18 +0100, Kevin Kofler wrote:
>> But again, I think that even with no other policy change, just
>> removing the 
>> "karma automatism" misfeature from Bodhi would be an improvement.
> 
> Or requiring min time in updates-testing (2-3 days) before an
> autokarma-assisted push

for non-security major updates this should be a MUST as in a RFC



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: exclude people from giving karma?

[Reindl Harald]

Am 24.02.2014 04:59, schrieb Kevin Kofler:
> Reindl Harald wrote:
>> how can people pretend "installation went smoothly, no issue detected
>> during basic document manipulation" for packages which are not installable
>> at all due dependencie problems?
> 
> Indeed, people giving +1 after manually installing dependencies (!!!) from 
> Koji (for a package that is itself already in updates-testing, so 
> (obviously!) the dependencies MUST be AT LEAST in updates-testing at the 
> time of testing for the update to be valid!) should be banned from Bodhi.
> 
> That said, may I remind you that you have recently given a +1 to a very 
> broken kdelibs update (kdelibs-4.11.3-6.fc19, which was causing crashes 
> during autostart)? (Thankfully, the update didn't make it to stable anyway; 
> we replaced it with a fixed build.) So please also be careful with your own 
> +1 votes. :-)

that must have been end 2013 and since i don't remember a 35 chars
password that leads to my "easy-karma.sh" echo's the pwd for the
clipboard that karma was given out of a running KDE session



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: exclude people from giving karma?

[Reindl Harald]

Am 23.02.2014 22:40, schrieb Theodore Lee:
> On 24/02/14 06:29, Susi Lehtola wrote:
>> On Sun, 23 Feb 2014 18:12:55 +0100
>> Reindl Harald  wrote:
>>> https://admin.fedoraproject.org/updates/FEDORA-2014-2922/libreoffice-4.2.1.1-1.fc20?_csrf_token=a6a024f6e2d35ad3fb8666c1244e215a6aa2
>>>
>>> how can people pretend "installation went smoothly, no issue detected 
>>> during basic
>>> document manipulation" for packages which are not installable at all due
>>> dependencie problems?
>>
>> People *couldn't* know there were problems, because all the positive
>> reports were from the time the update was in updates-testing. All who
>> tried the update, also had the dependency available in updates-testing.
> 
> For what it's worth, my report (the first with the dependency issue) and
> a subsequent one were also from updates-testing, and both did not have
> the dependency available.

they never did

> I did do a manual check of Koji and Bodhi to try and figure out why my
> results were different from the previous testers, and could only find
> the necessary build in Koji, which quite frankly left me very confused
> and unsure if I was experiencing some kind of mirror sync issue and/or
> chronic lack of coffee syndrome. I now understand the initial positive
> karma results had something to do with a buildroot override

which never hit updates-testing

2014-02-21 13:59:06 This update has been submitted for testing by dtardo
2014-02-22 09:35:15 will be pushed to the stable updates repository

this is *unacceptable* in case of broken deps and buildroot overrides
while this is not a secuity update and people are pushing such things
to stable refuse to understand the the dependecy error may result in
*not get whatever SECURITY UPDATE* for ordinary users for no gain

and no "you have to apologize" from the maintainer does change that

if the maintainers would run a baisc virtual machine consuming
ordinary repos without manual overrides such mistakes would be
recognized by them..



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: Creating local repo

[Reindl Harald]

Am 23.02.2014 18:29, schrieb Mauricio Tavares:
> Could anyone point me to info on creating a local repo? I want to learn the 
> entire process of creating a package
> but think it might be wiser to have a controlled environment

* yum install createrepo
* createrepo /path/to/your/rpms
* put a file in /etc/yum.repos.d/ pointing to a FTP/HTTP server
  configured for /path/to/your/rpms or if it is only local
  simply to the folder



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: exclude people from giving karma?

[Reindl Harald]

Am 23.02.2014 18:36, schrieb Reindl Harald:
> 
> Am 23.02.2014 18:33, schrieb Christopher Meng:
>> Let's test this one asap to prevent epoch(if you want):
>>
>> https://admin.fedoraproject.org/updates/libcmis-0.4.1-2.fc20,mdds-0.10.2-1.fc20
>>
>> Last weekend bodhi seemed very slow on processing updates, so I
>> downloaded and installed from koji by myself
> 
> DO NOT DO THAT AND THEN GIVE POSITIVE KARMA BECAUSE YOU LIE
> FOR ANYBODY WHO IS NOT YOU

yes, by downloading the dependency *manually* it resolves *now*
that the libreoffice update is in stable updates - but you
simply forgot your *responsibility* by giving karma for a major
update where you are even aware taht currently deps are broken
__

[root@srv-rhsoft:~]$ cd /downloads/
[root@srv-rhsoft:/downloads]$ ls
total 468K
-rw-r- 1 harry verwaltung 412K 2014-02-23 18:39 
libcmis-0.4.1-2.fc20.x86_64.rpm
-rw-r- 1 harry verwaltung  56K 2014-02-23 18:39 
libcmis-tools-0.4.1-2.fc20.x86_64.rpm
[root@srv-rhsoft:/downloads]$ yum update *.rpm
Loaded plugins: etckeeper, protectbase, tsflags
Examining libcmis-0.4.1-2.fc20.x86_64.rpm: libcmis-0.4.1-2.fc20.x86_64
Marking libcmis-0.4.1-2.fc20.x86_64.rpm as an update to 
libcmis-0.3.1-8.fc20.x86_64
Examining libcmis-tools-0.4.1-2.fc20.x86_64.rpm: 
libcmis-tools-0.4.1-2.fc20.x86_64
Package libcmis-tools not installed, cannot update it. Run yum install to 
install it instead.
Resolving Dependencies
--> Running transaction check
---> Package libcmis.x86_64 0:0.3.1-8.fc20 will be updated
--> Processing Dependency: libcmis-0.3.so.3()(64bit) for package: 
1:libreoffice-core-4.1.5.3-1.fc20.x86_64
rhsoft-fedora   
 | 2.9 kB
00:00:00
rhsoft-generic  
 | 2.9 kB
00:00:00
0 packages excluded due to repository protections
---> Package libcmis.x86_64 0:0.4.1-2.fc20 will be an update
--> Running transaction check
---> Package libreoffice-core.x86_64 1:4.1.5.3-1.fc20 will be updated
--> Processing Dependency: libreoffice-core = 1:4.1.5.3-1.fc20 for package: 
1:libreoffice-calc-4.1.5.3-1.fc20.x86_64
--> Processing Dependency: libreoffice-core = 1:4.1.5.3-1.fc20 for package: 
1:libreoffice-writer-4.1.5.3-1.fc20.x86_64
--> Processing Dependency: libreoffice-core = 1:4.1.5.3-1.fc20 for package:
1:libreoffice-graphicfilter-4.1.5.3-1.fc20.x86_64
--> Processing Dependency: libreoffice-core = 1:4.1.5.3-1.fc20 for package:
1:libreoffice-langpack-de-4.1.5.3-1.fc20.x86_64
--> Processing Dependency: libreoffice-core = 1:4.1.5.3-1.fc20 for package: 
1:libreoffice-draw-4.1.5.3-1.fc20.x86_64
--> Processing Dependency: libreoffice-core = 1:4.1.5.3-1.fc20 for package:
1:libreoffice-pdfimport-4.1.5.3-1.fc20.x86_64
--> Processing Dependency: libreoffice-core = 1:4.1.5.3-1.fc20 for package: 
1:libreoffice-impress-4.1.5.3-1.fc20.x86_64
---> Package libreoffice-core.x86_64 1:4.2.1.1-1.fc20 will be an update
--> Processing Dependency: libreoffice-ure = 1:4.2.1.1-1.fc20 for package: 
1:libreoffice-core-4.2.1.1-1.fc20.x86_64
--> Processing Dependency: libreoffice-opensymbol-fonts = 1:4.2.1.1-1.fc20 for 
package:
1:libreoffice-core-4.2.1.1-1.fc20.x86_64
--> Processing Dependency: libuno_sal.so.3(LIBO_UDK_4.2)(64bit) for package: 
1:libreoffice-core-4.2.1.1-1.fc20.x86_64
--> Processing Dependency: libfbembed.so.2.5()(64bit) for package: 
1:libreoffice-core-4.2.1.1-1.fc20.x86_64
--> Processing Dependency: libeot.so.0()(64bit) for package: 
1:libreoffice-core-4.2.1.1-1.fc20.x86_64
--> Running transaction check
---> Package firebird-libfbembed.x86_64 0:2.5.2.26539.0-8.fc20 will be installed
---> Package libeot.x86_64 0:0.01-1.fc20 will be installed
---> Package libreoffice-calc.x86_64 1:4.1.5.3-1.fc20 will be updated
---> Package libreoffice-calc.x86_64 1:4.2.1.1-1.fc20 will be an update
---> Package libreoffice-draw.x86_64 1:4.1.5.3-1.fc20 will be updated
---> Package libreoffice-draw.x86_64 1:4.2.1.1-1.fc20 will be an update
---> Package libreoffice-graphicfilter.x86_64 1:4.1.5.3-1.fc20 will be updated
---> Package libreoffice-graphicfilter.x86_64 1:4.2.1.1-1.fc20 will be an update
--> Processing Dependency: libfreehand-0.0.so.0()(64bit) for package: 
1:libreoffice-graphicfilter-4.2.1.1-1.fc20.x86_64
--> Processing Dependency: libetonyek-0.0.so.0()(64bit) for package: 
1:libreoffice-graphicfilter-4.2.1.1-1.fc20.x86_64
---> Package libreoffice-impress.x86_64 1:4.1.5.3-1.fc20 will be updated
---> Package libreoffice-impress.x86_64 1:4.2.1.1-1.fc20 will be an update
---> Package libreoffice-langpack-de.x86_64 1:4.1.5.3-1.fc20 will be updated
---> Package libreoffice-langpack-de.x86_64 1:4.2.1.1-1.fc20 will be an update
---> Package libreoffice-opensymbol-fonts.noarch 1:4.1.5.3-1.fc20 will

Re: exclude people from giving karma?

[Reindl Harald]

Am 23.02.2014 18:35, schrieb drago01:
> On Sun, Feb 23, 2014 at 6:31 PM, Reindl Harald  wrote:
>> that is impossible
>>
>> "libreoffice-core" is affected by a broken dependency
>> frankly i have the koji repo endabled (look at the bottom)
> 
> I have no idea what "the koji repo" is but
> https://admin.fedoraproject.org/updates/libcmis-0.4.1-2.fc20,mdds-0.10.2-1.fc20
> and http://koji.fedoraproject.org/koji/buildinfo?buildID=499516
> 
> If the package did never exist as you claim the libreoffice package
> could not have been built in the first place

one of the people who gave karma already statet that
he downloaded the missing dependenc< *manually* from
koji and so he *must not* give karma for a stable update

> I have no idea what "the koji repo" is

[root@srv-rhsoft:~]$ cat /etc/yum.repos.d/koji.repo
[koji]
name=Koji Repo
baseurl=http://koji.fedoraproject.org/repos/f$releasever-build/latest/$basearch/
enabled=0
skip_if_unavailable=1
gpgcheck=0



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: exclude people from giving karma?

[Reindl Harald]

Am 23.02.2014 18:33, schrieb Christopher Meng:
> Let's test this one asap to prevent epoch(if you want):
> 
> https://admin.fedoraproject.org/updates/libcmis-0.4.1-2.fc20,mdds-0.10.2-1.fc20
> 
> Last weekend bodhi seemed very slow on processing updates, so I
> downloaded and installed from koji by myself

DO NOT DO THAT AND THEN GIVE POSITIVE KARMA BECAUSE YOU LIE
FOR ANYBODY WHO IS NOT YOU - LOOK BELOW


Error: Package: 1:libreoffice-core-4.2.1.1-1.fc20.x86_64 (koji)
   Requires: libcmis-0.4.so.4()(64bit)
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest
[root@srv-rhsoft:~]$ rpm -qa | grep -i cmi
libcmis-0.3.1-8.fc20.x86_64
[root@srv-rhsoft:~]$ yum --enablerepo=koji update libcmis
Loaded plugins: etckeeper, protectbase, tsflags
rhsoft-fedora   
 | 2.9 kB
00:00:00
rhsoft-generic  
 | 2.9 kB
00:00:00
0 packages excluded due to repository protections
No packages marked for update



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: exclude people from giving karma?

[Reindl Harald]

that is impossible

"libreoffice-core" is affected by a broken dependency
frankly i have the koji repo endabled (look at the bottom)

so the only option to explain teh positive karma is a login
on bodhi, don't care about the installed version and for what
one is giving karma (there where more libreoffice updates in
the last weeks) and if someone does even not manage to compare
the version number of what he has installed and for what he
is in fact giving karma that's a problem

additionally to the problem that i expect froma maintainer
to install a package at least by him self

and *yes* i support that update inside a stbale-release
but not how poor it is managed from all directions

Am 23.02.2014 18:26, schrieb Michał Piotrowski:
> Maybe they didn't have any issues?
> 
> 
> 2014-02-23 18:12 GMT+01:00 Reindl Harald  <mailto:h.rei...@thelounge.net>>:
> 
> 
> https://admin.fedoraproject.org/updates/FEDORA-2014-2922/libreoffice-4.2.1.1-1.fc20?_csrf_token=a6a024f6e2d35ad3fb8666c1244e215a6aa2
> 
> how can people pretend "installation went smoothly, no issue detected 
> during basic
> document manipulation" for packages which are not installable at all due
> dependencie problems?

[root@srv-rhsoft:~]$ yum --enablerepo=koji upgrade
Loaded plugins: etckeeper, protectbase, tsflags
koji
 | 3.6 kB
Resolving Dependencies
--> Running transaction check
---> Package autocorr-de.noarch 1:4.1.5.3-1.fc20 will be updated
---> Package autocorr-de.noarch 1:4.2.1.1-1.fc20 will be an update
---> Package autocorr-en.noarch 1:4.1.5.3-1.fc20 will be updated
---> Package autocorr-en.noarch 1:4.2.1.1-1.fc20 will be an update
---> Package libreoffice-calc.x86_64 1:4.1.5.3-1.fc20 will be updated
---> Package libreoffice-calc.x86_64 1:4.2.1.1-1.fc20 will be an update
---> Package libreoffice-core.x86_64 1:4.1.5.3-1.fc20 will be updated
---> Package libreoffice-core.x86_64 1:4.2.1.1-1.fc20 will be an update
--> Processing Dependency: libfbembed.so.2.5()(64bit) for package: 
1:libreoffice-core-4.2.1.1-1.fc20.x86_64
--> Processing Dependency: libeot.so.0()(64bit) for package: 
1:libreoffice-core-4.2.1.1-1.fc20.x86_64
--> Processing Dependency: libcmis-0.4.so.4()(64bit) for package: 
1:libreoffice-core-4.2.1.1-1.fc20.x86_64
---> Package libreoffice-draw.x86_64 1:4.1.5.3-1.fc20 will be updated
---> Package libreoffice-draw.x86_64 1:4.2.1.1-1.fc20 will be an update
---> Package libreoffice-graphicfilter.x86_64 1:4.1.5.3-1.fc20 will be updated
---> Package libreoffice-graphicfilter.x86_64 1:4.2.1.1-1.fc20 will be an update
--> Processing Dependency: libfreehand-0.0.so.0()(64bit) for package: 
1:libreoffice-graphicfilter-4.2.1.1-1.fc20.x86_64
--> Processing Dependency: libetonyek-0.0.so.0()(64bit) for package: 
1:libreoffice-graphicfilter-4.2.1.1-1.fc20.x86_64
---> Package libreoffice-impress.x86_64 1:4.1.5.3-1.fc20 will be updated
---> Package libreoffice-impress.x86_64 1:4.2.1.1-1.fc20 will be an update
---> Package libreoffice-langpack-de.x86_64 1:4.1.5.3-1.fc20 will be updated
---> Package libreoffice-langpack-de.x86_64 1:4.2.1.1-1.fc20 will be an update
---> Package libreoffice-opensymbol-fonts.noarch 1:4.1.5.3-1.fc20 will be 
updated
---> Package libreoffice-opensymbol-fonts.noarch 1:4.2.1.1-1.fc20 will be an 
update
---> Package libreoffice-pdfimport.x86_64 1:4.1.5.3-1.fc20 will be updated
---> Package libreoffice-pdfimport.x86_64 1:4.2.1.1-1.fc20 will be an update
---> Package libreoffice-ure.x86_64 1:4.1.5.3-1.fc20 will be updated
---> Package libreoffice-ure.x86_64 1:4.2.1.1-1.fc20 will be an update
---> Package libreoffice-writer.x86_64 1:4.1.5.3-1.fc20 will be updated
---> Package libreoffice-writer.x86_64 1:4.2.1.1-1.fc20 will be an update
--> Processing Dependency: libe-book-0.0.so.0()(64bit) for package: 
1:libreoffice-writer-4.2.1.1-1.fc20.x86_64
--> Processing Dependency: libabw-0.0.so.0()(64bit) for package: 
1:libreoffice-writer-4.2.1.1-1.fc20.x86_64
--> Running transaction check
---> Package firebird-libfbembed.x86_64 0:2.5.2.26539.0-8.fc20 will be installed
---> Package libabw.x86_64 0:0.0.2-1.fc20 will be installed
---> Package libe-book.x86_64 0:0.0.3-1.fc20 will be installed
---> Package libeot.x86_64 0:0.01-1.fc20 will be installed
---> Package libetonyek.x86_64 0:0.0.3-1.fc20 will be installed
---> Package libfreehand.x86_64 0:0.0.0-3.fc20 will be installed
---> Package libreoffice-core.x86_64 1:4.2.1.1-1.fc20 will be an update
--> Processing Dependency: libcmis-0.4.so.4()(64bit) for package: 
1:libreoffice-core-4.2.1.1-1.fc20.x86_64
--> Finished Dependency Resolution
--> Finding unneeded leftover dependencies
Found and removing 0 unneeded dependencies
Error: Package: 1:libreoffice-core

exclude people from giving karma?

[Reindl Harald]

https://admin.fedoraproject.org/updates/FEDORA-2014-2922/libreoffice-4.2.1.1-1.fc20?_csrf_token=a6a024f6e2d35ad3fb8666c1244e215a6aa2

how can people pretend "installation went smoothly, no issue detected during 
basic
document manipulation" for packages which are not installable at all due
dependencie problems?



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: Proposal to WGs and rel-eng: Move 90-default.preset from systemd to fedora-release

[Reindl Harald]

Am 21.02.2014 23:30, schrieb Kevin Kofler:
> Colin Walters wrote:
>> That would mean that if we wanted to enable a new service by default,
>> admins wouldn't get it on upgrades.
> 
> … which is how it should be. I don't want upgrades to mess with my set of 
> enabled services. (E.g., I found it extremely rude from firewalld to enable 
> itself by default on upgrades.)

the same for avahi

looks like samba with F19 pulls it, fine, finally
i recently realized that on one of our main servers

* avahi was pulled with the dist-upgrade to F19
* there is no chance to get rid of it if you use samba
* it get *enabled* and started it with the reboot
* because i *hardly* avoid it anywhere  to be installed
  and i did not expect it on dist-upgrade number 10 on that machine
* it was runnign for some weeks for *no reason* there

shiny new world where the best you can do is "systemctl mask whatever"
to avoid get things you *absoluetly* not want installed and enabled
by random updates

--> Running transaction check
---> Package avahi.x86_64 0:0.6.31-11.fc19 will be erased
--> Processing Dependency: avahi = 0.6.31-11.fc19 for package: 
avahi-libs-0.6.31-11.fc19.x86_64
--> Running transaction check
---> Package avahi-libs.x86_64 0:0.6.31-11.fc19 will be erased
--> Processing Dependency: libavahi-client.so.3()(64bit) for package: 
1:cups-libs-1.6.4-2.fc19.x86_64
--> Processing Dependency: libavahi-common.so.3()(64bit) for package: 
1:cups-libs-1.6.4-2.fc19.x86_64
--> Running transaction check
---> Package cups-libs.x86_64 1:1.6.4-2.fc19 will be erased
--> Processing Dependency: libcups.so.2()(64bit) for package: 
ghostscript-9.10-5.fc19.x86_64
--> Processing Dependency: libcups.so.2()(64bit) for package: 
2:samba-libs-4.0.13-1.fc19.x86_64
--> Processing Dependency: libcupsimage.so.2()(64bit) for package: 
ghostscript-9.10-5.fc19.x86_64
--> Running transaction check
---> Package ghostscript.x86_64 0:9.10-5.fc19 will be erased
--> Processing Dependency: libgs.so.9()(64bit) for package: 
ImageMagick-6.7.8.9-5.fc19.x86_64
---> Package samba-libs.x86_64 2:4.0.13-1.fc19 will be erased
--> Processing Dependency: samba-libs = 2:4.0.13-1.fc19 for package: 
2:libsmbclient-4.0.13-1.fc19.x86_64
--> Processing Dependency: samba-libs = 2:4.0.13-1.fc19 for package: 
2:samba-4.0.13-1.fc19.x86_64
--> Processing Dependency: samba-libs = 2:4.0.13-1.fc19 for package: 
2:samba-common-4.0.13-1.fc19.x86_64
--> Processing Dependency: samba-libs = 2:4.0.13-1.fc19 for package: 
2:samba-client-4.0.13-1.fc19.x86_64



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: [Fedora-packaging] May I file 1000 bugs aka upstream test suite tracking

[Reindl Harald]

Am 21.02.2014 15:51, schrieb Alexander Todorov:
> На 21.02.2014 16:27, Richard W.M. Jones написа:
>> Is it correct that you're only going to be filing bugs when upstream
>> tarballs already contain test suites, but they are just not enabled in
>> the Fedora package?
> 
> I want to track which packages *DO NOT* have any tests and later be 
> able to focus on creating them (be it working with volunteers, GSoC 
> participants or whoever is willing to step up to this task).
> 
> I don't intend to force package maintainers to write tests if they 
> don't want to (or can't)

then bugzilla is for sure the wrong place

all these bug report would making only noise, mostly get
closed with WONTFIX or close dby the bugzapper, it's a
waste of time and energy for people not responsible for
but hear the noise

in the worst case some packagers write some hurry tests
to make you happy which are not worth one line written
for them because they don't conver anything and so does
not help in case of breakage in later builds

often enough writing good tests is more work than the software itself



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: how does somobeody install perl(ExtUtils::Embed)

[Reindl Harald]

Am 17.02.2014 17:42, schrieb Richard W.M. Jones:
> On Mon, Feb 17, 2014 at 12:11:54PM +0100, Martin Briza wrote:
>> On Mon, 17 Feb 2014 12:08:53 +0100, Reindl Harald
>>  wrote:
>>
>>>
>>> [builduser@buildserver64:/rpmbuild/SPECS]$ rpmbuild -bb subversion.spec
>>> error: Failed build dependencies:
>>>perl(ExtUtils::Embed) is needed by
>>> subversion-1.8.5-2.fc20.20140217.rh.x86_64
>>>rubygem(minitest) is needed by
>>> subversion-1.8.5-2.fc20.20140217.rh.x86_64
>>> [builduser@buildserver64:/rpmbuild/SPECS]$ sudo yum install
>>> perl(ExtUtils::Embed) rubygem(minitest)
>>> -bash: syntax error near unexpected token `('
>>> _
>>>
>>> how is somebody expected to translate such Require / Build-Requires
>>> to a package name yum understands?
>>>
>>
>>  yum-builddep subversion
> 
> or even better in this case:
> 
> yum-builddep ./subversion.spec

*that* is cool - thanks!



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

unsure for which package report a bug

[Reindl Harald]

what happened below is typing "rpmü" followed by a backspace
interesting is that it results in a error message and in
the history you have to press backspace again to get rid
of a invisible char

INTERESTING:
* normally the machine is german
* this happens only after LANG=C
___

[builduser@buildserver64:/rpmbuild/SRPMS]$ rpm -ivh *.rpmü
error: File not found by glob: *.rpmü
[builduser@buildserver64:/rpmbuild/SRPMS]$ rpm -ivh *.rpm
error: File not found by glob: *.rpm�
[builduser@buildserver64:/rpmbuild/SRPMS]$ rpm -ivh *.rpm
Updating / installing...
   1:GeoIP-1.6.0-1.fc20.20140217.rh   # [100%]



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: how does somobeody install perl(ExtUtils::Embed)

[Reindl Harald]

Am 17.02.2014 12:10, schrieb Paul Howarth:
> On 17/02/14 11:08, Reindl Harald wrote:
>>
>> [builduser@buildserver64:/rpmbuild/SPECS]$ rpmbuild -bb subversion.spec
>> error: Failed build dependencies:
>>  perl(ExtUtils::Embed) is needed by 
>> subversion-1.8.5-2.fc20.20140217.rh.x86_64
>>  rubygem(minitest) is needed by 
>> subversion-1.8.5-2.fc20.20140217.rh.x86_64
>> [builduser@buildserver64:/rpmbuild/SPECS]$ sudo yum install 
>> perl(ExtUtils::Embed) rubygem(minitest)
>> -bash: syntax error near unexpected token `('
>> _
>>
>> how is somebody expected to translate such Require / Build-Requires
>> to a package name yum understands?
> 
> By quoting them:
> 
> $ sudo yum install 'perl(ExtUtils::Embed)' 'rubygem(minitest)'

oh, thanks

Build-Requires: perl-ExtUtils-Embed rubygem-minitest

would do the same without special chars, no idea why
things are done the hard way here and there



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

how does somobeody install perl(ExtUtils::Embed)

[Reindl Harald]

[builduser@buildserver64:/rpmbuild/SPECS]$ rpmbuild -bb subversion.spec
error: Failed build dependencies:
perl(ExtUtils::Embed) is needed by 
subversion-1.8.5-2.fc20.20140217.rh.x86_64
rubygem(minitest) is needed by 
subversion-1.8.5-2.fc20.20140217.rh.x86_64
[builduser@buildserver64:/rpmbuild/SPECS]$ sudo yum install 
perl(ExtUtils::Embed) rubygem(minitest)
-bash: syntax error near unexpected token `('
_

how is somebody expected to translate such Require / Build-Requires
to a package name yum understands?



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: rpm bug 1065563 affecting httpd / php packages

[Reindl Harald]

Am 17.02.2014 11:37, schrieb Ville Skyttä:
> On Mon, Feb 17, 2014 at 12:07 PM, Remi Collet  
> wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Le 17/02/2014 10:24, Reindl Harald a écrit :
>>> are such changes allowed within a stable release?
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1065563
>>
>> As lot of package are using a bad virtual  provides / requires with a
>> double dash in EVR, and as a mass rebuild is probably a very bad idea
>> in stable release, I think this new check should only go in rawhide.
> 
> I don't think this calls for a mass rebuild or any kind of a rebuild
> actually, nor should it be rawhide only. AFAIU this doesn't affect
> runtime at all, only build time, and affected packages can be just
> fixed at the same time if they need an update in affected releases in
> the first place.

*no*

look here to see why
https://bugzilla.redhat.com/show_bug.cgi?id=1065563#c7

and the same will happen for *any* package built the
same way, i can only speak about the few i am using

yes, i am about rebuild subversion to get this solved because i have
now changed all these Provides/Requires in my *private* webstack
packages, but that shows it's not that simple you assume




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

rpm bug 1065563 affecting httpd / php packages

[Reindl Harald]

are such changes allowed within a stable release?
https://bugzilla.redhat.com/show_bug.cgi?id=1065563



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: Educating packagers about always making changes in devel / rawhide first

[Reindl Harald]

Am 12.02.2014 20:46, schrieb Josh Boyer:
> On Wed, Feb 12, 2014 at 2:42 PM, Reindl Harald  wrote:
>>
>> Am 12.02.2014 20:26, schrieb Peter Oliver:
>>> On 10 February 2014 16:42, Till Maas  wrote:
>>>
>>>> Isn't AutoQA already running these kind of checks?
>>>
>>> Here's an example:
>>> https://admin.fedoraproject.org/updates/FEDORA-2014-1847/AtomicParsley-0.9.5-2.fc20
>>
>> worthless as long "results are informative only"
>> it only will get effective if the build is purged until it passes
> 
> That is untrue.  I've pulled builds myself when I notice this fails.
> Please don't generalize like that.  It's effective and useful for
> maintainers that pay attention

stats would be interesting how many pay attention in case
they not get hurted noticeable

many maintainers do not pay attention if it does not hurt

otherwise systemd-bugs, bugs/typos in systemd-units and
systemd itself logged with every single "systemctl daemon-reload"
or reboot would not make it in GA releases and stay there over months




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: Educating packagers about always making changes in devel / rawhide first

[Reindl Harald]

Am 12.02.2014 20:26, schrieb Peter Oliver:
> On 10 February 2014 16:42, Till Maas  wrote:
> 
>> Isn't AutoQA already running these kind of checks?
> 
> Here's an example:
> https://admin.fedoraproject.org/updates/FEDORA-2014-1847/AtomicParsley-0.9.5-2.fc20

worthless as long "results are informative only"
it only will get effective if the build is purged until it passes



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: f20, anaconda, net install and video out of range ....

[Reindl Harald]

Am 07.02.2014 17:19, schrieb Paul Wouters:
> On Thu, 6 Feb 2014, Adam Williamson wrote:
> 
>> painstakingly hand-weeding something like M*a's ldetect-lst you can get
>> some minor benefits, like doing this kind of distinction where we want
>> to load the native driver for a real card but not qemu's emulated
>> cirrus.
> 
> You are telling me it is hard to detect the real physical card versus
> the emulated card? Come on! You can even make that decision by looking
> at the cpu type. If your cpu is QEMU Virtual CPU, how about using the
> virtual cirrus driver

correct

> Taking out everyone who tries to run fedora or rhel7 using a physical
> cirrus card IMHO is just sloppy and lazy. Yes, people still run P-III
> servers with SCSI disks and cirrus cards. In fact, I think you will
> see it more within the enterprise then outside it

you expect RHEL7 running on a PIII?
this train has passed by long ago

http://www.linux-mag.com/id/7618/
Although its still called the “i386″ architecture, the 32bit version has been 
built for i686 processors and later,
as well as being optimized for the Atom processor. This was done by setting the 
GCC CFLAGS to “-march=i686
-mtune=atom”. As such, Fedora loses the ability to run on i586 and older 
computers, but gains performance on
popular Atom based netbooks.



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: "a stop job is running for User Manager for 0"

[Reindl Harald]

Am 06.02.2014 20:59, schrieb Paul Wouters:
> On Thu, 6 Feb 2014, Reindl Harald wrote:
> 
>>> Regularly, we get tests failing because the VM does not boot within 60
>>> seconds, and seems to hang at:
>>>
>>> "a stop job is running for User Manager for 0"
>>
>> here you go
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1023820
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1010572
>> https://bugzilla.redhat.com/show_bug.cgi?id=1057811
>> https://bugzilla.redhat.com/show_bug.cgi?id=1057618
>> https://bugzilla.redhat.com/show_bug.cgi?id=1023788#c2
>>
>> now idea how this systemd made it in F20/RHEL7-Beta1 and why it takes
>> that long to fix so pretty clear bugs nor why prelink is not banned
>> at all in the distribution
> 
> Note that my test systems have never had prelink installed (and I've
> done my best to get prelink banished forever over the years)

one of the issues *looks* like prelink related
that's why i listed more than one bugreport

> It does seem to point to systemd related issues, although the only user
> on these systems is root.

which is user 0
that is yours, an not only yours
https://bugzilla.redhat.com/show_bug.cgi?id=1023820

however, systemd in F20 and RHEL17 is the most broken release
after F15, F16-F19 where improvements, F20 in case of systemd
is a massive step backwards in case of stability and bugs

sadly, because the rest of F20 is really stable and clean


https://bugzilla.redhat.com/show_bug.cgi?id=1023788 is simply
*unacceptable*  because it was reported *long* before final
release, is more than 3 months old and reproduceable with
every single reboot/shutdown via ssh



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: "a stop job is running for User Manager for 0"

[Reindl Harald]

Am 06.02.2014 20:43, schrieb Paul Wouters:
> 
> I'm using a minimal netinstall version of fedora20 for testing using
> KVM. We very often cycle these machines (once per test, we run hundreds
> of tests)
> 
> Regularly, we get tests failing because the VM does not boot within 60
> seconds, and seems to hang at:
> 
> "a stop job is running for User Manager for 0"

here you go

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

https://bugzilla.redhat.com/show_bug.cgi?id=1010572
https://bugzilla.redhat.com/show_bug.cgi?id=1057811
https://bugzilla.redhat.com/show_bug.cgi?id=1057618
https://bugzilla.redhat.com/show_bug.cgi?id=1023788#c2

now idea how this systemd made it in F20/RHEL7-Beta1 and why it takes
that long to fix so pretty clear bugs nor why prelink is not banned
at all in the distribution




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: What is the usage of an empty RPM ?

[Reindl Harald]

example of how to build meta packages

some obsoletes/provides are hacks to get rid of useless
dependencies or workarounds for UsrMove-bugs

the really relevant is "Requires:"
they do not need to privide files
they only ned to provide dependencies

[builduser@buildserver:~]$ cat /rpmbuild/SPECS/lounge-base.spec
Summary:   metapackage for thelounge.net default packages
Name:  lounge-base
Version:   19.0
Release:   1%{?dist}
BuildArch: noarch
Group: System Environment/Libraries
URL:   http://www.thelounge.net/
License:   GPL

Obsoletes: php-interbase
Obsoletes: php-pear
Obsoletes: php-pear-Auth-SASL
Obsoletes: php-pear-Mail-Mime
Obsoletes: php-pear-Mail-mimeDecode
Obsoletes: php-pear-Net-IDNA2
Obsoletes: php-pear-Net-SMTP
Obsoletes: php-pear-Net-Socket
Obsoletes: php-php-gettext
Obsoletes: php-snmp
Provides:  %{_bindir}/pear
Provides:  %{_bindir}/pecl
Provides:  %{_bindir}/perl
Provides:  php-pear
Provides:  php-pear-Auth-SASL
Provides:  php-pear-Mail-Mime
Provides:  php-pear-Mail-mimeDecode
Provides:  php-pear-Net-IDNA2
Provides:  php-pear-Net-SMTP
Provides:  php-pear-Net-Socket
Provides:  php-php-gettext
Provides:  %{_sbindir}/ldconfig

Obsoletes: mod_nss
Provides:  mod_nss
Obsoletes: mod_fcgid
Provides:  mod_fcgid

Requires:  attr
Requires:  authconfig
Requires:  bash-completion
Requires:  bzip2
Requires:  checksec
Requires:  chkrootkit
Requires:  dash
Requires:  diffutils
Requires:  dstat
Requires:  ethtool
Requires:  file
Requires:  grub2
Requires:  haveged
Requires:  hostname
Requires:  htop
Requires:  iftop
Requires:  iptables-services
Requires:  kbd
Requires:  less
Requires:  logwatch
Requires:  lsscsi
Requires:  lynis
Requires:  mlocate
Requires:  nano
Requires:  net-tools
Requires:  ntp
Requires:  openssh-clients
Requires:  openssh-server
Requires:  pciutils
Requires:  php-cli
Requires:  php-mysqlnd
Requires:  pigz
Requires:  postfix
Requires:  procmail
Requires:  procps-ng
Requires:  psmisc
Requires:  pyliblzma
Requires:  rkhunter
Requires:  rootfiles
Requires:  rpl
Requires:  rsync
Requires:  rsyslog
Requires:  rsyslog-mysql
Requires:  screen
Requires:  symlinks
Requires:  tar
Requires:  unhide
Requires:  vim-minimal
Requires:  vnstat
Requires:  xz
Requires:  yum-plugin-protectbase
Requires:  yum-plugin-tsflags
Requires:  yum-utils

%description
metapackage for thelounge.net default packages

%files

%changelog
* Tue Mar 27 2012 Reindl Harald 
- initial build
[builduser@buildserver:~]$


Am 04.02.2014 18:46, schrieb Kevin Wilson:
> Thanks to Adam and Daniel for the quick answer.
> 
> I am not an expert about RPMs. I just wonder where are these
> dependencies defined for libvirt (and in general for other RPMs),
> since the libvirt RPM file itself is an empty file ?
> 
> Regards,
> Kevin
> 
> 
> On Tue, Feb 4, 2014 at 7:37 PM, Adam Miller
>  wrote:
>>
>>
>>
>> On Tue, Feb 4, 2014 at 11:30 AM, Kevin Wilson  wrote:
>>>
>>> Hi,
>>> What is the usage of an empty RPM ? What it is for ?
>>> For example, on Fedora 20:
>>>
>>>  rpm -qpl  libvirt-1.1.3.3-2.fc20.x86_64.rpm
>>> shows:
>>> (contains no files)
>>
>>
>> It's effectively a meta-package that pulls in dependencies.
>>
>> # yum deplist libvirt
>> package: libvirt.x86_64 1.2.1-2.fc21
>>   dependency: /bin/sh
>>provider: bash.x86_64 4.2.45-6.fc21
>>   dependency: libvirt-client = 1.2.1-2.fc21
>>provider: libvirt-client.x86_64 1.2.1-2.fc21
>>provider: libvirt-client.i686 1.2.1-2.fc21
>>   dependency: libvirt-daemon = 1.2.1-2.fc21
>>provider: libvirt-daemon.x86_64 1.2.1-2.fc21
>>   dependency: libvirt-daemon-config-network = 1.2.1-2.fc21
>>provider: libvirt-daemon-config-network.x86_64 1.2.1-2.fc21
>>   dependency: libvirt-daemon-config-nwfilter = 1.2.1-2.fc21
>>provider: libvirt-daemon-config-nwfilter.x86_64 1.2.1-2.fc21
>>   dependency: libvirt-daemon-driver-interface = 1.2.1-2.fc21
>>provider: libvirt-daemon-driver-interface.x86_64 1.2.1-2.fc21
>>   dependency: libvirt-daemon-driver-libxl = 1.2.1-2.fc21
>>provider: libvirt-daemon-driver-libxl.x86_64 1.2.1-2.fc21
>>   dependency: libvirt-daemon-driver-lxc = 1.2.1-2.fc21
>>provider: libvirt-daemon-driver-lxc.x86_64 1.2.1-2.fc21
>>   dependency: libvirt-daemon-driver-network = 1.2.1-2.fc21
>>provider: libvirt-daemon-driver-network.x86_64 1.2.1-2.fc21
>>   dependency: libvirt-daemon-driver-nodedev = 1.2.1-2.fc21
>>provider: libvirt-daemon-driver-nodedev.x86_64 1.2.1-2.fc21
>>   dependency: libvirt-daemon-driver-nwfilter = 1.2.1-2.fc21
>>provider: libvirt-daemon-driver-nwfilter.x86_64 1.2.1-2.fc21
>>   dependency: libvirt-daemon-driver-qemu = 1.2.1-2.fc21
>>provider: libvirt-daemon-driver-qemu.x86_64 1.2.1-

Re: Fedora.NEXT Products and the fate of Spins

[Reindl Harald]

Am 04.02.2014 11:57, schrieb Jóhann B. Guðmundsson:
> On 02/04/2014 10:39 AM, Matthew Miller wrote:
>> On Thu, Jan 30, 2014 at 12:16:16PM -0800, Adam Williamson wrote:
>>> If we decide the alternative desktops are a valuable part of Fedora -
>>> which seems to be a popular opinion - how do we fit them into a
>>> Product-based conception of Fedora?
>>>
>>> We can have a KDE Product, and an Xfce Product, and an LXDE Product,
>>> but...at that point haven't we just re-invented spins? It doesn't seem
>>> to quite work with the Product conception.
>> I would like to see Products defined by the problem space that they are
>> aimed at rather than the technology they're based on. That is, a "Fedora
>> Scientific Desktop" is a lot more compelling to me than "Fedora KDE" -- at
>> least as a product. But I don't think there's anything wrong with Fedora KDE
>> as either a spin or something else.
>>
>> For that matter, there could be a "Fedora GNOME" spin distinct from the
>> Fedora Workstation product, if there were people really keen to work on it,
>> perhap as a showcase of upstream technology without worrying about the
>> concerns of the Fedora Workstation WG's particular area of focus. (With
>> "people keen to work on it" as the really key phrase.)
> 
> But you cannot overlap products as in you cannot have a "Gnome workstation 
> and "KDE workstation" etc you cannot
> have an "Server" product outside what is already defined in the ServerWG nor 
> a "Cloud" product outside what is
> already defined there.
> 
> Basically what's happening here is that "default" is being applied to now 
> three spaces which filled with Red Hat
> products and elevated above community contribution just like Gnome was put 
> above all community contributions as an
> "Default".
> 
> Do people truly really want us to move forward with this discrimination 
> between contributions to the project?

honestly going back to only a install DVD with a sane user-UI and dedicate all
the time wasted for the spin/products/discrimination discussions for 
documentations,
screenshots and howtos would have more benefit for Fedora

there is nothing you can't setup with the "one fits all" DVD or even with
a slim network install if you only knew what to install and how to configure



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: Fedora.NEXT Products and the fate of Spins

[Reindl Harald]

Am 30.01.2014 21:23, schrieb Richard Hughes:
> On 30 January 2014 20:19, Reindl Harald  wrote:
>> fact is that Redhat
> 
> Pet peeve of mine: Please call Red Hat by it's proper name, or people
> will start calling you Reindlharald

besides that you know what i meant with my post and that language
as written has finally the goal to understand what someone liked
to express with his words - it would be enough not calling me with
my last name as it often happens :-) Harald would be enough and
in the case of "Reindl" please "Mr. Reindl" :-)

there where i grown up my father, his grandfather and the neigbours
of his grandfather where called and written 

well, i say it again with the grammar you like
_

fact is that Red Hat has not endless budget and ressources
so if you have ressources for a limited work you have to
make decisions, frankly that is even the same with no look
at money 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: Fedora.NEXT Products and the fate of Spins

[Reindl Harald]

Am 30.01.2014 15:22, schrieb Jóhann B. Guðmundsson:
> On 01/30/2014 02:02 PM, Frank Murphy wrote:
>> On Thu, 30 Jan 2014 14:59:44 +0100
>> Johannes Lips  wrote:
>>
>>> Well, but it's not only about money and a lot of contributors use
>>> their spare time to contribute, so I wouldn't stress this money thing
>>> too much.
>>>
>> I didn't introduce the money angle,
>> just putting into Common language,
>> what has been inferred.
> 
> One would think that Red Hat's community sponsorship is not a “venture 
> capital” or "Investment" sponsorship but
> that it is a community sponsorship as it so clearly states everywhere but 
> apparently Red Hat looks at it that way
> that it "owns" the community

think about you are the only on that list saing that

fact is that Redhat has not endless budget and ressources
so if you have ressources for a limited work you have to
make decisions, frankly that is even the same with no look
at money 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]

[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

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]

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

[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

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

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

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

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

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

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

[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

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

[Reindl Harald]

Am 26.01.2014 01:54, schrieb Chris Murphy:
> 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

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   




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 01:28, schrieb Chris Murphy:
>> 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.
>
> But important user data having it's format updated in a way that makes it 
> incompatible
> with the previous minor version (same major version)? I'm snickering at the 
> language that 
> would ensue in the proprietary software world

you do not know what happens in case *of a bug*
you are in the area of undefined behavior

the point is that the snapshot *does not* bring you for
sure back where you came from or if it does you may regret
it because there is a timewindow between 3 steps

* snapshot / update
* continue your normal operations
* recognize there is a problem
* restore the snapshot
_

* if i have /var on a seperate partition *god beware* of the idea
  rollback a snapshot of the remaining rootfs because the system
  is ruined -> /var contains the whole rpm-database

* if i have /home on the same FS as the rootfs -> *god beware* of restore
  a snapshot because all work before "recognize there is a problem" is
  ruined
_

well, people already statet the solution maybe split the OS granulary
and extend the FHS -> that will *not* solve the problem, it only will
create new ones beause at the end of the day nobody except very few
people know what is hwre stored, snapshotted and can be restored with
what exactly impact leading to lose any control

a bug is a bug and in case of undefined bahvior the word *undefined*
is the really important - frankly, what happens if one of the components
used for snapshots is affected?

* nothing
* undefined system state
* all get trashed

solving problems by add more layers of complexity leads to have more
layers prone for bugs themself and the IT after 2010 tends to solve
that by wrap another layer around. frustrating.

Linux would not exist if Unix would not have made it a different way and
people coming up with technical complex solutions should consider how
it can be that 30 or 40 years old solutions still working perfect and
all the new ones are replaced every 2-5 years



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 25.01.2014 23:26, schrieb Tomasz Torcz:
> On Sat, Jan 25, 2014 at 02:55:32PM -0500, Simo Sorce wrote:
>> The ONLY way to do that is if you do not care at all about user's data
>> and simply accept that a rollback will also remove user data.
>>
>> The reason is simple: lot's of software *changes* data as part of its
>> normal functioning, including and often in rollback-incompatible ways.
> 
> What user data?  There is no user data touched/created during offline upgrade

and what is with the data *between* the upgrade and decision to roll back?



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: general compliment for F19/F20

[Reindl Harald]

Am 25.01.2014 23:01, schrieb Haïkel Guémar:
> I'm also dogfooding Fedora for almost a decade and i always had 
> updates-testing enabled since it exists.
> There were times when Fedora was very aggressive on updates and it had an 
> impact (a positive one overall, i hope)
> 
> There are two poles in our community: one wishing a more bleeding approach, 
> the other emphasizes on stability.
> We can't please everyone, but having different products over a common base 
> might concile these two sides

totally agreed

i like the bleeding approach, otherwise i would not use Fedora
on currently 35 machines, 10 of them *real* production starting
with FC9 in 2008, the rest my personal desktops and testing
VM's around me

> We can't please everyone

there is something between - offer things as *optional* replacement instead
replace working ones simply too early - why - because with the amount of
machines people like me own i can decide where i can take responibility to
test the replacement and where better not (if i only have the choice)

even in the category "production machines" i can draw a line and say
"ok, that one can also play testser for this and that because this
piece can't likely break down operations from users point of view"

and *that* was the reason for my DNF post - *currently* it feels
not to satisfy any of my environments while i *really* like to
help testing


Jan 25 21:58:18 Updated: elfutils-libelf-0.158-1.fc20.x86_64
Jan 25 21:58:19 Updated: elfutils-libs-0.158-1.fc20.x86_64
Jan 25 21:58:19 Updated: elfutils-0.158-1.fc20.x86_64

most likely not even in updates-testing now


well that packages built from source and tomorrow ready for give karma
if they all do not break verry likely fine to be pushed

Jan 25 22:31:34 Updated: apr-1.5.0-4.fc20.20140125.rh.x86_64
Jan 25 22:31:34 Updated: apr-devel-1.5.0-4.fc20.20140125.rh.x86_64
Jan 25 22:32:55 Updated: httpd-2.4.7-4.fc20.20140125.rh.x86_64
Jan 25 22:32:55 Updated: httpd-devel-2.4.7-4.fc20.20140125.rh.x86_64
Jan 25 22:32:55 Updated: 1:mod_ssl-2.4.7-4.fc20.20140125.rh.x86_64
Jan 25 22:32:55 Updated: httpd-tools-2.4.7-4.fc20.20140125.rh.x86_64
Jan 25 22:35:33 Updated: php-common-5.5.8-5.fc20.20140125.rh.x86_64
Jan 25 22:35:33 Updated: php-cli-5.5.8-5.fc20.20140125.rh.x86_64
Jan 25 22:35:33 Updated: php-pdo-5.5.8-5.fc20.20140125.rh.x86_64
Jan 25 22:35:33 Updated: php-mysqlnd-5.5.8-5.fc20.20140125.rh.x86_64
Jan 25 22:35:33 Updated: php-5.5.8-5.fc20.20140125.rh.x86_64
Jan 25 22:35:33 Updated: php-devel-5.5.8-5.fc20.20140125.rh.x86_64
Jan 25 22:35:34 Updated: php-bcmath-5.5.8-5.fc20.20140125.rh.x86_64
Jan 25 22:35:34 Updated: php-xmlrpc-5.5.8-5.fc20.20140125.rh.x86_64
Jan 25 22:35:34 Updated: php-xml-5.5.8-5.fc20.20140125.rh.x86_64
Jan 25 22:35:34 Updated: php-opcache-5.5.8-5.fc20.20140125.rh.x86_64
Jan 25 22:35:34 Updated: php-mcrypt-5.5.8-5.fc20.20140125.rh.x86_64
Jan 25 22:35:34 Updated: php-tidy-5.5.8-5.fc20.20140125.rh.x86_64
Jan 25 22:35:34 Updated: php-mbstring-5.5.8-5.fc20.20140125.rh.x86_64
Jan 25 22:35:34 Updated: php-imap-5.5.8-5.fc20.20140125.rh.x86_64
Jan 25 22:35:34 Updated: php-gd-5.5.8-5.fc20.20140125.rh.x86_64
Jan 25 22:35:34 Updated: php-soap-5.5.8-5.fc20.20140125.rh.x86_64
Jan 25 22:36:11 Updated: 6:php-pecl-mailparse-2.1.6-3.fc20.20140125.rh.x86_64
Jan 25 22:36:11 Updated: 6:php-pecl-ssh2-0.12-3.fc20.20140125.rh.x86_64
Jan 25 22:36:11 Updated: 6:php-pecl-mysqlnd_qc-1.2.0-3.fc20.20140125.rh.x86_64
Jan 25 22:36:11 Updated: 6:php-pecl-xdebug-2.2.3-3.fc20.20140125.rh.x86_64
Jan 25 22:36:11 Updated: 7:php-pecl-imagick-3.1.2-4.fc20.20140125.rh.x86_64
Jan 25 22:36:11 Updated: 
6:php-pecl-uploadprogress-1.0.3.1-3.fc20.20140125.rh.x86_64
Jan 25 22:36:11 Updated: 6:php-pecl-geoip-1.0.8-3.fc20.20140125.rh.x86_64
Jan 25 22:51:47 Updated: libzdb-3.0-2.fc20.20140125.rh.x86_64
Jan 25 22:51:47 Updated: libevent-2.0.21-4.fc20.20140125.rh.x86_64
Jan 25 22:51:47 Updated: gmime-2.6.19-1.fc20.20140125.rh.x86_64
Jan 25 22:51:48 Updated: 2:postfix-2.11.0-3.fc20.20140125.rh.x86_64
Jan 25 22:51:48 Updated: dbmail-3.1.10-1.fc20.20140125.rh.3.1.10.x86_64
Jan 25 22:51:48 Updated: gmime-devel-2.6.19-1.fc20.20140125.rh.x86_64
Jan 25 22:51:48 Updated: libevent-devel-2.0.21-4.fc20.20140125.rh.x86_64
Jan 25 22:51:48 Updated: libzdb-devel-3.0-2.fc20.20140125.rh.x86_64
Jan 25 22:51:48 Updated: 1:dovecot-2.2.10-2.fc20.20140125.rh.x86_64



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: general compliment for F19/F20

[Reindl Harald]

Am 25.01.2014 22:34, schrieb Haïkel Guémar:
> Le 25/01/2014 22:22, Reindl Harald a écrit :
>>
>> "as you actively did this month" - where? 
> 
> As i'm not planning to go further, i'll answer this last one:
> The very first flame of the year here has been the "DNF vs yum" thread you 
> started
> which got us coverage from phoronix.

nothing was wrong with that thread except some people took
it as attack and some started joke posts while it was meant as
"now while there is really enough time please consider what
features are really needed and should not be dropped"

if my intention would have been a flamewar i would simply have
waited a year and come after that with a rude "how is it possible
that this replacement has it made in a stable release"

> For the rest, just review your posts and the following discussions over 
> january

i know my posts in january

they are far away from a flamewar

> I can't wait HyperKitty, so we get real feedbacks about discussions in our 
> mailing-lists,
> and maybe act to tone down the bickering in devel

yes and maybe you will be surprised about the results

while you are so often use the word "community" keep in mind
the people using it daily, have enabeld updates-testing and
often enough download packages from koji and try to give feedback
to sort out troubles and prevent get them in stable releases while
at the same time try to avoid breakage because they drive a
prodcutn infrastructure with Fedora n-1 are part of it



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: general compliment for F19/F20

[Reindl Harald]

Am 25.01.2014 22:05, schrieb Haïkel Guémar:
> Le 25/01/2014 21:38, Reindl Harald a écrit :
>> first:
>>
>> be sure after the style of replies like yours i will
>> hestitate try to make compilemts again in the public
>> because the aggresive way you react leads nowhere else
>> then flamewars
> 
> I'd rather have you stop starting or feeding flamewars as you actively did 
> this month than
> these kind of "compliments"

"as you actively did this month" - where?

>> wow - even if someone makes a compliment it is taken rude - impressive
>>
>> the difference shortly before a new RHEL release is that the timeframe
>> is *much* more important for the RH folks than some random release
>>
>> accept it or not - you can't change the facts - period
> 
> You implied (and still imply) that most of the work is done by RH, belittling 
> the
> volunteer contributors

*no i did not* you only read it like that

> Off course, Red Hat is an important stakeholder in Fedora, but they 
> acknowledge that they're not
> the ones driving the project it's the community

yes, but they pay people to dedicate their full time and if that people
are doing bug-triage and only bug-triage for relevant components they
find more than a person working at free time for Fedora can do

not to belittle anybody
simply the fact a day has only 24 hours

> That's why we dropped along the "Core/extras" distinctions, that's why the 
> effective technical leadership is
> handled by the Fesco (a true community body) and that's why we're still
> sponsored by Red Hat.
> 
> But let's say that it was a naive statement from you

no, you only took it as abuse because you wanted to do so

> Remember that Fesco actually delayed systemd inclusion by one release for 
> very same reason:
> "not to rush things".
> At that time, it worked perfectly fine and we could have included it.

one release too early, 100% for sure
systemd and oterh services working with it in F16 was somehow OK
the release state of F15 was completly unacceptable for anybody
outside the "my personal computer" area

> One funny thing is that without a community contributor (i mean JBG), the 
> transition to systemd
> would have been much longer. No needs to wear a Red Hat to have an impact in 
> Fedora.

again: my intention was *not* to belittle anybody

> So you wanted to compliment the community, why did you felt the need to end 
> it by an
> unrelated statement about systemd?

because it *has* serious regressions in F20 which are acceptable
on a desktop, otehrwise i would not have written a mail woth the
subject "general compliment for F19/F20"

but hey are a problem on a server
sorry that i am one of them driving a lot of servers with Fedora and care baout

> Do you honestly think that if we continued with upstart and crappy sysV init 
> scripts,
> we would have had less issues or less critical issues ?

where did i say that?

i only honestly know if MySQL and some other services would have been migrated
to systemd in the first release replace upstart i would not felt that often
tempted to throw all the IT out of the next windows and with F16 that things
where *mostly* fine while some services are still not converted or at least
where not a few months ago :-)



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

[Reindl Harald]

Am 25.01.2014 22:00, schrieb Kevin Kofler:
> But then the right solution is to disable karma automatism entirely, not to 
> set it to some ridiculously high value.
> 
> Those meaningless thresholds need to go away (and really, the whole concept 
> of Bodhi karma and the policies that depend on it)

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

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

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





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: general compliment for F19/F20

[Reindl Harald]

first:

be sure after the style of replies like yours i will
hestitate try to make compilemts again in the public
because the aggresive way you react leads nowhere else
then flamewars

Am 25.01.2014 21:26, schrieb Haïkel Guémar:
> Le 25/01/2014 20:40, Reindl Harald a écrit :
>> i think sometimes some nice words are worth
>>
>> F19/F20 so far are great releases with nearly zero regressions
>> possibly because RHEL7 is cooked based on F19/F20 and partyl Rawhide
> 
> No, all the merit is due to Fedora contributors and our efforts to improve 
> the quality of the overall distro.
> Fedora is *community-driven*, implying that RHEL7 may be one of the cause of 
> that success is rude to the
> contributors whether they are paid or not by Red Hat

wow - even if someone makes a compliment it is taken rude - impressive

the difference shortly before a new RHEL release is that the timeframe
is *much* more important for the RH folks than some random release

accept it or not - you can't change the facts - period

>> the only downside currently are some systemd mis-behaviors hopefully
>> resolved before F19 is EOL and F20 becomes mandatory on servers
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1023788
>> https://bugzilla.redhat.com/show_bug.cgi?id=1023820
>> https://bugzilla.redhat.com/show_bug.cgi?id=1010572
>>
>> i really appreciate the distribution and only wish some major
>> features in F15-F17 would not appear again from the viewpoint
>> of their user-impact by "be first for a too high price"
>
> "In cauda venenum"
> Please read Fedora mission statement:

i do not need to read it 100 times

> "The Fedora Project's mission is to *lead* the advancement of free and open 
> source software and content as a
> collaborative community." (emphasis is mine)

so what - lead does not mean "lead for every price at any moment of time"

> I'm proud that we did these disruptive changes, because if we didn't, they 
> might never have happened

you could be even more proud if they would have happened anyways
but not that disruptive

> Many Fedora contributors feel the same (and a consequent number disagree too).
> We're not doing to get the first place, just to bring and help mature the 
> changes we feel right: systemd is one of
> them. And what happened later proved us that we were right.

and systemd with the state of F16/F17 and more server packages converted to 
systemd-units
would not have been that disruptive - period - in general systemd is a great 
improvement
and honestly before F15 was released the description and goals where things i 
really loved
to see, but not in a hurry, not in that state



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

general compliment for F19/F20

[Reindl Harald]

i think sometimes some nice words are worth

F19/F20 so far are great releases with nearly zero regressions
possibly because RHEL7 is cooked based on F19/F20 and partyl Rawhide

the only downside currently are some systemd mis-behaviors hopefully
resolved before F19 is EOL and F20 becomes mandatory on servers

https://bugzilla.redhat.com/show_bug.cgi?id=1023788
https://bugzilla.redhat.com/show_bug.cgi?id=1023820
https://bugzilla.redhat.com/show_bug.cgi?id=1010572

i really appreciate the distribution and only wish some major
features in F15-F17 would not appear again from the viewpoint
of their user-impact by "be first for a too high price"



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

[Reindl Harald]

Am 25.01.2014 17:46, schrieb Tomasz Torcz:
> Note that this situation is perfectly handled by Offline Updates.
> After reboot, there aren't collateral changes to filesystem, only 
> upgrade-related
> ones. So if there's a need for revert, the previous state is clearly defined

says who?

UsrMove was as example forced with the excuse to support this as well
as /usr on a own partition beause one snapshot of the system


so and now imagine a common setup

* /boot
* /
* /var

have fun with restore your snapshot or / or /usr where you bomb the rootfs back
and the rpmdb is still like the restore never did happen




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

[Reindl Harald]

Am 25.01.2014 17:40, schrieb Tomasz Torcz:
> 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
> 
> Such upgrade in stable release need to be done carefuly with above-standard
> amount of testing. But I think it's the only viable way

my expierience with pulseaudio-upgrades is good

Rex Dieter had PA 4.0 in a un-official repo months before it arrived
in Fedora and there was no regression using that repo on current Fedora

what about a scratch-build announced on @devel and @users to get active testers?



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

[Reindl Harald]

Am 24.01.2014 23:46, schrieb Michael Schwendt:
> On Fri, 24 Jan 2014 15:35:24 -0700, Stephen John Smoogen wrote:
> 
>> Looking at the number of people who respond to the qa list at times.. I am
>> going to say there are probably 6-10 active testers during non-release
>> times. It comes and it goes, but that is about the number who seem active
>> at least on lists (and it seems to be that way going over archives for the
>> last couple of years.) So any policy would need to take into account of
>> that limitation.
> 
> Any ideas how to attract more testers?
> 
> How to make the updates-testing repo more sexy?

* i am running updates testing 365/24 over the last 3 years
* i am running "yum --enablerepo=updates-testing --security" in production
* i test this packages in "near production" (test-vm-mirrors)

the only ones i leave out are *real* server packages because i
build them in general at my own inlcuding major-updates Fedora
not see at all or the other direction (PHP 5.4 first time with F18)

> More lessons to learn

yes here: https://bugzilla.redhat.com/show_bug.cgi?id=1019251

Joe Orton 2013-11-18 07:15:12 EST
Upstream is gearing up for 2.4.7 RSN - ECC support will get
picked up automagically when we do a new f19 build

where is the 2.4.7 build for F19?

more than 3 months ago i had httpd-2.4.6 with ECDHE *in production* on F18
and so confirmed that httpd works fine as expected with the new openssl
https://bugzilla.redhat.com/show_bug.cgi?id=319901#c108



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

[Reindl Harald]

Am 24.01.2014 23:46, schrieb Michael Schwendt:
> On Fri, 24 Jan 2014 15:35:24 -0700, Stephen John Smoogen wrote:
> 
>> Looking at the number of people who respond to the qa list at times.. I am
>> going to say there are probably 6-10 active testers during non-release
>> times. It comes and it goes, but that is about the number who seem active
>> at least on lists (and it seems to be that way going over archives for the
>> last couple of years.) So any policy would need to take into account of
>> that limitation.
> 
> Any ideas how to attract more testers?
> 
> How to make the updates-testing repo more sexy?
> 
> More lessons to learn:
> 
> https://admin.fedoraproject.org/updates/FEDORA-2013-23627
>   Karma:  17
>   Stable karma:   16 (!)
> 
> It has reached the karma threshold 16 after ~5 days.
> And those have not been all testers

but where do you see a problem with that package?
hreindl - 2013-12-20 11:07:28
works for me

[root@srv-rhsoft:~]$ rpm -q yum
yum-3.4.3-132.fc20.noarch

Jan 22 12:48:00 Updated: yum-3.4.3-132.fc20.noarch


built explicitly to test the yum package:
Jan 22 12:52:25 Updated: 
lounge-rhsoft-workstation-20.0-2.fc20.20140122.rh.noarch

updates after that:
Jan 22 14:09:10 Updated: ffmpeg-latest-manpages-2.1.3-4.fc20.20140122.rh.noarch
Jan 22 14:09:11 Updated: ffmpeg-latest-2.1.3-4.fc20.20140122.rh.x86_64
Jan 22 14:28:03 Installed: iftop-1.0-0.7.pre4.fc20.x86_64
Jan 22 14:28:03 Updated: 
lounge-rhsoft-workstation-20.0-3.fc20.20140122.rh.noarch
Jan 23 11:29:10 Updated: apcupsd-3.14.10-14.fc20.x86_64
Jan 23 11:29:10 Updated: apcupsd-gui-3.14.10-14.fc20.x86_64
Jan 23 16:32:25 Updated: glibc-2.18-12.fc20.x86_64
Jan 23 16:32:30 Updated: glibc-common-2.18-12.fc20.x86_64
Jan 23 16:32:30 Updated: pulseaudio-libs-4.0-12.gitf81e3.fc20.x86_64
Jan 23 16:32:30 Updated: libtool-ltdl-2.4.2-23.fc20.x86_64
Jan 23 16:32:31 Updated: pulseaudio-4.0-12.gitf81e3.fc20.x86_64
Jan 23 16:32:31 Updated: pulseaudio-utils-4.0-12.gitf81e3.fc20.x86_64
Jan 23 16:32:32 Updated: glibc-headers-2.18-12.fc20.x86_64
Jan 23 16:32:33 Updated: glibc-devel-2.18-12.fc20.x86_64
Jan 23 16:32:33 Updated: pulseaudio-module-x11-4.0-12.gitf81e3.fc20.x86_64
Jan 23 16:32:33 Updated: pulseaudio-libs-glib2-4.0-12.gitf81e3.fc20.x86_64
Jan 23 16:38:22 Updated: 12:dhcp-libs-4.2.6-0.1.b1.fc20.x86_64
Jan 23 16:38:22 Updated: 12:dhcp-common-4.2.6-0.1.b1.fc20.x86_64
Jan 23 16:38:23 Updated: 12:dhcp-4.2.6-0.1.b1.fc20.x86_64
Jan 23 16:38:23 Updated: 12:dhclient-4.2.6-0.1.b1.fc20.x86_64
Jan 23 21:03:57 Updated: tzdata-java-2013i-2.fc20.noarch
Jan 23 21:03:57 Updated: crypto-utils-2.4.1-46.fc20.x86_64
Jan 23 21:03:58 Updated: krb5-libs-1.11.3-39.fc20.x86_64
Jan 23 21:03:59 Updated: 
google-crosextra-caladea-fonts-1.002-0.3.20130214.fc20.noarch
Jan 23 21:04:01 Updated: webkitgtk-2.2.4-1.fc20.x86_64
Jan 23 21:04:02 Updated: tzdata-2013i-2.fc20.noarch
Jan 24 17:41:58 Updated: fltk-1.3.2-3.fc20.x86_64
Jan 24 17:41:58 Updated: libnl3-3.2.24-1.fc20.x86_64
Jan 24 17:41:58 Updated: freeglut-2.8.1-3.fc20.x86_64
Jan 24 17:41:58 Updated: pango-1.36.1-2.fc20.x86_64



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

[Reindl Harald]

Am 24.01.2014 21:13, schrieb drago01:
> On Fri, Jan 24, 2014 at 7:35 PM, Reindl Harald  wrote:
>> Am 24.01.2014 19:31, schrieb Reindl Harald:
>>>
>>> Am 24.01.2014 19:18, schrieb drago01:
>>>> On Fri, Jan 24, 2014 at 7:12 PM, Fabian Deutsch  
>>>> wrote:
>>>>> Am Freitag, den 24.01.2014, 00:55 +0100 schrieb Kevin Kofler:
>>>>>> it is time to analyze the fallout from the following catastrophic
>>>>>> Fedora 20
>>>>>> regression:
>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1054350
>>>>>> "rpm scriptlets are exiting with status 127"
>>>>>
>>>>> Hey,
>>>>>
>>>>> can't we add a default boot entry which starts the system in permissive
>>>>> mode?
>>>>
>>>> How would that help? If a user knows enough about the issue to try it
>>>> he/she could just switch to permissive mode
>>>
>>> in *that* case
>>>
>>> in a case where a broken selinux update leads in not boot at all
>>> i can not imagine what i would to besides boot with a CD/DVD/USB
>>
>> to be clear - *i can* edit the boot-params and put selinux=0 there
>>
>> the average user can't but he may remember "uhm something with selinux
>> was one of the last updates"
> 
> You are assuming that the "averange user" even knows what selinux is
> or reviews the list of packages for every update.
> I doubt either of them is true.

as i said often:

linux systems tend also to get way too closed

many things are hidden in the assumption "the user do not want to be disturbed
with this and that information and install as well as boot needs to be pretty
and shiny"

* rhgb
* quiet
* hidden grub-menu

hence, while you install Fedora there should be a (default enabled) checkbox
asking if you want to enable SELinux with a short description what it is

>> and try the however named option, keep
>> in mind some people own only one machine and can't google for help
> 
> I doubt that. Most people do have multiple ways to access the internet
> (multiple computers, tablets, phones, game consoles ...) it is 2014
> not 1996

technically yes

practically how much fun does somebody have to google on a smart-phone
for a solution while he is frustrated and angry - and even if - do not
assume that all users are living in your social structure, that is not
really true

for me it is no problem, on the other hand there is a guy on the CentOS
list with the thread "died again" seeking for a hardware problem and
stating he has no money to chnage his 10 or so years old computer while
you and i would have thrown out that crap by the next window weeks ago



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

[Reindl Harald]

Am 24.01.2014 20:22, schrieb Daniel J Walsh:
> On 01/24/2014 01:35 PM, Reindl Harald wrote:
>> Am 24.01.2014 19:31, schrieb Reindl Harald:
>>>
>>> Am 24.01.2014 19:18, schrieb drago01:
>>>> On Fri, Jan 24, 2014 at 7:12 PM, Fabian Deutsch 
>>>> wrote:
>>>>> Am Freitag, den 24.01.2014, 00:55 +0100 schrieb Kevin Kofler:
>>>>>> it is time to analyze the fallout from the following catastrophic 
>>>>>> Fedora 20 regression: 
>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1054350 "rpm scriptlets
>>>>>> are exiting with status 127"
>>>>>
>>>>> Hey,
>>>>>
>>>>> can't we add a default boot entry which starts the system in
>>>>> permissive mode?
>>>>
>>>> How would that help? If a user knows enough about the issue to try it 
>>>> he/she could just switch to permissive mode
>>>
>>> in *that* case
>>>
>>> in a case where a broken selinux update leads in not boot at all i can
>>> not imagine what i would to besides boot with a CD/DVD/USB
> 
>> to be clear - *i can* edit the boot-params and put selinux=0 there
> 
>> the average user can't but he may remember "uhm something with selinux was
>> one of the last updates" and try the however named option, keep in mind
>> some people own only one machine and can't google for help
> 
> enforcing=0 in the kernel command line will boot the machine in permissive 
> mode

please re-read what you have quoted and don't skip "average user" this time

the question was "can't we add a default boot entry which starts the system in
permissive mode?" and the first reply "If a user knows enough about the issue"



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