Re: drop obsolete static uid/gid allocations
On Sun, Jan 15, 2017 at 12:13:16AM +, Zbigniew Jędrzejewski-Szmek wrote: > https://git.fedorahosted.org/cgit/setup.git/tree/uidgid has a list > of "soft static" uids and gids. > > Currently FPC has a process for allocating new numbers on this list, > but here's a number of static uid/gid allocations from old times, > which are not necessary. Dropping them will allow those numbers to be > used in the dynamic pool, reducing the risk of exhaustion of system > uids or gids. > > (A "soft static" allocation is only needed for two reasons [1]: > - the user is used in the initramfs AND files or processes are carried > over into the real system, > - the UID is used on shared between systems. > > All other packages should use "dynamic" allocation, i.e. create > the user/group in %pre and get any free number.) > > I thought I'd file a ticket against setup, but since there's a large > number of items on this list, I decided to ask here first. > Any objection to dropping (from the static list) any of the following? > > == No need for static allocation, afaict > games, man, slocate, squid, named, postgres, mysql, nscd, > rpcuser, rpc, rpm, ntp, mailman, gdm, utempter, apache, smmsp, > tomcat, frontpage, nut, beagleindex, avahi, tcpdmp, privoxy, radvd, > imap, majordomo, polkituser, screen, clamav, saned, mock, ricci, luci > > == The following are completely unused? > console, wnn, haldaemon, vcsa, realtime, nocpulse, desktop, jonas, > pvm, xfs I guess xfs is the X font server, we use a dynamic one since ages (and as we are now moving to Wayland...). See https://fedoraproject.org/wiki/Releases/FeatureNoMoreXFS nocpulse was likely linked to a company RH acquired a long time ago and whose product served as the basis to Satellite/spacewalk. On RHEL, it is dynamically created, (cf https://access.redhat.com/solutions/222323 ), and I think spacewalk is not packaged in Fedora. -- Michael Scherer ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Improvements of Fedora Sponsorship process
On Fri, Aug 05, 2016 at 09:32:28AM +0200, Miroslav Suchý wrote: > I had the talk [1] about Fedora Sponsorship process at Flock. And we > had very interesting follow-up discussion. So I kinda missed it, since for some reason, i tought this was about financial sponsorship. (Given that I forgot words in each title of my own talks, I can't really complain much) > c) Create wiki page with list of sponsors willing to accept new > sponsoree. And list area of expertise of sponsors (e.g. java, > python, IoT...). This will make for sponsoree easier to find right > sponsor. Because we have some sponsors, who are active but are not > willing to accept new sponsoree right now. I think that's a good idea, but wouldn't it risk getting out of date after some time ? Should someone be in charge of it ? > d) When sponsors is not active for 2 years [*] - that means not just > in sponsoring work, but there is no activity in BZ, koji, wiki and > any other Fedora service at all (guessed by reading log of fedmsg), > then his sponsor status is removed. We will assume that the sponsor > is gone for good. what happen to the existing sponsored packagers ? (ie, do they get reassigned to a new sponsor ?) -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [OT] Tim, Gil, et. al. (e-mail address settings)
On Fri, Jul 01, 2016 at 05:02:58PM -0500, Michael Catanzaro wrote: > On Fri, 2016-07-01 at 16:19 -0400, Dan Book wrote: > > Nobody is blocking you. But aside from this one instance I went > > digging > > through my spam folder, I do not see your messages, and I suspect > > many > > others do not either. Communication doesn't work if you can't reach > > the > > audience, quite literally in this case. But if you don't care, then > > that's > > all. > > -Grinnz > > I checked my spam folder. All of gil's mails have been going there. > There is this helpful message: > > "Why is this message in Spam? It has a from address in libero.it but > has failed libero.it's required tests for authentication." > > There is documentation for this: > > https://support.google.com/mail/answer/1366858 > > which points to: > > https://dmarc.org/overview/ > > I don't understand email, but I suspect gil's problem has something to > do with that. So that's rather fast to explain. Libero.it use this SPF record: $ host -t TXT libero.it libero.it descriptive text "v=spf1 ip4:212.48.25.128/25 ip4:212.48.14.160/27 include:srs.bis.na.blackberry.com include:srs.bis.eu.blackberry.com include:srs.bis.ap.blackberry.com include:mail.zendesk.com -all" basically, if the mail do not come from zendesk or blackberry servers, or from the ranges 212.48.25.128/25 or 212.48.14.160/27, the provider (libero.it) say this is a fake mail and a spam (the -all). A quick look at the headers of mail send by Gil show that indeed, the mail do not come from any of the servers authorized to send mail on behalf of libero.it. Ergo, Gmail tag that as spam, because Libero.it say to do so in explicit and standard respecting way. So either libero.it change the SPF record, or Gil start to to use libero.it SMTP, or use a different email in the 'from' header. We can't really ask to all providers (ie, more than gmail) who use SPF to not listen to libero.it constraints, for obvious reasons (like "libero.it is fully authorized to do what they see fit with their domain" being the first one). -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Improving the offline updates user experience
On Wed, Oct 22, 2014 at 11:35:00PM +0100, Ian Malone wrote: On 22 October 2014 20:07, Michael Stahl mst...@redhat.com wrote: On 17.09.2014 13:58, Miroslav Suchý wrote: On 09/17/2014 11:54 AM, Bastien Nocera wrote: All those OSes require reboots when updating the OS. Define OS. Firefox is definitely not OS. While systemd is OS. I am fine with reboot after systemd upgrade, but not after upgrading Firefox. the important point in that case is not reboot after upgrading Firefox but *before* upgrading Firefox, which means that at the time of the upgrade no Firefox will be running and potentially crashing because one of the 100s of DSOs it loads on-demand has changed in an incompatible way. there used to be quite a few ABRT crashes reported against desktop applications with impossible looking stack traces (although with the automatic micro-reports it's less of a problem nowadays as they are easier to ignore), and sometimes the reporter gives feedback that the application was running across a yum update... While it can be a bit confusing the first time it happens to you, the solution is just to start and stop firefox again in that case. If it the goal is just to tidy ABRT crash reports (and I'm not sure it is) then forcing reboots on users wouldn't be very kind. Beyond cleaning crash reports and reducing them, there is also the perception of users. If we want to have the same reputation as some older windows with this software crashed and I do not know why from our users, then having regular random crashes after a random delay after upgrade is the way to go. If we still aim for the software is solid and stable, then we should try to reduce the random crash. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Replace Yum With DNF
Le samedi 14 juin 2014 à 04:00 +0200, Reindl Harald a écrit : Am 14.06.2014 03:42, schrieb Michael Scherer: Le samedi 14 juin 2014 à 03:33 +0200, Reindl Harald a écrit : So maybe you should propose to have dnf named yum 4.0, and then since that's a major version, we would be ok to change the behavior, command lines switch, configuration and backend in a backward incompatible way? yes so, just to be clear, that's ok to change the behavior, command lines switch, configuratio and backend in backward _incompatible_ for yum 4.0 aka dnf, for you ? it is *NEVER* ok to break user interfaces without a damned good reason there is no single reason to break command line switches at all So why do you say yes at the proposal that should be ok to break command line switch if you mean no ? So you are in favor of keeping the current behavior as is for how long ? ( because it sound like forever for you ) Or even with the name yum and a clear indication, that's something that shouldn't be changed, in which case, yum 3 behavior should be kept, which mean keeping all the code and behavior until later ? jesus christ the code behind has *nothing* to do with the userinterface and options - i have rewritten code of software i maintain for a decade now multiple times and in the meantime there is for sure not a single line the same as started 2003 without break user expectations In the case of dnf, the plugin api did changed. And I doubt people want to bring back the old one. So the user expectation around specific plugin is already broken. no - only if you want it that way as developer Well, yes, because that's the developer that has to make the effort. It is easy to say do that and going back to your business. In the end, those who work decide. And so far, I do not see patches coming from you. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Replace Yum With DNF
Le samedi 14 juin 2014 à 03:55 +0200, Reindl Harald a écrit : Am 14.06.2014 03:36, schrieb Michael Scherer: Everybody I know who looked at the yum python api told me it was a bit horrible. So a cleanup was needed for that. There was demand from packagekit developers to have a cleaner API as well, and I would hope that tools like puppet/ansible would benefit as well. And since that's python, you also have the need to be python 3 compatible, which is a rather big task, as seen by the slow migration of the rest of the platform. The less code you have to port, the less time it take (same goes for testing, documenting, translating) the internal API is between developers the options and CLI params are for users different worlds This divide is meaningless, since what affect developers affect non developers ( as code that is not ported will no longer work, even for API change ), and as people keep speaking of scripts on yum. The command line switches are part of the API for software like puppet, ansible. if someone takes the word improve in his mouth i don't see a place for remove in the same context the dirty codebase grown that way because previously unplanned features where included and it it pretty silly to cleanup things by step back from where it came which leads a few years later to the same problems: options left and right are included in a codebase originally not designed for it that's fine for developers because that way you can start every few years from scratch with remove, re-write and cleanup but it hardly gains anything for the users In fact, since developers can fix bug more easily with a code that is clean, it benefits to users as well. you ignore the bugs of missing functions which will be the first so you postponed the work only That's why the developers do ask what is missing. That's also why I ask for you what compatibility you exactly want, and you keep avoiding giving a clear answer. a smart re-write is using the benefit knowing what all sort of options, functions and configurations where added all the time before and organize the codebase to implement it in a better, more generic way with sane (API) interfaces Perfect, so are you leading the way, or do you continue to tell to people how to make a smart rewrite without being more specific and without putting any efforts? my effort is try to prevent thousands of bugreports Thousands ? I think you are exaggerating. Hyperbolic statements do not help. did you realize that in this thread it was even suggested to completly remove the yum command over the long even if it is only a symlink? Yes. And I would be in favor personally, so that let developers free to change the interface and anything if they see fit without having to keep old code for the old interface. People who want the old yum can keep it alive, the others can use the dnf name. throwing all away, start with a minimum and be proud it's faster and cleaner is only a short term solution You still didn't answer to the question I asked. How long do you want compatibility be kept, and what compatibility exactly ? [snip of yum help] That's neither the answer to : - how long - what -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Replace Yum With DNF
Le samedi 14 juin 2014 à 13:45 +0100, Jon Kent a écrit : Concerns me greatly when someone thinks cli is the wrong way to automate things. Agree Reindl comment 're this statement. CLI is not scalable, you need to fork processes for that. There is also no way to communicate errors to the software that do the automation, since you can only transmit string without any formatting or translation. You are also mixing something mean for a user and something meant for a software. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Replace Yum With DNF
Le samedi 14 juin 2014 à 12:55 +0200, Reindl Harald a écrit : Am 14.06.2014 12:26, schrieb Michael Scherer: Le samedi 14 juin 2014 à 04:00 +0200, Reindl Harald a écrit : Am 14.06.2014 03:42, schrieb Michael Scherer: Le samedi 14 juin 2014 à 03:33 +0200, Reindl Harald a écrit : So maybe you should propose to have dnf named yum 4.0, and then since that's a major version, we would be ok to change the behavior, command lines switch, configuration and backend in a backward incompatible way? yes so, just to be clear, that's ok to change the behavior, command lines switch, configuratio and backend in backward _incompatible_ for yum 4.0 aka dnf, for you ? it is *NEVER* ok to break user interfaces without a damned good reason there is no single reason to break command line switches at all So why do you say yes at the proposal that should be ok to break command line switch if you mean no ? to show you how weird your come on let us break compatibility is So you are in favor of keeping the current behavior as is for how long ? (because it sound like forever for you) yes forever to say it clear if it ain't broken don't fix it Well, yes, because that's the developer that has to make the effort. It is easy to say do that and going back to your business. In the end, those who work decide. And so far, I do not see patches coming from you i am fine with YUM for many years as others are too there was and is no valid reason to break CLI interfaces That's why the developers do ask what is missing. That's also why I ask for you what compatibility you exactly want, and you keep avoiding giving a clear answer *full* compatibility - is that so hard to understand and why? So basically, you want full compatibility forever. Then I guess you cannot say that nobody ask for that, since you just did. https://lists.fedoraproject.org/pipermail/devel/2014-June/11.html Yet, I still do not see you offering any help to achieve that, only you requiring it. Yes. And I would be in favor personally, so that let developers free to change the interface and anything if they see fit without having to keep old code for the old interface. why do you need to keep old code for compatible CLI interfaces? Because that's the easiest way, especially for plugins. Otherwise, any changes could result in unrelated side effects and regressions, and the more options you provides, the more stuff there is to break. And the QA cost of full compatibility is rather high, especially for python where there isn't much isolation or interface for the code ( ie, you can directly go to the internal structures, kinda like DOS years ago ). -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Replace Yum With DNF
Le samedi 14 juin 2014 à 15:08 +0200, Reindl Harald a écrit : Am 14.06.2014 14:56, schrieb Michael Scherer: Le samedi 14 juin 2014 à 13:45 +0100, Jon Kent a écrit : Concerns me greatly when someone thinks cli is the wrong way to automate things. Agree Reindl comment 're this statement. CLI is not scalable, you need to fork processes for that. There is also no way to communicate errors to the software that do the automation, since you can only transmit string without any formatting or translation. oh my god - CLI is used for decades and now as machines are some hundret times faster in IO and CPU performance it's not scalable.. Performant different from scalable. And you didn't address the problem of not having proper error communication, and I can add the lack of format API and mechanism to signal deprecation to issue of CLI as a automation mechanism. You can also add the fact that all CLI calls are synchronous ( since shell lack advanced synchronisation primitives ), which is also something going against modern scalability ( and by scalability, I do not mean 20 machines like you seems to do ) The fact we use command line tools in %post in rpm rather than clearly defined API to affect the system is one of the reason why rollback is hard to automate. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Replace Yum With DNF
Le samedi 14 juin 2014 à 15:15 +0200, Reindl Harald a écrit : Am 14.06.2014 15:04, schrieb Michael Scherer: Le samedi 14 juin 2014 à 12:55 +0200, Reindl Harald a écrit : That's why the developers do ask what is missing. That's also why I ask for you what compatibility you exactly want, and you keep avoiding giving a clear answer *full* compatibility - is that so hard to understand and why? So basically, you want full compatibility forever. Then I guess you cannot say that nobody ask for that, since you just did. https://lists.fedoraproject.org/pipermail/devel/2014-June/11.html stop that trolling to maintain yum in the long term is a completly different thing than keep *full compatibility* - compatibility is independet from the YUM code itself Given there is no specification of what you mean by full compatibility, the compatibility is the current behaviour in every details, and the current behaviour is therefore linked to the current code. Now, if someone do say here is what we consider to be compatible ( something that you have been asked 3 times and yet didn't provide, not even tried to provides ), then the compatibility would be separate from the code. But as long as full compatibility is what yum does now, the 2 are linked by definition. But again, can you give a more precise definition of the behaviour that should be kept without having to refer to yum code ? You do not even say what version of the yum code should be used as reference. Yet, I still do not see you offering any help to achieve that, only you requiring it. as you do not offering to do the work of re-view and adopt any existing script and howto out there I did intend to work on ansible to have it using dnf API, as that's a codebase I know quite well. Yes. And I would be in favor personally, so that let developers free to change the interface and anything if they see fit without having to keep old code for the old interface. why do you need to keep old code for compatible CLI interfaces? Because that's the easiest way, especially for plugins. interesting - guess what: the *easiest way* would have been not rewrite YUM at all - do it anyways but than say but for all other things which don't match the cherry picking it's easier not do to so is hypocrisy So basically, that exactly what I said. It is is easier to keep the old code than to ask to keep compatibility in the new one, especially since compatibility is not specified at all. So if your goal is 100% compatibility over all, then indeed, not changing anything is the simplest way. Now, if you want to see some changes, then you are ok to have something change, so the goal is no longer 100%. So you have to explain what are the 90% that shouldn't changes at all, and what are the 10% that you are ok to see changes. Otherwise, any changes could result in unrelated side effects and regressions, and the more options you provides, the more stuff there is to break. And the QA cost of full compatibility is rather high, especially for python where there isn't much isolation or interface for the code ( ie, you can directly go to the internal structures, kinda like DOS years ago ) you understand that any compatibility break is a side effect for the user? Yes, I do. That doesn't mean that I care however. I am personally ok with having some breakages if the developers think this is the better choice given time, contraints and all real life issues, as I trust them to have thought about it. And I do not care also because I am fully able to adapt, that's part of my job as sysadmin. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Replace Yum With DNF
Le vendredi 13 juin 2014 à 10:39 -0400, Steve Clark a écrit : On 06/13/2014 09:03 AM, drago01 wrote: On Fri, Jun 13, 2014 at 2:58 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 13.06.2014 14:53, schrieb Jan Zelený: That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is. the user expects that anyways if you replace something he did not asked for replace it and what just worked for him Well there are different levels of works i.e just because something works that something does not have to be the best possible implementation of something ... Horses worked too but at some point we decided that cars work better and moved on. Yes but who is this better for? A few developers or the mass of people and documentation that are used to using yum. With cars it was obviously better for me - dnf not so obvious. So far in this thread, I see no one stepping to maintain yum in the long term, just people asking to others to do it. But having someone volunteering to maintain it would be the solution. People who want to keep yum forever, just maintain it. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Replace Yum With DNF
Le vendredi 13 juin 2014 à 15:07 +0200, Petr Spacek a écrit : On 13.6.2014 14:58, Reindl Harald wrote: Am 13.06.2014 14:53, schrieb Jan Zelený: That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is. the user expects that anyways if you replace something he did not asked for replace it and what just worked for him why do so many developers not understand that simple fact? I don't think that simple fact that DNF is re-write of YUM justifies re-naming and re-training all users. Users don't care what you do with the source. And of course, users will complain no matter what you do. Like they complained when up2date was replaced by yum ? when zipper replaced whatever they used to have on *suse before ? When pkgin replaced pkg_add on some of the BSD ? It happened in the past, and I do not remember seeing so much complains.. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Replace Yum With DNF
Le samedi 14 juin 2014 à 03:03 +0200, Reindl Harald a écrit : Am 14.06.2014 02:59, schrieb Michael Scherer: Le vendredi 13 juin 2014 à 10:39 -0400, Steve Clark a écrit : On 06/13/2014 09:03 AM, drago01 wrote: On Fri, Jun 13, 2014 at 2:58 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 13.06.2014 14:53, schrieb Jan Zelený: That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is. the user expects that anyways if you replace something he did not asked for replace it and what just worked for him Well there are different levels of works i.e just because something works that something does not have to be the best possible implementation of something ... Horses worked too but at some point we decided that cars work better and moved on. Yes but who is this better for? A few developers or the mass of people and documentation that are used to using yum. With cars it was obviously better for me - dnf not so obvious. So far in this thread, I see no one stepping to maintain yum in the long term, just people asking to others to do it. But having someone volunteering to maintain it would be the solution. People who want to keep yum forever, just maintain it what are you talking about? *nobody* asked that *nobody* Nobody did ask that explicitly. But if people want to keep all howto running, either we keep yum as is, or we define what exactly should be preserved and what can be removed. If you tell me nothing should be removed forever, then you ask to keep yum forever. If not, then tell what can be removed and when, and others do the same. the point is *not* break YUM as name and in documentations as well as thousands of howtos, articles and books you can't re-write and gain the missing pieces of compatibility So ok, let the yum name being used by yum code, cause you want to keep how to running ( ie, that mean understand all options and everything like command line ), and that's it. DNS is DNF, and yum is what you have now, since any option change would result into broken howtos. Again, tell what can be removed and/or changed. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Replace Yum With DNF
Le samedi 14 juin 2014 à 03:10 +0200, Reindl Harald a écrit : Am 14.06.2014 03:04, schrieb Michael Scherer: Le vendredi 13 juin 2014 à 15:07 +0200, Petr Spacek a écrit : On 13.6.2014 14:58, Reindl Harald wrote: Am 13.06.2014 14:53, schrieb Jan Zelený: That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is. the user expects that anyways if you replace something he did not asked for replace it and what just worked for him why do so many developers not understand that simple fact? I don't think that simple fact that DNF is re-write of YUM justifies re-naming and re-training all users. Users don't care what you do with the source. And of course, users will complain no matter what you do. Like they complained when up2date was replaced by yum ? when zipper replaced whatever they used to have on *suse before ? When pkgin replaced pkg_add on some of the BSD ? It happened in the past, and I do not remember seeing so much complains.. maybe people just have enough of repeated iterations every few months breaking compatibility left and right while it would have been possible to replace/improve things without breakage You may not realize, but having someone who do not do your job telling you how to do it is perceived as pretty annoying for a lot of people. as said repeatly in that thread: go ahead and propose to rename GNOME3 because it is no longer GNOME Gnome is not a single software, it is a brand, and a collection of software. Keeping the brand is likely the reason why it was not renamed. But the part that did change visually, ie the windows manager and the shell among others got renamed from whatever it was named to gnome-shell. Same goes for rhytmbox, afaik. go ahead and propose to rename Linux because 3.15 is no longer Linux 1.0 I fail to see how comparing changes in more than 15 years is relevant to the current discussion. Nor even how anecdotal point of data is relevant. and that changes where much bigger than a fork of YUM renamed for no good reason especially in context of replace it it was renamed to provides side by side installation among others. I am sure that people would have been more upset if it was not done this way. ( as seen by the migration to gnome 3/kde 4 and people complaining exactly on that ). So maybe you should propose to have dnf named yum 4.0, and then since that's a major version, we would be ok to change the behavior, command lines switch, configuration and backend in a backward incompatible way ? Or even with the name yum and a clear indication, that's something that shouldn't be changed, in which case, yum 3 behavior should be kept, which mean keeping all the code and behavior until later ? -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Replace Yum With DNF
Le samedi 14 juin 2014 à 03:20 +0200, Reindl Harald a écrit : Am 14.06.2014 03:10, schrieb Michael Scherer: Le samedi 14 juin 2014 à 03:03 +0200, Reindl Harald a écrit : Am 14.06.2014 02:59, schrieb Michael Scherer: Le vendredi 13 juin 2014 à 10:39 -0400, Steve Clark a écrit : On 06/13/2014 09:03 AM, drago01 wrote: On Fri, Jun 13, 2014 at 2:58 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 13.06.2014 14:53, schrieb Jan Zelený: That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is. the user expects that anyways if you replace something he did not asked for replace it and what just worked for him Well there are different levels of works i.e just because something works that something does not have to be the best possible implementation of something ... Horses worked too but at some point we decided that cars work better and moved on. Yes but who is this better for? A few developers or the mass of people and documentation that are used to using yum. With cars it was obviously better for me - dnf not so obvious. So far in this thread, I see no one stepping to maintain yum in the long term, just people asking to others to do it. But having someone volunteering to maintain it would be the solution. People who want to keep yum forever, just maintain it what are you talking about? *nobody* asked that *nobody* Nobody did ask that explicitly. But if people want to keep all howto running, either we keep yum as is, or we define what exactly should be preserved and what can be removed why do functions and options need to be removed due a code-rewrite/re-factoring? to clean up the code base? likely yes. Also because the more code you have, the more corner case you can face, the more time you spend on testing, reimplementing, etc, etc. the dnf developers did a very good job engaging the users to know what matter to them, to integrate likely better or more flexible solution, etc. Everybody I know who looked at the yum python api told me it was a bit horrible. So a cleanup was needed for that. There was demand from packagekit developers to have a cleaner API as well, and I would hope that tools like puppet/ansible would benefit as well. And since that's python, you also have the need to be python 3 compatible, which is a rather big task, as seen by the slow migration of the rest of the platform. The less code you have to port, the less time it take (same goes for testing, documenting, translating) if someone takes the word improve in his mouth i don't see a place for remove in the same context the dirty codebase grown that way because previously unplanned features where included and it it pretty silly to cleanup things by step back from where it came which leads a few years later to the same problems: options left and right are included in a codebase originally not designed for it that's fine for developers because that way you can start every few years from scratch with remove, re-write and cleanup but it hardly gains anything for the users In fact, since developers can fix bug more easily with a code that is clean, it benefits to users as well. a smart re-write is using the benefit knowing what all sort of options, functions and configurations where added all the time before and organize the codebase to implement it in a better, more generic way with sane (API) interfaces Perfect, so are you leading the way, or do you continue to tell to people how to make a smart rewrite without being more specific and without putting any efforts ? throwing all away, start with a minimum and be proud it's faster and cleaner is only a short term solution You still didn't answer to the question I asked. How long do you want compatibility be kept, and what compatibility exactly ? (remember, you said that no one want to have everything forever, so let's be precise on what you want) And you can hardly complain to not be listened if you do not answer to precise questions when someone is willing to listen and try to find a solution. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Replace Yum With DNF
Le samedi 14 juin 2014 à 03:33 +0200, Reindl Harald a écrit : Am 14.06.2014 03:24, schrieb Michael Scherer: Le samedi 14 juin 2014 à 03:10 +0200, Reindl Harald a écrit : and that changes where much bigger than a fork of YUM renamed for no good reason especially in context of replace it it was renamed to provides side by side installation among others. I am sure that people would have been more upset if it was not done this way. ( as seen by the migration to gnome 3/kde 4 and people complaining exactly on that ). because both where a complete different product and not just a new version, DNF is just a new version of YUM and that's what major version numbers are for So maybe you should propose to have dnf named yum 4.0, and then since that's a major version, we would be ok to change the behavior, command lines switch, configuration and backend in a backward incompatible way? yes so, just to be clear, that's ok to change the behavior, command lines switch, configuratio and backend in backward _incompatible_ for yum 4.0 aka dnf, for you ? Or even with the name yum and a clear indication, that's something that shouldn't be changed, in which case, yum 3 behavior should be kept, which mean keeping all the code and behavior until later ? jesus christ the code behind has *nothing* to do with the userinterface and options - i have rewritten code of software i maintain for a decade now multiple times and in the meantime there is for sure not a single line the same as started 2003 without break user expectations In the case of dnf, the plugin api did changed. And I doubt people want to bring back the old one. So the user expectation around specific plugin is already broken. Yet, do you advocate bringing back the old API that no one liked, and more importantly, you volunteer to do that ? -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Replace Yum With DNF
Le mercredi 11 juin 2014 à 11:37 -0400, Chuck Anderson a écrit : On Wed, Jun 11, 2014 at 05:21:30PM +0200, Jan Zelený wrote: On 11. 6. 2014 at 08:52:34, Matthew Miller wrote: On Wed, Jun 11, 2014 at 02:44:10PM +0200, Jaroslav Reznik wrote: * package 'dnf-yum-compat-command' is installed by default. It obsoletes Yum and provides its own code/usr/bin/yum/code, a short script that redirects to code/usr/bin/dnf/code with an appropriate warning message that DNF is the preferred package manager now. Notice that upgrading F21 to F22 will not cause the compat package to be installed so will not disturb any upgrading users. This is kind of sentimental, and I think possibly Seth would not have liked to have a big deal made of it, but... I guess I'm going to anyway. I would like to keep the yum name in remembrance of his contributions. This also seems like the easiest path for all of the documentation, scripts, and user habits out there. I don't mind if the backend package is called dnf, but why not keep /usr/bin/yum as the primary command and just do the right thing, only warning on incompatible usage rather than nagging every time it is used? Actually the plan is to keep /usr/bin/yum as the primary command during the transition but it will do something similar to what the /sbin/service command does now. It will redirect to dnf and give user a message that it is redirecting to dnf. As for scripts, that's actually another reason why to keep yum around. Some scripts might not be able to handle some of the minor differences and some python scripts might still want to use the yum python API. That's why it makes sense to keep yum around for a few releases as a fallback. Have puppet, chef, ansible, salt, etc. been taught how to use dnf to install packages? I think it would be a shame to force all this software to do s/yum/dnf/ or to have to conditionally code for these differences based on OS release or the presense of yum vs. dnf. Why not just keep the command name the same with no nag message? I would expect puppet/chef to start using the library rather than direct access to the binary. And for ansible, I think the patch is quite simple, just add 2 lines. I guess we can start right now to get stuff merged. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [RFC] plans for initscripts in F22
Le vendredi 25 avril 2014 à 19:30 +0200, Miloslav Trmač a écrit : For LSB, there is an explicit promise that if a vendor does what is specified, the package will be possible to install and will run correctly. We do, of course, have the option to repudiate LSB and explicitly say we don't care for future releases. So shouldn't redhat-lsb or some subpackage be the one that pull that part ? As I do not think that Fedora is out of the box LSB compliant, I do not think that's a strong reason ( even if not breaking outside stuff could be something that matter ). In fact, if we were serious at supporting it, we would have it as a release criteria. I think we don't, and I think no one was interested into having it ( or rather, interested enough to do the job ). Also, regarding LSB compliance, do we want to consider all products to be LSB compliant by default, as I can perfectly see the cloud product being more interested into cleaning than lsb ? And it's not only commercial software; private projects that make no sense to publish (such as a company's web site) are equally affected such changes. Simply spoken, if we care only about package in Fedora, we are building an appliance; if we want to build an operating system, we do need to cater for software not included directly in the repo. Then how can we signal to people that they need to update those packages ? Because we can as well say we are gonna support that forever, but that will result into bitrot if no one really test. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: The Forgotten F: A Tale of Fedora's Foundations
Le lundi 21 avril 2014 à 11:56 -0400, Eric H. Christensen a écrit : On Mon, Apr 21, 2014 at 08:36:55AM -0400, Stephen Gallagher wrote: Now, let me be further clear on this: I am not in any way advocating the use of closed-source software or services. I am not suggesting that we start carrying patent-encumbered software. I think it is absolutely the mission of Fedora to show people that FOSS is the better long-term solution. However, in my experience a person who is exposed to open source and allowed to migrate in their own time is one who is more likely to become a lifelong supporter. A person who is told if you switch to Fedora, you must stop using Application X is a person who is not running Fedora. I'm confused here. No one is telling anyone that they can't use Application X. In fact, we do ( or rather, I do ). When I tell to people that Starcraft II and Eve Online do not run on Linux. When I tell that Office and Photoshop do not run on Linux. When I tell that their Iphone is not gonna work and I cannot be sure that the printer they just bought from Samsung is maybe not supported. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: The Forgotten F: A Tale of Fedora's Foundations
Le lundi 21 avril 2014 à 11:17 -0400, Stephen Gallagher a écrit : I'm trying to assert with this proposal that the best way for us to advance free and open source software is to continue shipping only open-source software, while making it easy for users to *transition*. By setting a hard-line on our users and saying You can only use FOSS, unless you jump through these fourteen poorly-documented hoops, we're discouraging our user-base (and ultimately, contributor base) from growing. I simply cannot see any way that we are satisfying our Mission by discouraging users from operating the way that they want to. Please excuse the reductio ad absurdum ( and my display of Lati^W Wikipedia ) But if we look at the current way, I think a high percentage of people want to run windows and download movies for free out on the internet, mostly because non technical people are motivated to do that. So if we really want to satisfy them, we should do that. The fact we don't prove that we will always do something that discourage people from operating how they want ( ie, without caring about license, copyright, etc ) for a variety of reasons. And so that we have to balance the various factors. So the question is more up to what point do we have to balance user requests for some value of users versus all others factors. The good part of working in free software is that lots of people do try various things, and it turn out that we are not operating in a vacuum. And there is distributions that do operate of the premise of functionality for users is more important than complete adherence of freedom ideals , mint is a fine example, ubuntu would be another one, mageia would be a 3rd one. So we can see if they did grow their contributors basis by taking this path ( especially given years have passed since they start ). And therefore, if the ultimate goal is to grow our own contributors basis, if this worked. I am not exactly sure it worked fine, but I do not have much data to back it up, more my own experience ( especially on Mageia side ). ( here, I should insert my theory on the stigma of beginners and how more complex distributions have more contribution, but too long for today ) All it does is ensure a positive feedback loop such that Fedora will eventually be used only by the limited set of people that are comfortable operating under strict restrictions on their behavior[1]. [1] Hmm... that sounds an awful lot like the way Apple behaves... except they can afford marketing. And lawyers, lots of them :) And they really limit people, which is not something we do, so the analogy is a bit disturbing. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: The Forgotten F: A Tale of Fedora's Foundations
Le lundi 21 avril 2014 à 13:19 -0400, Stephen Gallagher a écrit : On 04/21/2014 01:08 PM, Bruno Wolff III wrote: On Mon, Apr 21, 2014 at 12:37:57 -0400, Stephen Gallagher sgall...@redhat.com wrote: But I think that trying to actively discourage (read: prevent) users from installing such software is harmful to our Mission of advancing Free Software. In my view, it's okay to occasionally embrace closed-source as a means to expose more people to open-source. Failing to do so has a tendency to leave us labeled as zealots, which are often ignored. Does Fedora need to be that gateway OS? Maybe Ubuntu would be a better intermediate step? If Fedora isn't that gateway OS, why are we bothering? What makes it likely that any user would switch to us if they've entered the FOSS community via Ubuntu? (Don't get me wrong, this is a question we also need to answer, but I don't think it's wise of us to be recommending that Ubuntu handles gathering our new users for us.) So yes, if we want Fedora to have any mindshare at all (and therefore users) I assert that we /do/ need to be the gateway OS. Following your pattern of switching people to cross platform software then to Fedora, why not then start to invest into that, with for example : - distributing software for Windows in the same version that can be found for Fedora, following the same release schedule. Potentially having a updater. - have some easy way to switch back and forth ( something like anaconda creating a specific sharing partition, with software using it by defaults ) - partnership with user group for that, shipping them on the DVD we distribute. I am sure we can find lots of way, and that some of them have been already tried. And that seems perfectly aligned with Fedora mission and much closer to the way people convert users. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: advertisement in packaged software
Le mercredi 12 février 2014 à 07:11 -0500, Matthew Miller a écrit : On Wed, Feb 12, 2014 at 12:08:20PM +, Petr Pisar wrote: Are there any existing packages that already do that? vim advertises ICCF to make a donation for children in Uganda. Even leaving aside the whole charity / good cause vs. selling consumer goods aspect, I think a message about donations buried in the help is also a completely different case. On Fedora, it is in the help. On Debian, it is directly on the start when you open a empty file. So I am not sure which one is the default, there is no obvious patchs to enable or disable it in our packages and on Debian side. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
Le jeudi 30 janvier 2014 à 12:28 -0800, Dan Mashal a écrit : In fact, why don't we take this to a vote instead of arguing about it on this list? Why don't make this a Fedora elections issue? for the same reasons as usual, ie practical ones, like voting mean deciding who vote, ie, only board, fesco, all people in the packager group, all people with a FAS, anybody that come ? And for philosophical reasons like the simple fact that voting is divisive and that's going against the idea of building a consensus. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up; F22 will require applications to ship appdata to be listed in software center
Le lundi 27 janvier 2014 à 17:11 +0100, Andreas Tunek a écrit : 2014-01-26 Michael Scherer m...@zarb.org: Le dimanche 26 janvier 2014 à 18:14 +0100, Heiko Adams a écrit : Am Sonntag, den 26.01.2014, 12:01 -0500 schrieb Rahul Sundaram: Hi On Sun, Jan 26, 2014 at 11:57 AM, drago01 wrote: No this isn't an issue at all. No one is saying that non gui apps are useless or should be removed. The point is that gui installer installs gui apps. If you want to install a command line tool whats wrong with using the command line for that? If you don't know how to use the command line there is no point in installing it in the first place. I can use yum just fine but I don't find it convenient to go to the gui for gui apps and then remember to go use yum to install command line apps. Following this logic users have to use yum, dnf, yumex oder gnome-packagekit-installer to install i.e. additional GUI-Themes or mouse-cursors because they are no apps and for that reason not listed in gnome-software, right? If yes, that's IMHO absolute bullshit! It would make more sense to install them directly from the tool that set the mouse cursors, or the theme. Why switch to a different tool ( ie, a software installer ) to install something that is not a software ? So every application that could be extended would have to be rewritten? not rewritten, but extended. How would you solve stuff like extra gvfs-components? Have that support in nautilus? like we do for gstreamer or fonts. In the case of gvfs, this could manifests by people trying to connect to ftp, and then showing a popup this url is not supported, but we can install it. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up; F22 will require applications to ship appdata to be listed in software center
Le dimanche 26 janvier 2014 à 18:14 +0100, Heiko Adams a écrit : Am Sonntag, den 26.01.2014, 12:01 -0500 schrieb Rahul Sundaram: Hi On Sun, Jan 26, 2014 at 11:57 AM, drago01 wrote: No this isn't an issue at all. No one is saying that non gui apps are useless or should be removed. The point is that gui installer installs gui apps. If you want to install a command line tool whats wrong with using the command line for that? If you don't know how to use the command line there is no point in installing it in the first place. I can use yum just fine but I don't find it convenient to go to the gui for gui apps and then remember to go use yum to install command line apps. Following this logic users have to use yum, dnf, yumex oder gnome-packagekit-installer to install i.e. additional GUI-Themes or mouse-cursors because they are no apps and for that reason not listed in gnome-software, right? If yes, that's IMHO absolute bullshit! It would make more sense to install them directly from the tool that set the mouse cursors, or the theme. Why switch to a different tool ( ie, a software installer ) to install something that is not a software ? -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: acceptability of updates-testing breakage vs. rawhide breakage
Le vendredi 10 janvier 2014 à 09:56 -0500, Chuck Anderson a écrit : On Thu, Jan 09, 2014 at 10:42:33AM -0800, Adam Williamson wrote: On Thu, 2014-01-09 at 10:13 -0500, Chuck Anderson wrote: This appears to have also broken Fedora 19 updates-testing, which is even less acceptable than breaking rawhide. Eh, I'd suggest not. updates-testing is actually explicitly meant as a place to catch this kind of problem, whereas we're trying to keep Rawhide rolling and especially try not to break nightly image generation. At least we can vote broken things in updates-testing down. Wow, really? updates-testing is allowed to be more broken than rawhide? So why don't we just do all development in updates-testing, and don't push these changes to rawhide until they pass the updates-testing karma? This is not how I understand these things should work. I think this attitude will push even fewer people to run with updates-testing enabled. Out of anything that can happen during a update, having small broken deps is the most visible and the less problematic one. People focus because that's visible, but it doesn't break anything ( ie, your system still boot, it doesn't start to segfault or eat your data ), and can be reverted quite quickly by maintainer, and avoided by the tester using a option to yum. People are working on taskotron ( successor of autoqa ) and this will likely prevent this kind of issue in the future, I hope. If you feel that's important to make sure this doesn't happen, they will always accept any kind of help. But in the mean time, as this is IMHO the most beging type of breakage, I think we can tolerate them from time to time until we can properly automate the checking. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Unresponsive maintainer: Mark Chappell
Le vendredi 10 janvier 2014 à 13:54 -0700, Jerry James a écrit : On Dec. 5, 2013, I sent private email to Mark Chappell (tremble) about a change I need to the normaliz package in order to update to a more recent version of polymake. On Dec. 11, 2013, I opened https://bugzilla.redhat.com/show_bug.cgi?id=1040627 to ask for the same change. On Dec. 19, 2013, I applied for comaintainer privileges in pkgdb. I waited through the holiday season, in case Mark is on vacation, then asked for a response on Jan. 3, 2014 (comment 3 on that bug). It has now been 1 week since the request for a response, with no reply to the original email, the pkgdb request, or to the bug. Mark is not listed on the vacation page; fedora-active-user says: email trem...@tremble.org.uk FAS password for jjames: Last login in FAS: tremble 2013-08-19 Last action on koji: Mon, 30 Dec 2013 package list entry created: perl-Class-Trigger in dist-6E-epel-build by ausil [still active] Last package update on bodhi: 2013-01-14 14:38:59 on package nrpe-2.13-2.fc18 Last actions performed according to fedmsg: ERROR:active-user:'raw_messages' Well, there's a comprehensible error message! Anyway, does anybody have an alternate means of contacting Mark? Yep, I forward him the email -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf versus yum
Le jeudi 02 janvier 2014 à 16:45 -0500, Rahul Sundaram a écrit : Hi On Thu, Jan 2, 2014 at 4:36 PM, Michael Scherer wrote: It could be implemented as a plugin and still installed by default. It could be but I doubt that is the proposed change here. They just don't want to deal with the functionality at all and seem to have some sort of philosophical argument against it being the default behavior. The argument from the other side apparently is that users asked for it and they should get exactly what they asked even if doesn't make any sense mostly and the program they intend to replace it with has been used already with this functionality for several years which is bound to trip up users during the proposed transition. With people complaining all over the place that we do not respect anymore the unix way, here is a case where we let people shoot them in the foot. Also I don't see the advantage of that over just merging the functionality and adding a configuration option. I could see a few. having a plugin permit to have it more extensible. For example, let's say I want to have a system that act a bit smarter, and prevent removing kernel, and several others stuff depending on the hostname ( ie, in a classroom where people are using VM to test ). Or imagine I want to let kernel be removed because the system is in a container, so I can detect the container type and decide to let people remove or not. If all is set in stone in the main software, then we can hardly permit theses use cases. And for the record, i would be in favor of having a safeguard by default. In fact having it in a plugin permit to anybody to have it enabled or not in a downstream consumer, and this could even be a per-WG change. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf versus yum
Le jeudi 02 janvier 2014 à 16:08 -0500, Rahul Sundaram a écrit : Hi On Thu, Jan 2, 2014 at 3:52 PM, Matthew Miller wrote: This one is clearly one of those doomed to repeat history things in motion. Protected packages was first implemented * as a yum plugin because Seth thought it was kind of crazy and shouldn't be core functionality, but then it proved itself in real use and became built-in. Now, the DNF pages says Similar functionality can be implemented by a plugin, putting us right back where we were. ** Pretty much, yeah. I remember trying to convince Seth to merge the functionality and got pretty similar replies to what I hear from Ales now. Similar issues at https://bugzilla.redhat.com/show_bug.cgi?id=1044984 and https://bugzilla.redhat.com/show_bug.cgi?id=1044984. I really dislike going through the same process twice. Pushing such functionality out into plugins won't work well either because by the time users realize that such a plugin exists and they might need them, it is likely to be too late and if you discard existing features without understanding the use cases fully, you will end up creating a rough transition for users. If someone is going to replace A with B, it would be nice for the developers involved to go through the release history and bugs and find out why the current functionality was done the way it was before deciding to change it. It could be implemented as a plugin and still installed by default. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Sshd getting 'dyntransition' AVC's in SElinux enforcing mode
Le vendredi 27 décembre 2013 à 15:06 -0700, Philip Prindeville a écrit :
I’m seeing the following after an update (via yum) from F19 to F20:
time-Tue Dec 24 16:05:44 2013
type=SYSCALL msg=audit(1387926344.492:5867): arch=c03e syscall=1
success=no exit=-13 a0=6 a1=7f4e5e7afbb0 a2=20 a3=7fff44c2c550 items=0
ppid=686 pid=693 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=sshd exe=/usr/sbin/sshd
subj=system_u:system_r:init_t:s0 key=(null)
type=AVC msg=audit(1387926344.492:5867): avc: denied { dyntransition } for
pid=693 comm=sshd scontext=system_u:system_r:init_t:s0
tcontext=system_u:system_r:sshd_net_t:s0 tclass=process
time-Tue Dec 24 16:05:45 2013
type=SYSCALL msg=audit(1387926345.093:5883): arch=c03e syscall=1
success=no exit=-13 a0=7 a1=7f4e5e7acef0 a2=2a a3=666e6f636e753a72 items=0
ppid=686 pid=706 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000
egid=1000 sgid=1000 fsgid=1000 ses=627 tty=(none) comm=sshd
exe=/usr/sbin/sshd subj=system_u:system_r:init_t:s0 key=(null)
type=AVC msg=audit(1387926345.093:5883): avc: denied { dyntransition } for
pid=706 comm=sshd scontext=system_u:system_r:init_t:s0
tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=process
Is this a known issue? I’m running:
Can you make sure the label is correct on the fs ( ie, relabel the
whole / ), as this seems to be a wrongly labeled sshd.
--
Michael Scherer
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Schedule for Wednesday's FESCo Meeting (2013-12-18)
Le mercredi 18 décembre 2013 à 21:40 +, Jóhann B. Guðmundsson a écrit : On mið 18.des 2013 21:20, Reindl Harald wrote: who do you think you are to claim whatever people are outside the community? Individual that tells that truth and shed's light how RH operates. Shed light on RH decide on its own how to spend their money without asking to others ? Or the truth of having job title not decided by the community ? Since you are not aware of it Red Hat invented the position of Fedora QA Community Manager ( I dont know who but I would very much like to meet that person ) and placed Adam in that position. Community manager != manager. Yes, the title doesn't express it quite well, create some confusions and I would suggest to people in similar position to use community gardener as Dave Neary told me once to emphasise the difference. But if you would look at what I think to be usual US job titles, you could see stuff like office manager, key account manager and various other titles that doesn't hold much managerial responsibility in the traditional sense ( ie, managing people, deciding what others people do, etc ). So focusing on job title rather than the acts of the person seems to be a quite weak foundation for any kind of conclusion, especially since the last part of your mail seems to imply that you do not know what is in the job description. Adam had no history with the community when he took that job and neither does Mike R. Adam demonstrated skills by working on QA for another distribution ( ie mandriva ) for several years, handling discussion with community, handling tests on Cooker, etc, etc. It is all archived on ml, you can check. So claiming he had no history with the community is either a lie, or a myopic view of the community by restricting yourself to Fedora QA while ignoring the free software community at large for no good reasons. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On Thu, Dec 05, 2013 at 07:40:36PM -0600, mrnuke wrote: On 12/05/2013 11:38 AM, Michael scherer wrote: On Wed, Dec 04, 2013 at 08:25:54PM -0600, mrnuke wrote: This change is Sofa King stupid. Why couldn't we have just enabled the warning without turning it into an error, THEN let packagers work with upstream in fixing those warnings? Regulate, not ban. Because packagers will just ignore it [...] I think this is a childish argument, but let's take it. So what? You're going to start stepping on people's lawns and change things just because you want to impose your greater good? In fact, I already do, I add checks in rpmlint for what I think to the greater good. And in other times and places, I even forced people to fix some rpmlint errors in their packages, just based on my own judgement, or their packages would not be uploaded. And while you may think this is childish, I have some data to back my assertion that some people ignore until there is a enforcement. For example, I have seen no one except me requesting CVE for potential security problems that rpmlint do see since 6 months ( missing-call-to-setgroups-before-setuid, missing-call-to-chdir-with-chroot ). Even during reviews, that's just ignored because this is not mandatory to fix ( for example https://bugzilla.redhat.com/show_bug.cgi?id=976770 ). ( and I did a run on the whole set of Fedora packages, so I know that I was not lucky and found the only single rpm with a problem ). Let's rather ask the contrary, why is this so much a issue to communicate with upstream to fix things, and add patches ? -Werror is not needed for communication. It is not about communication. This is about a small group of people imposing their MY WAY!!!. Like there is a small group of people imposing packages guidelines, so I fail to see your point exactly. [...] really fail to see why there is people complaining. You run the assumption that all upstreams are paradise, heavenly, and friendly. And you also run the assumption that upstreams will never introduce such bugs in the future, never leaving packagers with the headache of patching things up. That's already part of the life of packagers. For example, suddenly, gcc decide to be stricter and suddenly, some VCS written in C++ decide to not compile anymore, so you have to spend 1 full day just to make it compile. ( of course, totally fictious example that didn't happen to me several years ago ). There is enough software not building anymore and dropped after mass rebuild to show that such problem are not really so uncommon. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On Wed, Dec 04, 2013 at 08:25:54PM -0600, mrnuke wrote: On 12/04/2013 12:10 PM, Brendan Jones wrote: This is just a pain. Can someone explain to me why this is good? Good or not, this is not the right question to ask. * Is this necessarry, and are the benefits worth the pains? * This change is Sofa King stupid. Why couldn't we have just enabled the warning without turning it into an error, THEN let packagers work with upstream in fixing those warnings? Regulate, not ban. Because packagers will just ignore it like some currently ignore rpmlint or various checks, and in turn this just produce noises for anyone looking to see if something need to be fixed or not. There is also the case where the code look fine, so you start to ignore the warning, then upstream change the code, and now, this is exploitable and problematic, but since people stop to cared about it, no one know until someone exploit it. Let's rather ask the contrary, why is this so much a issue to communicate with upstream to fix things, and add patches ? This is not a issue for Debian and Ubuntu, this was not for Mandriva and Mageia when similar changes have been enforced and usually, most upstream are receptive, so i really fail to see why there is people complaining. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Thu, Nov 07, 2013 at 09:55:12PM +0100, Miloslav Trmač wrote: On Thu, Nov 7, 2013 at 9:48 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Thu, 07.11.13 20:09, Miloslav Trmač (m...@volny.cz) wrote: Is there a technical reason why we can't use their packaging format, interpreting it with our technologies but staying compatible? Well, the most relevant bit is that they use apparmor for sandboxing. Nobody else uses that. Are the packages expected to ship their own apparmor policy? That would appear to be at odds with the idea of protecting against malicious packages. If they aren't expected to ship their own, could we implement the same sandboxing policy using SELinux? (https://wiki.ubuntu.com/AppDevUploadProcess seems to suggest Ubuntu will be using some higher-level profile format, not raw AppArmor.) The whole plan is here : https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement Looking at : https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement/Manifest I would say no. From a quick look, some abstraction are quite apparmor specific, see the concept of read_path, which is something we can hardly translate to selinux ( since apparmor use path, while selinux use a 2 tier system with label assigned to path, and then privileges assigned based on label ). What we could do is to have a better abstraction that would be apparmor and selinux comptaible. Since despites what Lennart claim, AppArmor is also used by Opensuse. And I am sure people using smackd ( such as intel people ) would be delighted to not be left in the cold. SELinux is still pretty RH/Fedora specific, even if Debian and gentoo support it in theory ( in practice, Debian didn't seems to support it that well ). And I don't think it is a good idea to use .deb as an image format. .deb is just an ar archive; if this were the only difference, it would not be worth fragmenting the ecosystem over IMHO. (Especially if the GNOME apps alternative is a compressed disk image, which saves disk space and costs extra CPU time and memory, making exactly the wrong tradeoff in most situations AFAICS.) While I do not see any obvious problem into using deb, I do not think it will bring much gain. It will matter for people managing the low level format, ie few people. Reusing the manifests ( if it was doable ) would have yield much more gain. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Wed, Nov 06, 2013 at 02:45:46PM -0500, Rahul Sundaram wrote: Hi On Wed, Nov 6, 2013 at 2:38 PM, Adam Williamson wrote: I'm still slightly out of sync with the fedora.next stuff (REALLY picked a bad time to go on vacation), but it does seem to me that a decent amount of 'mature reflection' was done on it before it was approved, at least. I don't really have a problem in believing that but it would be useful to know in more detail how the initial proposals came to be (who were involved? what problems are we trying to solve? what are failures of the current model? did it go through Red Hat management internally before being proposed and is more headcount being allotted? Was Fedora Board and FESCo members aware that a proposal were coming through and what was their rationale for choosing to go forward? etc) I suspect Mattew discussed this around him before, as anything anyone would propose. Would chatting with Spot on IRC count as going with Red Hat management, or just 2 community member talking together ? Because the outcome would be the same. But the The proposal was discussed IRL during Flock, the proposal was discussed here before[1] and got lot of feedback, the proposal was checked by Board[3] , by FESCO[2]. And I think this was in line with the discussion on the whole product or platform on the Board mailling list, who was started by the user base discussion initiated by Robyn [4]. So it all boil down to thing have changed, and so we think we should also do some changes, for all those reasons. [1] https://lists.fedoraproject.org/pipermail/devel/2013-July/186323.html [2] https://fedorahosted.org/fesco/ticket/1158 [3] https://fedoraproject.org/wiki/Fedora.next/boardproposal [4] http://wordshack.wordpress.com/2013/04/04/board-meeting-topic-for-the-day-user-base-aka-target-audience/ -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Le vendredi 08 novembre 2013 à 21:24 +0100, Miloslav Trmač a écrit : On Fri, Nov 8, 2013 at 2:31 PM, Michael scherer m...@zarb.org wrote: On Thu, Nov 07, 2013 at 09:55:12PM +0100, Miloslav Trmač wrote: On Thu, Nov 7, 2013 at 9:48 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Thu, 07.11.13 20:09, Miloslav Trmač (m...@volny.cz) wrote: Is there a technical reason why we can't use their packaging format, interpreting it with our technologies but staying compatible? Well, the most relevant bit is that they use apparmor for sandboxing. Nobody else uses that. Are the packages expected to ship their own apparmor policy? That would appear to be at odds with the idea of protecting against malicious packages. If they aren't expected to ship their own, could we implement the same sandboxing policy using SELinux? (https://wiki.ubuntu.com/AppDevUploadProcess seems to suggest Ubuntu will be using some higher-level profile format, not raw AppArmor.) The whole plan is here : https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement Looking at : https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement/Manifest I would say no. From a quick look, some abstraction are quite apparmor specific, see the concept of read_path, which is something we can hardly translate to selinux ( since apparmor use path, while selinux use a 2 tier system with label assigned to path, and then privileges assigned based on label ). Yes, that's one thing that we cannot (and shouldn't) support, but read_path is listed in the Red-flagged for manual review (use should actively be discouraged with updates made to policy groups and templates) section; is it likely to be frequently used? I can imagine that for any application having some kind of private database ( like a list of music file, save for games, or scoreboard, etc ), this would be used. So yeah, not much, but not that uncommon either IMHO. But even on the others fields, there will be some issues like the need to keep the policy in sync ( for policy_groups ), and the need to keep the template in sync (as the system work by taking template to generate the policy). Keep in sync the content and the name. It could be doable to adapt, but I am quite sure that sooner or later, we will face problem to keep the SElinux and AppArmor policies in sync, due to the difference of approach. I also expect that a conversion wouldn't be straightforward due to different stacks, etc. I do not really see that as a sustainable approach. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Workstation PRD summary and next steps
Le samedi 09 novembre 2013 à 01:21 +0100, Ralf Corsepius a écrit : On 11/09/2013 01:14 AM, Matthias Clasen wrote: On Sat, 2013-11-09 at 01:03 +0100, Kevin Kofler wrote: Christian Schaller wrote: The next update of the PRD will be posted to the fedora-desktop list as that is the designated 'home' of the working group and product and we want to avoid cluttering up the general Fedora-devel list with product specific further discussion. In other words, you want to move all discussion to a list that's mostly only followed by GNOME people where you can expect all changes to be swept through without any criticism… No, we want to move to a forum where the working group members have a chance to discuss things without being drowned out by 100+ mails/day from you. The other working groups are doing the same on their respective mailing lists. I am sure these lists will be public and open to everybody? They already are : https://lists.fedoraproject.org/pipermail/desktop/2013-November/thread.html https://lists.fedoraproject.org/pipermail/server/2013-November/thread.html ( and looking for the others is left as a exercise for the reader ) It was also posted on devel-announce : https://lists.fedoraproject.org/pipermail/devel-announce/2013-October/001258.html -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Tue, Nov 05, 2013 at 01:23:01PM -0800, Adam Williamson wrote: On Mon, 2013-11-04 at 23:50 +0100, Michael Scherer wrote: Le lundi 04 novembre 2013 à 21:02 +0100, Reindl Harald a écrit : Am 04.11.2013 20:56, schrieb drago01: On Mon, Nov 4, 2013 at 8:49 PM, Reindl Harald h.rei...@thelounge.net wrote: that's all true but you can be pretty sure if a app-store with bundeled applications exists *nobody* would package and maintain them as RPM - everybody would point with his finger to the app No because RPM packages apps *do* have benifits .. otherwise we wouldn't have this discussion. if it goes in that direction, and it starts faster than anybody likes you do a dramatical harm to the userbase which likes the consistent package managment and *really used* conecpt of shared libraries Again those are NOT MUTUALLY EXCLUSIVE. You can have sandboxed *and* rpm packaged apps at the same time. the most imporant word in your answer is *CAN* but you will not, nobody will package whatever application as RPM if he is fine with the app-store, so you *could* have both but i doubt at the end of the day it will happen If no one think that using a rpm is bringing any value, then indeed, no one will do the job. Now, if someone think this is better for whatever reasons, then this someone will do the job. It seems that your fear is that if people are not forced to make rpm, they will not see the value of doing so, and so would not do it. So if that's the problem, then the solution is to demonstrate the value of packaging and rpm rather than restricting all others alternatives. So to me this is the nub of the debate, and it's both fantastically interesting and fantastically difficult to work out in advance. In an ideal world things would work the way Michael describes, and also, the stock market would behave precisely as neat theories based on rational actors predict, and no-one would have any difficulty solving the three door problem, and healthcare.gov would never have been launched in a state in which it could not possibly work... And in the real world, well, it's the real world. :) Excuse me to remove your bnice piece of anticipation, and excuse me to not answer in the same way as I do not have a good idea for now. While what you show is likely true, there is just 1 single problem, this is not the future. This is the present. Currently, if you do not have the big button of your story, you still have a few choice as a ISV or upstream ( free or non free, the problem are the same for both, except that in the case of free software, people will complain to you for stuff that you didn't decide to do ): 1) you just distribute nothing, besides a tarball with source code. Or maybe just a gem or similar. This seems to satisfy perfectly some people who are quite happy of the sisyphean tasks that is the integration of a always growing pack of line of code, but strangely enough, it doesn't suit that well some end-users. And the choice of version shipped by the distribution is a choice that the distribution do. So far, this model served us quite well, and frankly, it satisfy most of my needs, because I have several years of experience. But besides some end-users, that's also not satisfying for some upstream, since they want to have their code sent to users fast for various reasons, like having feedback on new features ( the faster, the better, if possible the day of release ), sometime, they want to distribute bugfixes or proposed bugfixes. Sometimes they also want to have a supported version, potentially older. For every policy decided by a distro, you can find one reason to do thing differently. In the end, it all boils down on who decide the version, between the upstream, the end users and distribution. And while of course, with enough ressources, everybody can choose what he want, there is no one here with a unlimited amount of ressources. SO in the end, that's just distribution using their power to decide for others,; because others either do not have the ressource (users), or spend their ressources on making software (upstream). In order to take/give back some choice to upstream and/or end users, people tried various systems : 2) compile stuff in static That's ugly. And yet, that work enough well for distributing games on Linux since a few years (earliest personal example I can find would be Unreal tournament), for distributing software used in industry or even plugin. Some upstream do this for now. Despites us saying don't do that, it kill kittens, ulrich drepper said it. 2bis) use some magical system, like autoinstall, zeroinstall, etc. They didn't work that well. Potentially for chicken and eggs problem, potentially because some problem were left unsolved. However, since company like Microsoft and Apple ( or Google ) managed to make it work fine enough
Re: gnome software shell search provider? [Re: Is Gnome Software ready for primetime?]
Le lundi 04 novembre 2013 à 12:04 +0100, Nicolas Mailhot a écrit : instead going the easy windows-way and say ok, you have to reboot it would be more worth to optimize the handling *after* updates without reboot and let the user decie wichi services are needed to restart Not to mention the windows way only works for home systems. In any corporation, sending update and reboot now orders to tens of thousand of workstations is a major productivity killer AFAIK, some part of Orange do that. The only productivity killed is the one of the people that work in the night during the mandatory update windows at 2 or 3 o'clock. And at work, we have a policy of rebooting servers after every monthly update, to make sure the latest version of library and everything are running. And this mostly disturb irc screen/tmux session, because we do that during the night. (because if you wait for reboot to apply updates some people won't ever reboot and if you leave them the choice some will drop everything to reboot at once because they'd rather waste work time now than go home later at the end of the workday since updates take ages) Based on my experience, people already do that, so we have to cope with the fact they do not make update if we give them the choice. And this is also costing money to company due to calls to support that could be avoided if people ran the latest updated version of some software. One alternative is to force updates during the night, which would work fine for a workstation in a office ( and in which case, the issue of having to reboot become much less a problem ). But not for laptops. One way or another, adding causes for reboot is not going to make the product more successful in the market. Can we stop the race to adopt other systems antifeatures? Outside of posters in this thread, I think most people do not really care how the update work. What they care is to avoid weird bugs and that's the main point. Now, you disagree on the way to fix those weird bugs, but if no one fixed them so far ( and to be honest, I have not seen anyone even starting to work on this ), I doubt that waiting more is gonna make the fix appear. Free software is a do-o-cracy, whatever your perfect fix is, if it is not being implemented, it doesn't exist. And if people do not wish to use GPK or gnome-software to make updates because of the reboot, the old way still exist. People spoke of yumex among others, and the various scripts that were posted would still work, yum would still be here (or dnf). -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Le lundi 04 novembre 2013 à 12:21 +0100, Mateusz Marzantowicz a écrit : On 04.11.2013 11:13, drago01 wrote: On Mon, Nov 4, 2013 at 11:11 AM, Frank Murphy frankl...@gmail.com wrote: On Mon, 4 Nov 2013 11:03:45 +0100 drago01 drag...@gmail.com wrote: Apps shipping from upstream direcly does not have to be closed source. Firefox for instance could use that, or libreoffice, or eclipse. If a user needs a newer version (or nightly build) without having upstream worry about the specific distribution. I haven't read every post in the thread. Confused are use asking users to build nightlies (or other ver) from src? No we are just creating a way to allow those upstreams to create those builds for users (as Florian said without having them to update to rawhide or wait six months for the next release). The average user don't use nightly builds and should not be interested in such experimental software. Only developer could benefit from gaining access to latest builds in order to participate in project development. Developers are also interested into getting feedback and tests from users, and so if they can tell to people use this version, see if the bug is fixed, or tell me what you think of the UI, this benefit free software as a whole. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Le lundi 04 novembre 2013 à 21:02 +0100, Reindl Harald a écrit : Am 04.11.2013 20:56, schrieb drago01: On Mon, Nov 4, 2013 at 8:49 PM, Reindl Harald h.rei...@thelounge.net wrote: that's all true but you can be pretty sure if a app-store with bundeled applications exists *nobody* would package and maintain them as RPM - everybody would point with his finger to the app No because RPM packages apps *do* have benifits .. otherwise we wouldn't have this discussion. if it goes in that direction, and it starts faster than anybody likes you do a dramatical harm to the userbase which likes the consistent package managment and *really used* conecpt of shared libraries Again those are NOT MUTUALLY EXCLUSIVE. You can have sandboxed *and* rpm packaged apps at the same time. the most imporant word in your answer is *CAN* but you will not, nobody will package whatever application as RPM if he is fine with the app-store, so you *could* have both but i doubt at the end of the day it will happen If no one think that using a rpm is bringing any value, then indeed, no one will do the job. Now, if someone think this is better for whatever reasons, then this someone will do the job. It seems that your fear is that if people are not forced to make rpm, they will not see the value of doing so, and so would not do it. So if that's the problem, then the solution is to demonstrate the value of packaging and rpm rather than restricting all others alternatives. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Le lundi 04 novembre 2013 à 23:16 +0100, Reindl Harald a écrit : Am 04.11.2013 22:25, schrieb Stephen Gallagher: On 11/04/2013 04:01 PM, Kevin Kofler wrote: Huh? How is github relevant to an end user at all? They do not care if the source code of their software comes from github, SourceForge or some lone developer's HDD. They get it all from a distro. That's really not true any more in a world built on top of Ruby, Django, Node.js... In most cases, the people using these technologies don't use the distribution packages at all. They instead use 'rubgyem-install', 'easy_install/pip' and 'npm install'. The only thing they care about from the distro (sometimes!) is having those tools present who is they? any countable numbers of them? I guess that the same countable numbers we can see in they get it all from a distro. If I may, I would suggest that being a bit more consistent in your critics would benefit your position. don't forget that you never have real numbers in case of a Linux distribution and a few people telling you doing so is not they in context of the real userbase I was giving a talk at pycon.fr last week, and spend the 3 days discussing with people. Most people I discussed with ( coders and sysadmins alike ) were fully ok with using pip install, much to my dismay as a Fedora member. And those are people that write free softwares, people who contribute to the whole ecosystem, and people we want to help to write more free software. maybe you think they do not matters and we shouldn't care and only focus on your usecase, but I would disrespectfully disagree, despites the energy you spent on this thread trying to restlessly convince people. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Le mardi 05 novembre 2013 à 00:05 +0100, Reindl Harald a écrit : the real problem Fedora has that there is nobody with the power to make finally decisions and in doubt everybody can do anything and until the damage is not done things which are not broken are happily fixed If there was such a person or group, and if that person would say stop posting now, now we do offer sandbox because i decided', you would complain as equally as you do now. If you want someone who has a final word and a vision, there is Ubuntu and Mark. But this whole discussion is going totally off topic, so I will stop here and now. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: gnome software shell search provider? [Re: Is Gnome Software ready for primetime?]
Le dimanche 03 novembre 2013 à 14:23 +0100, Kevin Kofler a écrit : Michael Scherer wrote: When statistics cost you money, yeah, I think that's important to take them in account. Maybe your employer do not care about this, but I strongly suspect mine does, and I strongly suspect that most companies do care about this as well. Company computers should get updated only by the sysadmins (which AFAIK is how it works at his company, him being the CTO, sysadmin and lead developer in one person), or by automated scripts running as root (which is how it's done at my university, there's an autoupdate script running at bootup). Users have no business updating company-managed computers. You would delighted to know that not everybody do like this. We prefer let the employees decide when the time to update is right, due for exemple factor like having to leave the office soon, or being at a customers site without much network connectivity, etc, etc. As i say, we mostly have a fleet of laptop, and of course, the situation would be different if this was a set of workstation, but alas, this is not the case. Not to mention that basically, what you suggest is that the system bypass users explicit requests to shutdown, and that doesn't sound like a improvement to me ( and again, I say that also because that's what we tried at work, and this didn't work that well ). Yet this is exactly how PackageKit deals with this for online updates. Then I think this must be changed. And in fact, that's maybe why this is currently changed. However, since you didn't explained at all what are the issues you are facing with the new approach, and since you have only explained how you are doing on your 20 servers ( which is totally unrelated to the question of desktops, BTW, and which would still be usable at your convenience on anything you maintain ), I am quite sceptic on your whole intervention. The issues are that: * updates require 2 reboots, as long as this is automated, this is a technical detail. People seeing 2 times the bios do not really matter. Granted, this is annoying to have to enter your encryption password twice if you use luks, but I wonder if kexec cannot help on that part. * you cannot use what you upgraded before doing the reboots, and so ? If the upgrade is the reboot, this is to be expected. AFAIK, the update is not applied until you reboot, and AFAIK, you can still do stuff by yourself using yum. So if your point is you cannot use the update before the update is applied, I have yet to find what you mean exactly. * in particular, you cannot install new packages built against the updated ones before the reboots, Then this mean there is a problem in dependency. If I install kevin- simulator-1.0 that requires libmichael1.1 while libmichael1.0 is installed, either it need it and it will pull it, or it doesn't need and it will not pull it. This also ask the whole question of having non compatible library, etc, but I think we already answered that question with the update policy and need to keep a proper compatible ABI. * security fixes also only take effect after the reboots. unlike now, where they take effect based on random factors such as was firefox already running, or did I logged out after the update, or did I reboot on the new kernel ? At least, the new system bring coherency, you know that everything is up to date after the reboot. And again, if you like the previous way, you can still opt-out of the system. It also violates the principle of least surprise. In what way ? If the system clearly say we are gonna need to reboot to apply thoses updates, it is hard to say that you are surprised. And the principe of least surprise would be violated if we didn't followed the dominant paradigm, which is still windows afaik. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packages have proxy word.
Le samedi 02 novembre 2013 à 21:20 +0200, مصعب الزعبي a écrit : First , I ask very important questions: Is Fedora a global community or not ?? It is a global community, and as such, need sometime to take steps for the global community rather than for a local one. While the situation with your internet connexion is unfortunate, AFAIK, there is a immediate workaround. A more proper way would be to be able to restrict mirror by protocol ( or better, have yum/dnf to probe for them, ie switch to a different protocol if he see there is something fishy going with one protocol ), but unfortunately, this is not gonna to code itself in 1 night ( or if this is coded in 1 night, this is not gonna be backported itself in 1 night ). Another solution would be to make mirror manager always return https mirror for ip of some country or similar system. But then, you have to send a proper bug report, and so far, I do not see you doing that. Is Fedora working for Freedom or not ?? Working for freedom yes, but that doesn't mean working to fight all kind of freedom restriction irrespective of any others factors. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: gnome software shell search provider? [Re: Is Gnome Software ready for primetime?]
Le samedi 02 novembre 2013 à 21:40 +0100, Reindl Harald a écrit : Am 02.11.2013 21:35, schrieb Richard Hughes: On 2 November 2013 20:27, Reindl Harald h.rei...@thelounge.net wrote: lsof | grep DEL | grep /usr shows any opened but deleted file which is the case after updfates while applications are running Doesn't work with libreoffice, firefox or any application that loads plugins or modules explain why * the plugin is not loaded - fine * the plugin is not loaded but will be on demand - more fine, it loads the updated provided the updated is in the right place. If I have software1 that load plugin from /usr/lib/software1/v1 and suddenly, I switch to software1 v2 who load from /usr/lib/software1/v2, new plugins will be in /usr/lib/software1/v2, so outside of the search path of the running software1 v1 instance that currently run. Or what about if I start firefox at the same moment it is being updated ? Maybe you do not care about this because you know this is gonna crash, but the reason why so many people do not believe on Linux on the desktop is also partially due to this kind of crash from time to time. When you see them, you just start to think ok, this is crashing, that's not as solid as I believed, followed later by linux on the desktop is not even stable, let's go back to windows, it crash but at least, there is games. People internalized the problem and act as if this was normal, while it is not. Ars technica summarize quite clearly the situation on this problem : http://arstechnica.com/information-technology/2013/11/its-the-little-things-how-small-conundrums-make-many-hate-computers/ And I do not even speak of the users who reboot during a upgrade, resulting into unbootable system due to issue like this ( https://bugzilla.redhat.com/show_bug.cgi?id=1002891 ). Sure, people shouldn't do it. Yet they do, that's purely a statistical problem. Maybe you do not see it with your small set of 20 servers, but with ~ 40 RHEL desktops in my office, I have seen it 4 times. I have spend ~ 2h to fix each of them. Now, take a bigger fleer of laptop, and count how much this is costing in time to a company. Time lost by users, time lost by having someone looking at it instead of focusing on others issues. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: gnome software shell search provider? [Re: Is Gnome Software ready for primetime?]
Le samedi 02 novembre 2013 à 22:35 +0100, Reindl Harald a écrit : Am 02.11.2013 22:29, schrieb Michael Scherer: Ars technica summarize quite clearly the situation on this problem : http://arstechnica.com/information-technology/2013/11/its-the-little-things-how-small-conundrums-make-many-hate-computers/ And I do not even speak of the users who reboot during a upgrade, resulting into unbootable system due to issue like this ( https://bugzilla.redhat.com/show_bug.cgi?id=1002891 ). Sure, people shouldn't do it. Yet they do, that's purely a statistical problem. Maybe you do not see it with your small set of 20 servers, but with ~ 40 RHEL desktops in my office, I have seen it 4 times. I have spend ~ 2h to fix each of them. Now, take a bigger fleer of laptop, and count how much this is costing in time to a company. Time lost by users, time lost by having someone looking at it instead of focusing on others issues strange - and instead fix the reboot/shutdown to delay the shutdown in case of a running rpm/yum/dnf we go the crappy way of install updates offline to work around statistics? When statistics cost you money, yeah, I think that's important to take them in account. Maybe your employer do not care about this, but I strongly suspect mine does, and I strongly suspect that most companies do care about this as well. Not to mention that basically, what you suggest is that the system bypass users explicit requests to shutdown, and that doesn't sound like a improvement to me ( and again, I say that also because that's what we tried at work, and this didn't work that well ). Your proposal also do not account that by preventing shutdown/reboot on a laptop, a user that do not pay attention ( and again, this happen in real life ) could damage his computer if the laptop is still running and put in a laptop case, etc. And this is not theoretical damage. I fried my motherboard while doing something stupid like using the laptop as a ipod in my bag, despite the system shutting itself down at 80°C. sorry, but i can't see the improvement here If preventing problems and increasing reliability is not a improvement, I do not know what it is. However, since you didn't explained at all what are the issues you are facing with the new approach, and since you have only explained how you are doing on your 20 servers ( which is totally unrelated to the question of desktops, BTW, and which would still be usable at your convenience on anything you maintain ), I am quite sceptic on your whole intervention. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: abrt Bugzilla summary
Le lundi 16 septembre 2013 à 08:51 -0600, Kevin Fenzi a écrit : On Mon, 16 Sep 2013 10:36:41 +0200 Karel Zak k...@redhat.com wrote: Please, fix/improve your email client UI. All bugzilla emails contain all necessary information in email header: ...snip... For example if you use mutt then all you need is to add unignore X-Bugzilla-Product X-Bugzilla-Component to your .muttrc. Cool. That allows me to easily see it if I am viewing that email... doesn't however easily let me see if it I have a list of 10 new bugzilla emails coming that I haven't read yet. It's pretty common that we don't have component name in BZ summary... yeah, which is kinda sad, IMHO. I wonder if someday it would make sense to customize this per user? Possibly too much complexity... Assuming you filter your mail using something like maildrop that can filter the email and rewrite the Subject. If spamassassin can do it, why not do the same :) ( I use that to remove the [ml name] of some list, to reorder the subject for easier visual matching, etc, etc ) -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: COPR
Le mardi 03 septembre 2013 à 15:37 -0400, Jay Greguske a écrit : On 09/03/2013 12:29 PM, Michael scherer wrote: On Tue, Sep 03, 2013 at 09:48:52AM -0600, Kevin Fenzi wrote: On Tue, 03 Sep 2013 10:10:32 -0400 Jay Greguske jgreg...@redhat.com wrote: If we had SELinux policy enabled on the builders and used MLS on the chroots that would mitigate chroot-to-chroot attacks. I'm not sure if policy could prevent a chroot'ed process from getting access to the builder's certificate. If it could, I think getting SELinux working on the builders would be an easier path than re-writing koji to use VMs. Maybe someone with more expertise could comment on the latter issue. In the past we had selinux disabled on the builders, as mock didn't handle selinux very well at all and there were issues. (even in permissive mode). With this switch to Fedora 19 for builders, we also enabled selinux in permissive mode to gather information on any outstanding issues/avcs. Ideally I would like to get them all to enforcing and make sure we lock down the builds as much as we are able from the vm. the main issue is that mock should do the transition to a different domain once it run anything in chroot. I do have a patch but I was not able to make a policy for the transition ( or my patch is buggy ) and I didn't look at it since a few weeks. I can send it if someone want to take a look. Please post it. :) Sure, here it is. I just rebased on newer mock yesterday, and didn't tested at all ( it didn't rebase well, so maybe there is something missing ). I also didn't spent much time on the integration on a config point of view, ie config for each domain, or that's not needed, etc, etc. But that's polish I plan to keep once I had it working (and i do not remember the status at all, maybe that's completely broken and will not have time to work on it before 2 weeks ) -- Michael Scherer From 3fc44d9bc2cdb4ea04d7040e6e137aafcdf7e3f5 Mon Sep 17 00:00:00 2001 From: Michael Scherer m...@zarb.org Date: Wed, 17 Jul 2013 07:52:04 +0200 Subject: [PATCH] add options to make process run in a chroot in a different context --- py/mock.py | 3 +++ py/mockbuild/backend.py | 9 ++--- py/mockbuild/util.py| 21 - 3 files changed, 25 insertions(+), 8 deletions(-) diff --git a/py/mock.py b/py/mock.py index a91b030..5008b9e 100755 --- a/py/mock.py +++ b/py/mock.py @@ -443,6 +443,9 @@ def main(ret): execfile(cfg) uidManager.restorePrivs() +# TODO do not hardcode it +config_opts['chrootcontext'] = 'mock_chroot_t' + # configure logging config_opts['chroot_name'] = options.chroot log_ini = os.path.join(config_path, config_opts[log_config_file]) diff --git a/py/mockbuild/backend.py b/py/mockbuild/backend.py index 4b4940e..0e7e5c6 100644 --- a/py/mockbuild/backend.py +++ b/py/mockbuild/backend.py @@ -77,6 +77,7 @@ class Root(object): self.chrootuid = config['chrootuid'] self.chrootuser = 'mockbuild' self.chrootgid = config['chrootgid'] +self.context = config['chrootcontext'] self.chrootgroup = 'mockbuild' self.yum_conf_content = config['yum.conf'] self.yum_priorities_conf_content = config['priorities.conf'] @@ -541,13 +542,14 @@ class Root(object): # bad hack # comment out decorator here so we dont get double exceptions in the root log #decorate(traceLog()) -def doChroot(self, command, shell=True, returnOutput=False, printOutput=False, raiseExc=True, *args, **kargs): +def doChroot(self, command, shell=True, returnOutput=False, printOutput=False, raiseExc=True, context=None, *args, **kargs): execute given command in root self._nuke_rpm_db() return mockbuild.util.do(command, chrootPath=self.makeChrootPath(), env=self.env, raiseExc=raiseExc, returnOutput=returnOutput, shell=shell, - printOutput=printOutput, *args, **kargs) + printOutput=printOutput, context=context, + *args, **kargs) def doNonChroot(self, command, shell=True, returnOutput=False, printOutput=False, raiseExc=True, *args, **kargs): '''run a command *without* chrooting''' @@ -738,6 +740,7 @@ class Root(object): self.tryLockBuildRoot() log.debug(shell: calling preshell hooks) self._callHooks(preshell) +context=self.context if options.unpriv or self.no_root_shells: uid=self.chrootuid gid=self.chrootgid @@ -761,7 +764,7 @@ class Root(object): ret = mockbuild.util.doshell(chrootPath=self.makeChrootPath(), environ=self.env, uid=uid, gid=gid, - cmd=cmd
Re: COPR
On Tue, Sep 03, 2013 at 09:48:52AM -0600, Kevin Fenzi wrote: On Tue, 03 Sep 2013 10:10:32 -0400 Jay Greguske jgreg...@redhat.com wrote: If we had SELinux policy enabled on the builders and used MLS on the chroots that would mitigate chroot-to-chroot attacks. I'm not sure if policy could prevent a chroot'ed process from getting access to the builder's certificate. If it could, I think getting SELinux working on the builders would be an easier path than re-writing koji to use VMs. Maybe someone with more expertise could comment on the latter issue. In the past we had selinux disabled on the builders, as mock didn't handle selinux very well at all and there were issues. (even in permissive mode). With this switch to Fedora 19 for builders, we also enabled selinux in permissive mode to gather information on any outstanding issues/avcs. Ideally I would like to get them all to enforcing and make sure we lock down the builds as much as we are able from the vm. the main issue is that mock should do the transition to a different domain once it run anything in chroot. I do have a patch but I was not able to make a policy for the transition ( or my patch is buggy ) and I didn't look at it since a few weeks. I can send it if someone want to take a look. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: COPR
Le mardi 03 septembre 2013 à 15:37 -0400, Jay Greguske a écrit : On 09/03/2013 01:54 PM, Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/03/2013 12:29 PM, Michael scherer wrote: On Tue, Sep 03, 2013 at 09:48:52AM -0600, Kevin Fenzi wrote: On Tue, 03 Sep 2013 10:10:32 -0400 Jay Greguske jgreg...@redhat.com wrote: If we had SELinux policy enabled on the builders and used MLS on the chroots that would mitigate chroot-to-chroot attacks. I'm not sure if policy could prevent a chroot'ed process from getting access to the builder's certificate. If it could, I think getting SELinux working on the builders would be an easier path than re-writing koji to use VMs. Maybe someone with more expertise could comment on the latter issue. In the past we had selinux disabled on the builders, as mock didn't handle selinux very well at all and there were issues. (even in permissive mode). With this switch to Fedora 19 for builders, we also enabled selinux in permissive mode to gather information on any outstanding issues/avcs. Ideally I would like to get them all to enforcing and make sure we lock down the builds as much as we are able from the vm. the main issue is that mock should do the transition to a different domain once it run anything in chroot. I do have a patch but I was not able to make a policy for the transition ( or my patch is buggy ) and I didn't look at it since a few weeks. I can send it if someone want to take a look. Yes The builders should run each mock with a unique MCS Label and then lock them down with SELinux. I would be willing to help with this. This would be the easiest solution to the problem of separating out the chroots. Are you confident we can protect the host itself from attacks from a mock chroot? That's what Openshift Online use, and according to Dan, it resisted so far, and not because no one tried. You have to balance the density/efficiency/overhead vs the protection. Something like cubes running in a VM over a VM from a different technology would be more secure than a regular shared ssh server, but there is a price :) -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Unexpanded %post in updated rpm on F19
Hi, I found 2 rpms ( nscd, acpid ) that were sent in updates with a bug that didn't expand the systemd macro : https://bugzilla.redhat.com/show_bug.cgi?id=1000713 https://bugzilla.redhat.com/show_bug.cgi?id=1000712 This make them unable to be removed or upgraded, at least not without a manual intervention. Could something be done with it so that doesn't spread to others packages, and those be fixed before too much people install them ? -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Unexpanded %post in updated rpm on F19
Le samedi 24 août 2013 à 15:57 +0200, Michael Scherer a écrit : Hi, I found 2 rpms ( nscd, acpid ) that were sent in updates with a bug that didn't expand the systemd macro : https://bugzilla.redhat.com/show_bug.cgi?id=1000713 https://bugzilla.redhat.com/show_bug.cgi?id=1000712 This make them unable to be removed or upgraded, at least not without a manual intervention. Could something be done with it so that doesn't spread to others packages, and those be fixed before too much people install them ? found https://bugzilla.redhat.com/show_bug.cgi?id=995158 so if you push anything to updates-testing, please check that the macro are expanded correctly. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Bundled Flash
Le vendredi 23 août 2013 à 14:19 -0500, Jon Ciesla a écrit :
On Fri, Aug 23, 2013 at 2:11 PM, Adam Williamson awill...@redhat.com
wrote:
On Fri, 2013-08-23 at 13:57 -0500, Jon Ciesla wrote:
Pretty? Nope. Overkill? Maybe? Reliable? So far.
Are you sure? Does it work since rpm started throwing file
conflict
errors when you're trying to do this? That seems to be a
fairly recent
innovation, and the changelog indicates this was written in
2008. Has it
actually been tested recently?
https://bugzilla.redhat.com/show_bug.cgi?id=447156#c22
The discussions I could find about this seem to be down on
doing it in %
pre, so I can't see why %post would be any better. Ref
http://mm3test.fedoraproject.org/hyperkitty/list/de...@mm3test.fedoraproject.org/message/XRQUA2DOHNCFWWP2F7WLFW6L5GHPCERZ/
.
No, I've mostly left it as is since written, and adapted to additional
bundled PHP libs as needed. Testing was heavy at the time but has
been mimimal since. Conversely, it's been a long time since I've had
a BZ on any of this, which is not necessarily good evidence that it
works. If you find a better way I'm more than happy to rip it
off^H^H^H^H^H^H^H^H^H^Hlearn.
So what we found on irc :
Since rpm first create the files for the new rpm that is installed, then
remove the files that should be removed still present from old rpm and
not in the new one, we fix the issue by waiting until the directory is
removed to create the symlink. Looking at
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Scriptlet_Ordering ,
we need something after step 10.
So in %install :
+# remove bundled tinymce
+rm -rf %{buildroot}%{roundcubedir}/program/js/tiny_mce
+
( + others additions )
Since the only solution we have ( in new rpm ) is step 14, we need to
add a %posttrans :
+%posttrans
+if [ ! -h %{roundcubedir}/program/js/tiny_mce ];
+ln -s /usr/share/tinymce/jscripts/tiny_mce
%{roundcubedir}/program/js/tiny_mce
+fi
%posttrans is kinda garanted to have bash and ln, due to it being run
after everything.
However, we need to make sure that the symlink is managed by rpm in
%files, so we add a %ghost :
%config(noreplace) %{_sysconfdir}/httpd/conf.d/roundcubemail.conf
%attr(0775,root,apache) %dir /var/log/roundcubemail
%config(noreplace) %{_sysconfdir}/logrotate.d/roundcubemail
+%ghost %{roundcubedir}/program/js/tiny_mce
And if we remove the rpm, we need to remove the symlink :
+%preun
+if [ $1 -eq 0 ]; then
+# remove the symlink we have added in %postrans for migration
+rm -f %{roundcubedir}/program/js/tiny_mce
+fi
Now, this method has a huge problem, we cannot downgrade the package to
the bundled version. There is no script that would remove the symlink in
time, ie before step 3 of
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Scriptlet_Ordering
Everything that is run is from the new package to install, ie the old
rpm that we want to downgrade to. So since we would need to fix the old
rpm to have it downgradable, that's a bit hard.
Another issue is the %ghost, we cannot really check the symlink is still
the same. Maybe there is some better syntax for that.
--
Michael Scherer
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: Old packages remain on the mirrors for one week
Le mercredi 14 août 2013 à 11:26 -0600, Kevin Fenzi a écrit : I guess I'm open to the idea, but I have long wished we could have some way to always keep the previous version of a package for yum downgrades. ;( Keeping all that in metadata would bloat it a lot. I think Debian does that by having a special mirror that use date information in the url. See http://snapshot.debian.org/ So http://snapshot.debian.org/yesterday serve the debian set of package as seen yesterday, etc, etc That use some fuse magic, according to a quick check of http://anonscm.debian.org/gitweb/?p=mirror/snapshot.debian.org.git;a=tree ( and it was based on pdumpfs before ) -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: UML (user mode linux) for Fedora
Le jeudi 08 août 2013 à 22:35 +0100, Richard W.M. Jones a écrit : I wonder (idly) if anyone has every tried to package UML for Fedora, and if there is anything in the packaging guidelines that would stop UML being packaged as a regular package? By regular package, you mean using a separate spec/srpm from the kernel spec ? -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ExecStart line in systemd service files.
Le jeudi 08 août 2013 à 20:55 +0100, আনন্দ কুমার সমাদ্দার Ananda Samaddar a écrit : Hello all, I'm in the process of packaking kwakd for Fedora. On the user list Rahul Sundaram mentioned that the service file should not use a hardcoded path to the binary. So, the mail was : https://lists.fedoraproject.org/pipermail/users/2013-July/438912.html And I think Rahul refered to : #patch systemd service file to point to /usr/bin and not /usr/local/bin %patch0 -p0 Previously the ExecStart line read like this: ExecStart=/usr/bin/kwakd -p 80 After speaking to upstream and passing on Rahul's comments upstream changed it to this: ExecStart=kwakd -p 80 However when using the service file with the above line kwakd fails to start. I've had a quick look at some already installed service files and they all seem to include the full path to the binary. Can someone tell me what the correct line should be taking into account Rahul's comment? The path must be the full path, but it must ideally be changed by configure or make. IE, if I install the software in /opt/mysoftware with ./configure --prefix=/opt/mysoftware it should also generate a systemd file that use the correct path after ./configure make. For the exact way of doing that, you have to see autoconf manual, and I do not have a example ready to give. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: Proposal for a more agile Fedora.next (draft of my Flock talk)
Le samedi 27 juillet 2013 à 11:31 +0200, Brendan Jones a écrit : Is it even feasible to use the Fedora Java/JBOSS stack unless you are an existing customer? There is no customer for Fedora, so I am not sure to fully follow you. And last time I tested, ovirt was working on fedora, so jboss do work. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary of accepted Fedora 20 Changes - week 30
Le samedi 27 juillet 2013 à 12:54 +0200, Reindl Harald a écrit : Am 27.07.2013 12:45, schrieb drago01: On Sat, Jul 27, 2013 at 12:39 PM, Nicolas Mailhot Even if we do that ... for most of those user this mails are mostly noise. Where are the facts backing this assertion? Common sense ... so i am maintaing more than 20 fedora machines and i am happy about this mails from my *first day* with Fedora many years ago Sure, so that's 1 person. No, find just a bit more and we will start to be able to have proper data instead of anecdote. I can tell that most of the non technical users ( around 40 in my office, but I have no reason to believe the 1960 in others offices are different on that part ) using linux desktop at work ask me why they receive mail everyday speaking of the backup system not being configured ( and so mailling them to enable it ). Most have no idea why they receive mail from the computer, because for most of them, this is something they never faced. ( and we are speaking of corporate mail, so i can only imagine for the personal mail ). A notification that come on your desktop is something people can understand and a little bit more familiar to them . A mail sent by your computer to say something on a regular basis is not, except for technical person like you and me ( and usually, when I receive mail from cron, they are obscure and useless and due to some failure, so I think people writing cron job do not care that much to help me seeing what is is wrong ). so which commons sense is more woth? yours or mine? where are the facts backing up the opposite? nobody needs to backing up the opposite! if somebody comes up and and declares long existing things as noise and wants to deprecate them he is the one who has to bring facts cron output is usually not translated ( cause it is well know that every admin speak english, why should we take care of that ), and that's already a problem. A mail do not permit a good interaction ( like click here to configure stuff that you should configure ) while a notification permit that ( at least on a desktop ). There is no rate limitation for cronjob output. Usually, no need to send me 100 mails about job error, no disk space, I got the message on the first mail, the 99th are just useless spam that also contribute to the problem. AFAIK, you cannot easily ( ie, without being minimaly command line savy ) opt out of the mail notification, except by filtering that on your mail, which is not something all users know how to do ( but receiving mail they do not want is something they do not want, and I even got a server ending in a blacklist of yahoo because I think one user ended to filter the mail from cron he received on a server ). For a desktop use case with a single user, that's already enough reasons to use something else. For a desktop with more than 1 user, the issue are the same, except that now, someone has to configure the email of every user in /etc/aliases, thus needing more than a anaconda patch. And for servers, having 2 ways to get logs of what is running is just asking for more work than needed. When you setup something to aggregate the log ( splunk, central syslog ), there is no need to have a second system that send a different type of log on a different way, just because this was done like this before. 2 systems, twice the risk of failing, twice the work to setup, and of course, they do not match on feature. Anyway, I think I contributed enough to this thread, so I will stop here. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary of accepted Fedora 20 Changes - week 30
Le jeudi 25 juillet 2013 à 11:55 -0700, Adam Williamson a écrit : On Thu, 2013-07-25 at 17:36 +0200, Lennart Poettering wrote: On Thu, 25.07.13 14:39, Jaroslav Reznik (jrez...@redhat.com) wrote: Partially accepted Changes * No Default Sendmail - https://fedoraproject.org/wiki/Changes/NoDefaultSendmail - https://lists.fedoraproject.org/pipermail/devel/2013-July/185328.html Sendmail will be removed from @core. Removal of sendmail from @standard didn't pass. Note: About @standard group might be decided in next release of Fedora. * No Default Syslog - https://fedoraproject.org/wiki/Changes/NoDefaultSyslog discussed on https://lists.fedoraproject.org/pipermail/devel/2013-July/185329.html Remove rsyslog from @core, move to @standard pending revaluation in future. Note that this is not the decision I was interested in. I will hence not work on the implemetation of either of these features. Unless Matthew takes them over alone I will will mark these feature pages as obsolete as they didn't get agreed on. Taking rsyslog out of @core is a one-line commit to comps which someone could do in 30 seconds. It hardly needs 'working on'. Technically, fixing all packages with the assumption there is a MTA already installed and file for log will be there are also part of the feature that would have needed work. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora as an crowd founded project an additional funding source to our sponsor
Le mercredi 24 juillet 2013 à 15:11 -0700, Adam Williamson a écrit : On Wed, 2013-07-24 at 16:50 +, Jóhann B. Guðmundsson wrote: On 07/24/2013 04:40 PM, inode0 wrote: On Wed, Jul 24, 2013 at 11:07 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: The entire budget is not public so you won't get a definitive answer for a large portion of the budget. Why is it not public any reason why we the community cannot know how much we cost? I don't think there's any particular reason, but one thing is that it's not particularly obvious even within Red Hat: there isn't a single nice clear Fedora Budget, money gets spent on Fedora out of all sorts of other budgets. It may well be the case that *Red Hat* does not know precisely how much money Red Hat spends on Fedora. :) Working in IT @Red Hat, I concur, and I am pretty sure that no one has all the information to make that estimation. Network, hosting and storage are all under different budgets for different team, and all aggregated ( cause the DC where RH host Fedora server is not dedicated to Fedora, far from it ), and everybody has better things to do that splitting usage by project, and querying the right folks to get the number to start with. RH is not yet a bureaucratic behemoth where everything is precisely counted. However, a rough estimate would be easy to get, just ask for the number of servers, and multiply that by a estimated cost based on industry average. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora as an crowd founded project an additional funding source to our sponsor
Le vendredi 26 juillet 2013 à 13:32 +, Jóhann B. Guðmundsson a écrit : On 07/26/2013 01:07 PM, Michael Scherer wrote: Working in IT @Red Hat, I concur, and I am pretty sure that no one has all the information to make that estimation. Network, hosting and storage are all under different budgets for different team, and all aggregated ( cause the DC where RH host Fedora server is not dedicated to Fedora, far from it ), and everybody has better things to do that splitting usage by project, Not following what you mean by project. Fedora is a project, but so does gluster, ovirt, jboss, etc. Some of them are not hosted at all by RH, or hosted externally with RH people that serve as sysadmin, either officially, fully or not fully. And some are in the same DC than Fedora. I can hardly give more details, since that's handled by a totally different departement than mine, and each community still have lots of freedom on what to choose, but for example, jboss.org, who is hosting lots of RH-sponsored project, is hosted in Phoenix, as a quick mtr show. And each project has lots of freedom, the requirement of Fedora team are not the same as jboss ( ie, Fedora would never accept jira as a bug tracker ). So by project, i mean upstream project where RH sponsored the infrastructure, fully or not fully, with hardware or not and with people or not. On one hand you have Red Hat the company and on the other you have Fedora the project which means two entirely separated infrastructures. yeah sure these two might be communicating heavily between themselves unless ofcourse you want to risk issues from either the company or the project being able to directly affect each other when someone screws up or something fails or something needs to be updated in either the company or the project and that's just bad administrator practices. They are separated on a network level (different vlans, maybe different switchs/rack, depending on the space constraint) and on organisational level but likely not in different rooms and for sure not in different datacenters for efficiency reasons ( ie, handling less datacenters is more efficient than having to deal with 5 or 6 of them ). That's the main reason to have the sponsored servers in the same place for different projects, with RH taking care of paying the local IT person when there is a problem. Please also note there is lots of servers used by Fedora that are located where no one from RH has physical access, as seen on the list of DC used by Fedora infra : https://fedoraproject.org/wiki/Infrastructure/Architecture Having served as a sysadmin for a distribution project in the past, you always see a tension between the need to have a process to grant access based on merit, technical knowledge and trust, and the harsh reality of having to pay to get to the DC when it is not located where your contributors live ( in our case, every jump to the DC costed ~ 400€ and 1 or 2 days of vacations days, due to DC being far away and opened only during weeks ). -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora as an crowd founded project an additional funding source to our sponsor
Le mardi 23 juillet 2013 à 21:03 -0500, Chris Adams a écrit : You apparently don't want anyone who is working on Open Source as part of any job (Red Hat or not) involved in the distribution you support (since you said you don't value system admins fixing things while on the clock the same either). I see the value of having people paid to work on a project, but I also see the value of having more than 1 source of such people ( you can call this the Mandrake syndrom, and I could speak for hours on the problem it caused ). Having a project dominated by 1 single sponsor is a rather suboptimal situation. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora as an crowd founded project an additional funding source to our sponsor
Le mercredi 24 juillet 2013 à 10:31 -0400, Darryl L. Pierce a écrit : On Wed, Jul 24, 2013 at 09:05:40AM -0500, inode0 wrote: On Wed, Jul 24, 2013 at 7:49 AM, Darryl L. Pierce mcpie...@gmail.com wrote: On Wed, Jul 24, 2013 at 12:37:09PM +, Jóhann B. Guðmundsson wrote: We would need to form a financial sig that handles that. Are these people going to be paid for their efforts, since it's completely non-technical? Why is being non-technical related in any way to paying someone to do it? It's an administrative role. I'd assume that you'd pay somebody who's going to be doing this job. If not, that's fine. That's why I asked if it was going to be paid for, since it's a lot more work than just writing checks.` So you assume that administrative mean not fun, so people will not do it for free ? On one hand, i would agree, this is quite hard to find a good treasurer, motivated, etc. On the other hand, there is lots of group doing it around you. Having someone paid for that would be kinda self defeating, and having a world wide group is the real issue, knowing the various law around the world is nightmarish. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora as an crowd founded project an additional funding source to our sponsor
Le mercredi 24 juillet 2013 à 08:42 +, Jóhann B. Guðmundsson a écrit : On 07/24/2013 07:33 AM, Brendan Jones wrote: On 07/24/2013 03:50 AM, Jóhann B. Guðmundsson wrote: Earlier this evening I was asked how I expected Fedora to function in any way similarly to how it does now without the backing of one or more organizations like Red Hat. I gave the quick answer through donations since I was not in mood to give the detailed answers ( and taint that thread even further ) however I'm about do it here to certain extent since the questioner probably did not expect me to have actually given this any thought which I actually have although I have not chiselled it into stone, making it the concrete proposal the community demands since it's just a small fraction of a larger idea or rather vision I have but I have decide it be the correct time to share that part of that vision of mine with the rest of the community to gather feedback. Under the current model I thought it is not possible to make monetary donations to Fedora (I remember Jared Smith saying something about this at a linuxconf.au a while back) Hardware, physical items, consumable media etc is OK though. Something to do with US taxes, correct me if I'm wrong. Looks like we need to get the Fedora name out of the states You could just use a NGO outside of US. We used to have Fedora EMEA, and we have Borsalinux-fr. There is no need to have it done officially by the Fedora project or anything. And that's what was done for Mageia before the association got a legal entity, using another partner association in France as a proxy for money. I think Debian also do something similar for debconf, with SPI. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: ReadOnlyDirectories /etc and /usr for network-services
Le lundi 22 juillet 2013 à 00:02 +0200, Reindl Harald a écrit : Hi has anybody considered to put the following as default in systemd-units of network services? cross-posting to users-list intented because i think it is a good idea to bring it to a broader userbase! ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr http://www.freedesktop.org/software/systemd/man/systemd.exec.html additionally having the RPM database to accessable for network-services is fine, set for all listed below and reduces the attack surface InaccessibleDirectories=/var/lib/rpm InaccessibleDirectories=/var/lib/yum __ this would greatly reduce the impact of a possible root-exploit and IMHO make installing a rootkit hard to impossible while it is a good compromise to read-only /usr on a own partition without make system-administration via SSH harder I am not sure for /var/lib/rpm. For /usr and /etc, you need to be root to modify them most of the time if I am not wrong, and so if you are root, can you set them as being rw again ? ) ( and anyway, even if root can change that, it may be sufficient to stop some automated worms, as I have already seen one that overwrite openssh binary, this would have been prevented ) exeptiopns: * trafficserver it touchs /etc/trafficserver at startup ReadOnlyDirectories=/usr is fine Seems like a bug in the software. It would prevent to have it run from a livecd. * mediathomb refuses for whatever reason to start with read-only /etc ReadOnlyDirectories=/usr is fine Same as above. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Proposal for a more agile Fedora.next (draft of my Flock talk)
Le lundi 22 juillet 2013 à 09:38 -0400, Matthew Miller a écrit : And third, by increasing our engagement upstream, we can reduce our own work. For example, right now RubyGems.org doesn't do any validation of licenses, basic review for malware, or gem signing. If we knew that this basic diligence was happening upstream, we could extend our circle of trust. We've long had the mantra of upstream! upstream! upstream! for code and patches — we can do the same thing for packaging, for the same reasons and for similar benefits. (But to do that, we need to work with upstream packaging formats rather than demanding RPM — because experience shows that that doesn't work.) I am quite doubtful about this part. What interest most people pushing gems to github or anywhere is the low barrier of entry. By pushing our contraints upstream directly, I think we may go against the wish of those developers. There is a whole movement on no copyright, and we know this doesn't work like this unfortunately ( see SCO case, for example, and even if newer developers do not seems to care, I am old enough to remember ). And that's not that rpm is overly complex ( even if it could be simplified, and work on this front is going quite well ), it is all the rules around that make stuff more difficult. So if we decide to push the rules upstream, let's say on pypi, unless a huge part of the whole community start to check everything, I doubt we can have the same level of confidence on the whole set of modules. So in the end, we would still need to either : - be able to fix/correct metadata on every modules, or negociate with upstream to have them fixed - be able to filter and remove the one that are not good. We can make sure this scale for part that can be automated ( as perl/cpan did with kwality testing, and the whole feedback and cpantesters idea ), but we still need a manual inspection for various stuff, and there is likely less people interested into reviews than coding. So the question is how do we convince people who are not convinced yet of the added value of such rules ? -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 Self Contained Change: Ruby on Rails 4.0
Le mardi 16 juillet 2013 à 08:59 +0200, Vít Ondruch a écrit : Dne 15.7.2013 18:31, Bill Nottingham napsal(a): Jaroslav Reznik (jrez...@redhat.com) said: = Proposed Self Contained Change: Ruby on Rails 4.0 = https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_4.0 Change owner(s): Vít Ondruch vondr...@redhat.com, Josef Stříbný jstri...@redhat.com, ruby-...@lists.fedoraproject.org Ruby on Rails 4.0 is the latest version of well know web framework written in Ruby. == Detailed description == The Ruby on Rails stack is evolving quickly and Fedora needs to keep pace with it. Therefore the whole Ruby on Rails stack should be updated from 3.2 in Fedora 19 to 4.0 (latest version) in Fedora 20. This will ensure that all the Ruby developers using Fedora have the latest and greatest RPM-packaged Ruby on Rails. == Scope == Proposal owners: * The whole Rails stack has to be updated * New additional gems will have to be packaged * Some dependencies of the Rails stack will need update Does this work for users of Rails currently in Fedora, or will those packages need upgraded/ported as well? Bill There is plenty of rubygem-*-rails packages in Fedora. We will try to ensure, that all these works. There is currently no Rails application in Fedora to my knowledge. There is openshift-broker and console. And I think there is a gsoc to package gitlab. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Tools to mount and promote Fedora on cybers.
Le dimanche 14 juillet 2013 à 15:59 -0430, Eduardo Javier Echeverria Alvarado a écrit : Do not know the reason by it fedora kiosk spin edition was discontinued, but the same functionality can to achieve with xguest package. So you don't need anything more for install Fedora as a kiosk For a kiosk, being able to disconnect on idle is a nice feature, you do not want someone who forgot to disconnect from gmail to have his account compromised if someone use the kiosk after. Ideally, having xguest disconnecting rather than locking the screensaver would be a way to implement this. And usually, in a cyber cafe, you also want to be able to limit the time spent on the session by disconnecting after a time, and display that time to the customers. You also want to let people connect only if they paid :) -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
Le mercredi 03 juillet 2013 à 09:44 +0200, Johannes Lips a écrit : On Wed, Jul 3, 2013 at 9:32 AM, drago01 drag...@gmail.com wrote: On Mon, Jul 1, 2013 at 11:54 PM, Dan Mashal dan.mas...@gmail.com wrote: On Mon, Jul 1, 2013 at 2:52 PM, Pierre-Yves Luyten p...@luyten.fr wrote: Not sure if it makes any sense but maybe could we have something like freeze tag changes until desc is better. I propose this because testers will not _really_ want to -1 karma, and as a maintainer it might be a bit hard, but with a good reminder like not pushed to stable until desc is better I would have made less mistakes yes not being reminded is not an excuse and such proposal would not save time, still I believe it could help more than hurt There is already a perfect example of this. https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19 This is also a perfect example of useless does not fix bug x karma. If it is not *worse* then the previous package there is no reason to give it negative karma. If it doesn't fix the bugs, the update should fix, it is appropriate to give negative karma. Otherwise the bugs would be closed, when it becomes stable, but won't be fixed. That's not what the guidelines say : https://fedoraproject.org/wiki/QA:Update_feedback_guidelines#Update_does_not_fix_a_bug_it_claims_to -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
Le mercredi 03 juillet 2013 à 09:54 +0200, Johannes Lips a écrit : On Wed, Jul 3, 2013 at 9:47 AM, Michael Scherer m...@zarb.org wrote: Le mercredi 03 juillet 2013 à 09:44 +0200, Johannes Lips a écrit : On Wed, Jul 3, 2013 at 9:32 AM, drago01 drag...@gmail.com wrote: On Mon, Jul 1, 2013 at 11:54 PM, Dan Mashal dan.mas...@gmail.com wrote: On Mon, Jul 1, 2013 at 2:52 PM, Pierre-Yves Luyten p...@luyten.fr wrote: Not sure if it makes any sense but maybe could we have something like freeze tag changes until desc is better. I propose this because testers will not _really_ want to -1 karma, and as a maintainer it might be a bit hard, but with a good reminder like not pushed to stable until desc is better I would have made less mistakes yes not being reminded is not an excuse and such proposal would not save time, still I believe it could help more than hurt There is already a perfect example of this. https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19 This is also a perfect example of useless does not fix bug x karma. If it is not *worse* then the previous package there is no reason to give it negative karma. If it doesn't fix the bugs, the update should fix, it is appropriate to give negative karma. Otherwise the bugs would be closed, when it becomes stable, but won't be fixed. That's not what the guidelines say : https://fedoraproject.org/wiki/QA:Update_feedback_guidelines#Update_does_not_fix_a_bug_it_claims_to Could be, but if the still broken bugs are going to be closed, when the update becomes stable, doesn't really help, or? Given that this is enabled in the update. Then we could decide on : - better process, ie if you happen to notice a bug is not fixed by update, please reopen it - better tooling, ie a way to say do not close this bug to bodhi. Either a message in bodhi, or something on bugzilla side. -- Michael Scherer -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
Le lundi 17 juin 2013 à 10:52 +0200, Florian Weimer a écrit : I'm wondering what the current guidelines for filing bugs on bugzilla.redhat.com are. https://fedoraproject.org/wiki/Bugs_and_feature_requests welcomes filing enhancement requests, but some package maintainers disagree and require filing bugs upstream. I would like to avoid creating accounts in gazillion upstream bug trackers, If only more bug trackers would accept openid, this would make the issue less problematic for all. There is a plugin for that : https://wiki.mozilla.org/Bugzilla:OpenID_Auth_Plugin So is there any reason to not offer it, or I can start filling bug to request it ? -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F19 locale issue?
Le dimanche 16 juin 2013 à 13:36 +0200, Jan Dvořák a écrit : Hi, I don't have any idea how this happened: $ locale locale: Cannot set LC_ALL to default locale: No such file or directory LANG=en_US.utf8 LC_CTYPE=en_US.utf8 LC_NUMERIC=\'\' LC_TIME=\'\' LC_COLLATE=en_US.utf8 LC_MONETARY=\'\' LC_MESSAGES=en_US.utf8 LC_PAPER=\'\' LC_NAME=en_US.utf8 LC_ADDRESS=en_US.utf8 LC_TELEPHONE=en_US.utf8 LC_MEASUREMENT=\'\' LC_IDENTIFICATION=en_US.utf8 LC_ALL= I have LANG=en_US.UTF-8 on kernel cmdline and in /etc/locale.conf. Yep : https://bugzilla.redhat.com/show_bug.cgi?id=974778 In short, fix /usr/libexec/gnome-settings-daemon-localeexec to remove ', not ','. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Daily package ownership changes?
Le mardi 28 mai 2013 à 21:10 +0200, Pierre-Yves Chibon a écrit : On Tue, 2013-05-28 at 14:58 -0400, Rahul Sundaram wrote: 3) reports on source url which don't work - havent been done in a llong time afaik and needs to be automated and way to silence them in known cases in a per package way (by checking in a file into the git repo for that package for instance) I wonder if we could use fedmsg there, and trigger the check on each spec update of the rawhide branch or something like that. [...\ 6) abi bumps could trigger rebuilds as needed automatically by the buildsystem. Several distributions including Mageia, Mandriva, openSUSE has been doing this for ages already Any tooling from them we could use for this? AFAIK, Mageia do not do that. Mandriva and openSUSE both use a custom build system. But on a conceptual level, that's not hard. The way we could do it for Fedora is to see if there is a build on koji ( using fedmsg ), see if that a library, see the abi has changed ( using some kind of filter and a database ), and so run some script that rebuild and bump the spec on rawhide in mock, mail errors if any, and if not, just send it to koji. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
Le vendredi 24 mai 2013 à 07:08 +0200, Ralf Corsepius a écrit : On 05/23/2013 06:05 PM, Simone Caronni wrote: On 23 May 2013 17:38, James Antill ja...@fedoraproject.org mailto:ja...@fedoraproject.org wrote: On Thu, 2013-05-23 at 13:52 +0200, Simone Caronni wrote: mv /etc/nagios/nagios.cfg /etc/nagios/nagios.cfg.mine yum reinstall nagios --onlyfile /etc/nagios/nagios.cfg How is this functionally different from yum reinstall nagios ? Yes, yum/rpm will currently replace files with identical copies but functionally the extra copies are just wasting reinstall time. By doing yum reinstall nagios I don't have the the default config files (i.e. nagios.cfg.rpmnew is not created). This happens only on upgrades. yum remove pkg yum install pkg should do what you want (backups of modified config files). But that's unfortunately not always convenient if you need to remove dependent packages for yum remove ? I guess yum-shell may help in that case ? -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
Le mercredi 22 mai 2013 à 22:18 +0100, Richard W.M. Jones a écrit :
(3) RPM's spec file format needs to be redone using a Real Parser. At
the moment it has all sorts of strange corner cases (for example, how
to define a macro containing an arch-dependent list?). It'd be a good
opportunity to fix brokenness such as global meaning define, lack
of direct support for configuration flags, writing 0%{?rhel},
complexity of non-trivial %setup's, etc.
in 2/3 years :) Doubtful.
But then, add have the spec format to be easy to parse by a software so
we can write better QA tools like rpmlint or fedora-review.
(5) Almost all %pre/%post scripts need to be eliminated. There's no
reason that RPM can't detect when a shared library is being installed.
+1 for file triggers
Mandriva did have that, and that greatly help to enforce a consistent
policy and let packager focus on the others part rather than cut and
paste the same stuff.
And if we do have less %post script, we increase compatibility with
other distributions if they do the same.
--
Michael Scherer
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
Le mercredi 22 mai 2013 à 11:17 -0700, Ravindra Kumar a écrit : I don't know if this feature already exists, so forgive my ignorance if it is already there. I think having an RPM equivalent of Systemd's ConditionVirtualization will be very useful for controlling packages that are intended for virtualized environments. It could gracefully warn users about unsupported environments. It can also be overridden using some switch to force ignore the warning. libsolv/yast does it ( if I understood correctly ).You can have some virtual provides that exist as fake packages in the db, and then have a package have a requires on it. So it cannot be installed if the hardware is not here. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
Le mercredi 22 mai 2013 à 21:06 +0200, Björn Persson a écrit : Jan Zelený wrote: what are the changes that you would like to see in the foreseeable future (say 2-3 years) and why would you like to see them (what would they help you with)? Dare I say ... (puts on a helmet) ... Recommends and Suggests? It would take more then 2 to 3 years to make sure everybody understand the same thing for Suggests and Recommends. Without explaining why a package is suggested or recommended, people cannot make informed choice on it. So in the end, people will either get too much, or they will not get enough. And if you had suggest/recommend by default, you bloat the system, and if you don't, then that's useless. I am not against the idea, but that's not a technical issue. Technically, Suggest can be added to rpm quite fast, there is patch floating around. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default-installed MTA (was Re: MTA virtual provides craziness)
Le lundi 20 mai 2013 à 17:01 -0600, Kevin Fenzi a écrit : On Mon, 20 May 2013 15:55:24 -0700 Adam Williamson awill...@redhat.com wrote: On Mon, 2013-05-20 at 21:27 +0100, Peter Robinson wrote: if a disk dies it is nice to have it in syslog but it is useless if you see it days later while a mail from crond is more or less real time You still have to configure all of that and whether a MTA is installed automatically or not doesn't really make it work out of the box. For basic local delivery, configuration is not required. Mail to root, any default aliases of root, and any existing local user is delivered with sendmail's OOTB configuration, to /var/spool/mail where you can read it. Sure, but do many users do? Or does it sit there until the end of time? I think it may not be rotated, so in the long run, with enough verbose cronjob, you will fill your hard drive. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question about what to do if mantainer is absent
Le mercredi 15 mai 2013 à 11:40 -0700, Adam Williamson a écrit : On Wed, 2013-05-15 at 12:21 -0600, Pete Zaitcev wrote: On Tue, 14 May 2013 20:03:41 -0500 Michael Catanzaro mike.catanz...@gmail.com wrote: Well the open model has already been tried and proven in openSUSE, and they're still using it because it actually works really well. There aren't usually any issues regarding overlap of work, though admittedly that community is a smaller than Fedora's. It's hard to get away with scp /home/*/.ssh/id_rsa evilhost because every change is always reviewed by a small group of maintainers responsible for a collection of packages. How do they deal with a conflict? Imagine someone there splitting texlive into 2500 subpackages and then 100 angry contributors reverting it. What are they going to do in their open model then? FWIW, Mandriva used a similar open-commit model - compared to Fedora, basically all packagers were proven packagers and could commit to almost anything, a small range of packages were 'protected' as they are in Fedora - and I don't recall any significant issues like this actually popping up. In general, if you give F/OSS people a collaborative system, they will work collaboratively. It seems pessimistic to assume that people would get into edit wars just because they disagreed. We did have issues, but having a more exclusive model wouldn't have changed anything to that, and would indeed have slowed down the distribution. People who cannot work in a collaborative fashion will cause issues with or without rules. It would be true to say that the Mandriva package corpus overall was on average of somewhat lower quality, in terms of conforming to the distro guidelines, than Fedora's is, but I don't think that can be attributed to the collaborative model so much as to a simple lack of sufficient personpower. If anything it would have been *worse* without motivated packagers being able to go through the whole package base and fix up problems. The problem was more the lack of will to clean the package base. Each of my attempt to remove packages was met with some resistance, and there was no review on first commit, so some people were happy to push _lots_ of crappy package and then disappear. And people were too busy to clean, or to detect what is broken and remove it. (Probably the extant Mandriva forks still use such a model, but I'm not really involved in any of them so I can't say for sure.) Yep mageia still do, even if there is a greater focus on automate testing for broken deps, etc and a community who was more understanding the issue than before. Given the expectation in term of package numbers from users, and the size of the community at that time, that was ( and still is ) the only scalable model for Mageia project, and also the easiest to set up, as using a team system like Opensuse or Debian would have required more efforts, both on governance side and build system side, and since no one did the governance part, patches for build system didn't appear ( hard to code when there is no specification ) -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
Le jeudi 16 mai 2013 à 14:44 -0400, john.flor...@dart.biz a écrit :
From: Adam Williamson awill...@redhat.com
How do I determine what component to file a bug against? I guess I
have to find the package that caused these .service files to be
installed?
Yes. 'rpm -qf /lib/systemd/system/foo.service'.
I'd actually suggest doing:
rpm -qif /lib/systemd/system/foo.service
... and noting the source rpm.
For the sake of over optimisation :
$ rpm --queryformat '%{SOURCERPM}\n' -qf /lib/systemd/system/foo.service
foo-1.2-7.fc19.src.rpm
--
Michael Scherer
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MTA virtual provides craziness
Le mercredi 15 mai 2013 à 07:45 +0100, Peter Robinson a écrit : Adam, like you I seem to remember a subtle difference between MTA and the others. I think its because some MTAs only do local delivery, some do remote and some can do both. Eg sendmail needs procmail to handle the local part from distant memory. The way I see the issue, a software would likely need a interface, ie something that provides /usr/bin/sendmail with this set of supported option. We cannot requires directly this file due to alternative ( I think ), so we may need a Requires/Provides for that. I do not see why a rpm would need to express I need to have something listening on port 25 or anything like that ( and so pull smtpd or anything like this ), from a network point of view ( since anything using the network could use a different host, so this mean a Requires is not the good way to express this dependency ). -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reviewer needed for some packages?
Le jeudi 09 mai 2013 à 14:48 -0500, Alex G. a écrit : On 05/09/2013 02:06 PM, Hans de Goede wrote: Hi Wolfgang, They were already asigned but the reviewer told me that he has any time to review them, so i reset them to sero. It would be very nice if someone has the time and motivation to review them. The usual way to deal with this is to ask for a review swap, you cannot expect people to review your packages, without ever doing a review in return, that would mean some people would be only ever doing reviews without ever getting any of their packages into Fedora, which just does not work. Touche. I've had a package waiting over six months for a review, but I was able to get three packages in, in under a day by doing a review swap. There will occasionally be people who do reviews for the pleasure of doing so. For the rest of us, there's debit mastercard. Umh, I mean review swaps. Well, we could just decide to do 2 reviews for each review we receive and this would solve the issue nicely. ( and in fact, I only do reviews without putting more packages ) -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Build control-center in mock fail
Le mercredi 08 mai 2013 à 10:02 -0700, Adam Williamson a écrit : On 08/05/13 08:13 AM, Igor Gnatenko wrote: Thx. But why in oficially packages doesn't fixed? Does anyone know if it's actually the case that the guidelines require packages be buildable without internet access? I just had a quick search on obvious terms through https://fedoraproject.org/wiki/Packaging:Guidelines , and couldn't find anything. It may not be explicitly written, but we want to have reproductible builds, which also mean a build that do not depend on external entity such as a networked server. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
Le dimanche 05 mai 2013 à 11:18 -0600, Chris Murphy a écrit : On May 5, 2013, at 1:40 AM, Pierre-Yves Chibon pin...@pingoured.fr wrote: So if you disagree please provide *reasonable* arguments. Those who disagree have already done this ad nauseum. The summary: The Neilsen-Norman article cited is an editorial piece. It is out of scope, out of context, not a study, and not a paper. As I said earlier, I cited the url to say there is a discussion going on. And yes, this is as much useful as all others people stating their opinions in this thread. The fact that this is still being discussed ( as I found post/article/etc in 2010 and 2012 ) show that's indeed a complex question, and we can all agree on that. We can also all agree that we have no conclusive data for anything. IE, we have no data on shoulder surfing ( ie, is it prevalent during os installation ? ), nor data to show how problematic is the password masking in term of user experience. It suggests there's a usability consequence for masked passwords, which is an observation in the realm of Thank You Captain Obvious, that doesn't really need a study. It should be ignored. It may seems obvious but not everybody seems to agree with that according to this thread. And so, if it doesn't need a study, then why dismiss it as not a study ? Being obvious doesn't mean it should be ignored either. It's inappropriate for others to state the relative risk level of a user's situation, rather than deferring to the user's ability to self-assess their risk level. As a distribution project, we are doing this kind of choice almost daily. This one is just one among the million one that have already been done. I would like also add that not everybody is able to correctly self-assess their risk level. In fact, I would even say that few people are able due to various psychological bias like loss aversion ( http://qje.oxfordjournals.org/content/112/2/647.abstract ), or some others bias related to risk like : http://en.wikipedia.org/wiki/Zero-risk_bias http://en.wikipedia.org/wiki/Subadditivity_effect ( and maybe others among the list http://en.wikipedia.org/wiki/List_of_cognitive_biases ). The implemented change offers no alternatives, to account for elevated risk contexts. There are at least two alternative behaviors: a.) Mask by default with two fields, with an unmask option that would gray out the (now superfluous) second field. b.) The entry method used on mobile platforms, delayed masking per character. I argued against this in my earlier email when I brought it up. This isn't a mobile platform. It's higher risk, and probably not as easy to employ as option a.) which is a common cross platform behavior. Yes, and is not solving the same issue. Again, on a mobile platform, there is much more accuracy issues than on a PC, thus needing some changes. Now since the issue with the current change is I am forced to type the password visible and I do not want to do it for some others reasons, yes, that's a problem ( at least to me, even if I think that's a rare problem, but still a problem ). So what about this alternative proposal (made earlier, upon no one commented ) : c.) unmask by default, with a explicit mask option. That answer to the need of being able to mask if your environment requires it, so should at least satisfy part of the people who want that. And this permit to people who are more likely to make a error to check without thinking about doing it. That's the reverse of option A, because my hypothesis based on my own empirical users observations is that people who would need to use this option are not the ones that will think to do it. For example, I do use the unmask feature for long passwords given by someone else ( ie wifi ), since I cannot be sure I typed it correctly. But I would likely not use it for typing my own password for a account creation since I trust myself to type it right, like I think most people. And if people want others ideas, there is some creative one like this one, adding decoy text : http://hcsl-web.clemson.edu/wp-content/uploads/2012/12/Evaluating-the-Usability-and-Security-of-Input-Masking-Techniques.pdf or adding decoy characters : http://lab.arc90.com/2009/07/08/halfmask-an-experiment-in-password-masking/ ( didn't work with firefox, only with epiphany ) ( as a side note, I suspect that the whole idea come from this article : http://uxdesign.smashingmagazine.com/2012/10/26/password-masking-hurt-signup-form/ ) -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
Le vendredi 03 mai 2013 à 21:41 -0700, Dan Mashal a écrit : On Fri, May 3, 2013 at 9:32 PM, Matthew Garrett mj...@srcf.ucam.org wrote: If you want to change a decision, it helps if you're discussing it in a forum that's read by the people who made that decision. Anaconda developers don't read the developer list? That's terrible! That's the whole point of having a separate list in the first place, so people are not forced to read a high volume list like fedora-devel. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
Le vendredi 03 mai 2013 à 23:24 -0500, Eric Sandeen a écrit : What is the downside to defaulting to a hidden PW, with an opt-in mechanism to display the password as it's typed? The downsides of defaulting to cleartext have been noted, and to me are quite self-explanatory. First, we need to see why the input default to visible. The discussion about it have been going since a few years in usability circles when Jakob Nielsen proposed it : http://www.nngroup.com/articles/stop-password-masking/ http://uxmovement.com/forms/why-password-masking-can-hurt-your-sign-up-form/ and I think that even Bruce Schneier have gave his opinion in favor of the proposal : http://www.schneier.com/blog/archives/2009/06/the_problem_wit_2.html http://www.schneier.com/blog/archives/2009/07/the_pros_and_co.html I can add to that that I have seen more than once people setting a password which was not the one they believed due to : - keyboard layout ( ie, qwerty vs azerty in France ) - small usage difference with Windows way, again on azerty keyboard ( people using capslock on french keyboard to type numbers while they should use shift, as capslock just type capital letter like À or É and not 0 or 2, and if you do not understand, just look on the web to compare how different it is from qwerty-based keyboard ) Or I could also speak of the small non standard keyboard such as macbook one where ~ or | are not printed and where using the wrong keyboard could result in wrong characters if you are unaware of the problem. Or what about the people where the ASCII ( or ASCII related ) chars are not the norm, and people are forced to use it for the password despite sometime being less familiar with it ( ie, china, japanese, india ) ? I think we can agree there is a few problems to solve here, and showing the password ( I think ) help to solve them ( or at least minimize the time spent on figuring what is wrong ). But the discussion is not about that, even if I think the rational around the defaults. Showing by default will help people who are less familiar, hidden by default will satisfy people who think that's a security issue. Hidden by default and showing it on demand is likely to still be a hindrance to people who may not know they type their password wrong ( because I think most assume that it will work fine, we are not to a point where people assume by default this will fail ). So what about hiding on demand, and having it visible by default ? This way, people who prefer to have it hidden will be happy, and we are still friendly to non technical users. ( and then the discussion is around the mechanism to hide the password, between reduce visual clutter and have a explicit checkbox ) -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
Le samedi 04 mai 2013 à 05:51 -0400, Rahul Sundaram a écrit : Hi On Sat, May 4, 2013 at 5:37 AM, Michael Scherer wrote: and I think that even Bruce Schneier have gave his opinion in favor of the proposal : http://www.schneier.com/blog/archives/2009/06/the_problem_wit_2.html http://www.schneier.com/blog/archives/2009/07/the_pros_and_co.html Not anymore http://www.out-law.com/page-10152. This page cite the 2nd link I already gave earlier... And the way I read it, he explain that for him, the risk of should surfing are overrated. He also say that for a public terminal and a pin code, password should be masked, but for a person on a private computer, that's likely not a problem. Now of course, the issue is that a installer of a linux distribution is not a web site, so part of the discussion doesn't apply at all. And being at the moment in a install party ( which is as the most public way of installing a linux system ), I see quite often people writing their passwords on a paper ( and not only during install party ). And if most people have already trouble to keep up their passwords, I think most people will have more problem with passwords of others. The show password as we type proposal is good for a mobile as you likely have accuracy issues with it, but I am not sure that help solving the problems that showing password is (IMHO) meant to solve ( but again, I just speculate on the reason, I trust the designers to make educated choices but I am not mind reading ). -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
Le samedi 04 mai 2013 à 15:22 -0700, Dan Mashal a écrit : On Sat, May 4, 2013 at 2:37 AM, Michael Scherer m...@zarb.org wrote: and I think that even Bruce Schneier have gave his opinion in favor of the proposal : http://www.schneier.com/blog/archives/2009/06/the_problem_wit_2.html http://www.schneier.com/blog/archives/2009/07/the_pros_and_co.html Which he later took back. As said to Rahul, that's what he say in the 2nd link I gave. Do people read what I say before replying to me ? I can add to that that I have seen more than once people setting a password which was not the one they believed due to : - keyboard layout ( ie, qwerty vs azerty in France ) - small usage difference with Windows way, again on azerty keyboard ( people using capslock on french keyboard to type numbers while they should use shift, as capslock just type capital letter like À or É and not 0 or 2, and if you do not understand, just look on the web to compare how different it is from qwerty-based keyboard ) The installer should detect the keyboard automatically. I have yet to see how the installer can detect the layout of a keyboard, because that would solve much issues we have a work with luks passwords and grub. In fact you can even tell it what type of keyboard you have on the first screen. And if you had to actually choose the keyboard ( as I assume you don't since that's good by default for you ), you would know that there is sometime several variants, up to sometime 3 or 5 variants per country ( see swiss or italian ones in gnome ). I do not have issues with keyboard myself, but I can see why there is some case where some peoples may not know what to choose ( even if things greatly improved since last years when we had 8 unneeded keyboard variants for France ) And I am not sure that there isn't some country with more than 1 national layout ( depending how you interpret this map : http://en.wikipedia.org/wiki/File:Latin_keyboard_layouts_by_country_in_Europe_map.PNG ). Again, the situation may not be as simple as people believe for some users. How much, no idea. Should we care, I think we should but maybe not everybody agree. But I think we cannot say the issue do not exist, some people will type their passwords wrong. Or I could also speak of the small non standard keyboard such as macbook one where ~ or | are not printed and where using the wrong keyboard could result in wrong characters if you are unaware of the problem. I think people that have Macs have learned how to use their slightly different keybaords by now. I guess then the guy I have seen today having this same exact issue on Ubuntu on his macbook didn't got the memo. But the discussion is not about that, even if I think the rational around the defaults. Showing by default will help people who are less familiar, hidden by default will satisfy people who think that's a security issue. Showing by default helps no one. Then I think you are not doing enough support, or maybe you are more lucky than me with people you choose/have to help and support. Hidden by default and showing it on demand is likely to still be a hindrance to people who may not know they type their password wrong ( because I think most assume that it will work fine, we are not to a point where people assume by default this will fail ). Straw man argument. So what about hiding on demand, and having it visible by default ? This way, people who prefer to have it hidden will be happy, and we are still friendly to non technical users. Absolutely wrong. What part is wrong, that people that prefer to have it hidden will not be happy, or that this will not make some less technical user happy ? Cause I can find a few people that would be happy, just read the slashdot thread to find some of them ( so you cannot exactly say they do not exist ). Do not get me wrong, I would personally have been as surprised as you were if I did a installation of F19, and had no problem with the old way. But I can see people who would benefit from the change, and what the reasoning was. Why can't there be a wider community approval be able to vote on things like this? As I stated earlier there are a list of things that have changed without any real widespread community approval. Because we are Fedora, not reddit. For 1, voting has some inherent issues like who should be able to vote, and 2, who decide what can and should be set to be voted 3) who is volunteer to organize them ? In fact, if you are so keen on having community approval, you should lead by example, install a voting application on openshift or anywhere, and start doing vote for your own work, so you will see if that work, if you feel more legitimate, etc, etc. Just follow https://github.com/openshift-quickstart/limesurvey-quickstart and that's it. That would be fair to apply what you are preaching and to first see how it work on yourself before proposing the changes
Re: Do you think this is a security risk and if not is it a bad UI decision?
Le samedi 04 mai 2013 à 17:06 -0600, Chris Murphy a écrit : On May 4, 2013, at 3:37 AM, Michael Scherer m...@zarb.org wrote: Or I could also speak of the small non standard keyboard such as macbook one where ~ or | are not printed and where using the wrong keyboard could result in wrong characters if you are unaware of the problem. I don't know what this means. On my MBP these characters are printed in all applications including in anaconda's plaintext password field. I've yet to experience the behavior you describe on any Mac. Indeed, that was not clear ( or it was clear, but in my head only ). I meant not printed on the keys themself. And I checked, the issue is not present on qwerty models ( it seems ) , but on azerty layout, the ~ and | are not visible on the keyboard ( at least, on the keyboard I have on my old macbook 2.2 ). See for example : http://bblfish.net/tmp/2004_09_29/titanium_azerty_keyboard.jpg ( old power book ) http://users.telenet.be/depot/screenshots/mb%20azerty.jpg and others on google images. And last time I used it, the mapping was not the same between os x and linux on uc details ( ie, using ctrl vs apple key, if I am not wrong ), but I do not boot on os x any more, so maybe things are better now. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Idea: {Gnome,KDE,Xfce,...} Minimal Desktop groups
Le lundi 29 avril 2013 à 16:58 +0200, Sandro Mani a écrit : On Mon, Apr 29, 2013 at 4:55 PM, Rich Mattes richmat...@gmail.com wrote: On Mon, Apr 29, 2013 at 9:07 AM, Sandro Mani manisan...@gmail.com wrote: So, what about creating groups for the various desktop environments which pull in basesystem + xorg + mesa drivers + displaymanager + bare desktop shell? Do the groups already provided in comps.xml[1] not work for this task? Currently, one can use yum's groupinstall option to install the gnome, kde, xfce, lxde, mate, and cinnamon desktops and desktop environments. Rich Well, those groups are not exactly minimal. But minimal is not well defined. We have tried that at Mageia, and what i can say : - no one agree on what minimal mean ( cause everybody want something more later, or there is people complaining that minimal is too minimal ) - having minimal and non-minimal just confuse users, which were the primary target of having groups in the first place. So that was not working that well. So before asking for that, you should define minimal in term of features ( ie, not in term of packages, cause that's already too low level and was the cause of misunderstanding, because people didn't define the use case others than I want to have this installed cause I said so ). IE, what do you expect to work and what shouldn't. Because in the end, if what you want is just kwin or gnome-shell, then just install them. Something we could do is to have a specific provide for each session, like yum install session(gnome) that would take what is needed to have gnome in *dm listed as a choice, and i think that would fit the definition of minimal. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: audacity
Le dimanche 28 avril 2013 à 13:08 -0400, Nico Kadel-Garcia a écrit : There's also the Penguin Liberation Front for a few components with weird licensing that others haven't been able to resolve usable licenses for. PLF closed a few weeks ago[1], and was for Mandriva. [1] http://www.mail-archive.com/plf-discuss@zarb.org/msg01913.html -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of Hardened Packages
Le dimanche 14 avril 2013 à 01:43 +0200, Kevin Kofler a écrit : Richard W.M. Jones wrote: This would be excellent, and projects in this area could make a significant contribution. I suspect that any general code-to-policy translator will hit the Halting Problem, since it seems trivial to write a program which would not be possible to translate, but that doesn't mean it can't be solved for many useful real world cases. That's exactly why SELinux policy is the wrong representation. It duplicates information of the code without being automatically transformable either way, requiring every change to be made twice. If a software say he can open any arbitrary files on the filesystem doesn't mean it should. The code is most of the time not adequate to explain the permission really needed, that's too low level. And the unix model of user is not really adequate either. You could argue the exact same things about unix permissions why does apache requires me to modify permission on ~/public_html while I already expressed it can read them in code or firewall why should I open the port 80 when i already said in the code of apache that it will use this port. I repeat: The proper solution is to prevent executing any machine code which is not part of the program's source code. Block arbitrary-code execution exploits and SELinux is just dead weight. Repeating doesn't make it right. For example, what do you do for javascript interpreters ? ( like the one we can find in webpages, or in pdf, etc ). Or libreoffice macros. Or php interpeter, whose source code do we take in account, the one of php, the one of apache, the one of the php application, ( unless someone add a plugin of course ) ? The whole point of having it in 2 different places is to have a proper inspection of what it need to do. That's defence in depth. And security bugs have been fixed due to that inspection, like software leaking file descriptors by errors. More over, SELinux do more than blocking arbitrary code-execution exploit, it also allow to enforce access control to follow security model such as Bell-LaPadula model, it permit to have proper isolation for software like openshift origin, or SVirt. But you are welcome to convince any upstream directly to invest more time in stuff like seccomp-bpf as did by Chrome, vsftpd and others if you think that's the right approach to fix security issues. -- Michael Scherer !DSPAM:516a7a988771503385058! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20130413 changes
Le samedi 13 avril 2013 à 11:10 +, Fedora Rawhide Report a écrit : Compose started at Sat Apr 13 08:15:26 UTC 2013 [system-config-kickstart] system-config-kickstart-2.9.1-1.fc20.noarch requires Requires: Quite easy to fix : https://bugzilla.redhat.com/show_bug.cgi?id=951830 -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Each Fedora release I do series of blog on New Security Feature coming in the next Fedora.
Le mercredi 10 avril 2013 à 09:11 -0400, Daniel J Walsh a écrit : I need ideas for what to write about in Fedora 19. Could people send some to me. If you google security features site:danwalsh.livejournal.com you will see a lot of the past blogs. Things I have covered in the past in addition to SELinux advances, systemd improvements, journald, kerberos moving the cache, FreeIPA integration with ActiveDirectory, audit improvement, libvirt/containers ... Privacy in gnome 3.8 ? -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of Hardened Packages
Le lundi 01 avril 2013 à 12:29 +0530, Dhiru Kholia a écrit : On 03/29/13 at 08:47pm, Björn Persson wrote: 2. An alternate approach is to come up with an expanded list of packages which should be hardened. Since FESCo maintains a list, I suppose anyone can propose specific programs to be added to the list, but it seems pointless to explicitly list programs that are already covered by the first three criteria. I agree that it seems pointless (and tedious) to explicitly list programs which are already covered. However many packages (like PostgreSQL, Dovecot and MongoDB) meet the criteria but still are not getting hardened. I am not sure about the underlying reasons (oversight / performance concerns / etc.). What would be a good way to solve this problem in your opinion? (File bugs / Explicitly list such packages / Turn on hardening by default) I would file bugs, and list those that were checked on a wiki page, along a link to the bug and a date, and revisit the reason on a regular basis. It would be great to have some sort of automated method to find if hardening criteria applies to a particular package. Ideas are welcome! You can take a look on http://people.redhat.com/sgrubb/security/ , there is a script rpm-chksec to verify that. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
Le dimanche 24 mars 2013 à 09:05 -0400, Nico Kadel-Garcia a écrit : On Sat, Mar 23, 2013 at 11:08 PM, Kevin Kofler kevin.kof...@chello.at wrote: Miloslav Trmač wrote: BTW determining this accurately should be fairly doable[1]. Just look for symlink() and link() calls (and recursively through wrapper APIs / language bindings). These syscalls are fairly rare. That checks for PROGRAMS which run into this. It catches neither admin's custom scripts nor ln commands run directly by the users. Who knows on how many machines manually created symlinks point to inodes owned by different users? For example, I've been known to link /sbin programs to $HOME/bin/. on hosts I use and do not have root access on, so that traceroute iour chkconfig or the hardlink program are always avaialble. The decision to leave /sbin out of the default PATH except for root users has created many interesting such situations. You can also just fix the path for your user. This is especially true in environments where commercial or experimental versions of gcc or Java are instlled in /usr/local/gcc or /usr/local/java or /opt/[package] on some hosts and not others, and need to be activated on a user-by-user basis. Unless your $HOME/bin is using a sticky bit and is world writable like /tmp, this will change nothing for you. See http://users.sosdg.org/~qiyong/lxr/source/Documentation/sysctl/fs.txt#L160 for more information. Also, for the record, Debian also enable it for the next stable release : http://womble.decadent.org.uk/blog/whats-in-the-linux-kernel-for-debian-70-wheezy-part-1.html ( along other interesting things, like disable autoloading for seldomly used network protocols ) -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
Le lundi 18 mars 2013 à 17:42 +0800, Mathieu Bridon a écrit : Can't DNF do the same? The proposed system of targets seems extremely complex, for a functionality that is already possible... It is really not that bad, and the quantity of complexity in it is well hidden from everyone but NM and systemd. And it will give more to the users: they will only decide once what connections are available the regular background network tasks and which are not for, for all the applications. But applications can already query NM to get details on the state of the connection. But the logic of deciding which is which is likely in pk, not in nm. So implementing it everywhere will requires to duplicate the code and logic. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
Le mardi 12 mars 2013 à 12:27 +0100, Bjorn Munch a écrit : On 08/03 12.56, Michael Scherer wrote: Le mardi 05 mars 2013 à 11:34 +0100, Bjorn Munch a écrit : The package we have ready as an upgrade of the existing one removes some no longer needed patches, adds a few new patches, updates the spec file of course, and also adds an rpmlintrc file. It has of course been tested on a Rawhide installation. What do you mean by adding a rpmlintrc file ? Sorry for late reply, I was away. yeah, no problem We have run rpmlint on the package and it reported a number of problems. Many have been fixed, but this file lists a couple of problems to be ignored. Either they're not actually errors (e.g. a few zero length files) or they should be fixed upstream. We do not really use rpmlintrc like this, as rpmlint config is just a python script, and I think this would be too dangerous to have it executed automatically ( even if that's not really different from spec for that matter ). -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Fedora revamp proposal
Le lundi 11 mars 2013 à 03:44 +0100, Kevin Kofler a écrit : Michael Scherer wrote: A few wasted mega of disk space do not seems to be big problem if that permit to have more people on rawhide, faster tests and faster feedback. Old libraries accumulate over the lifetime of an installation, eating many MiB, not just a few. Given the target of rawhide, I expect people to be able to clean the unneeded packages after a while. Heck, like they do for packages that got orphaned and removed. And do you have any number ? Cause I have been running distro with such policy and many MiB still doesn't make much to my experience, so provides credible numbers if you wish to make your point , especially when talking to people who have seen this policy in action. The priority for rawhide should be having something that work first. It feels really wrong to design a whole library packaging policy around Rawhide. I do not see how it would feel wrong to try to fix a issue by changing a policy. And I do not see why Rawhide should be less important than stable for that matter. The focus needs to be on making stable releases clean without useless legacy compatibility baggage, and Rawhide needs to be the development bed for that. Compatibility libraries only make sense where the packages cannot be ported to the new version in time for the release. Usually, you have 3 months for branched to make sure everything is rebuild and that there is only 1 version of a lib. Have you read what Olav said, about packages without source rpm will be removed after 2 weeks, and then they show as having broken deps in report ? The script is not that hard to do, you can even get the one I wrote from svn ( http://svnweb.mageia.org/adm/puppet/modules/mirror_cleaner/ ). Not to mention that having the old version for a few days doesn't mean people cannot go ahead and rebuild their packages as they do now, the only difference is for users, since this permit to have a installable rawhide for a more longer period of time. And I think the problem could be solved ( and in fact, it is already a problem we have for those that install something, then remove the main software without cleaning deps ). The solution for that problem is called yum history undo, and it doesn't solve the old library problem. yum history undo work fine for simple and medium cases, but after a while due to the level of churn on stable release, it can break : http://pastebin.com/Bdt6ngy2 And there is nothing broken on my system according to yum check all. We should not refuse the idea on the ground that this is too complex for some users to understand the concept of soname. Either they don't, and then we should just hide libraries from the UI at some point ( and that's already done ), because with or without soname, that will not change anything, or they are able to understand and then we should not treat them as they couldn't. IMHO, having KDE 3 libs versioned as kdelibs4 is totally unacceptable. It's really confusing. (The only worse way to do things is to append an unreadable suffix for the C++ ABI to that as Debian did with kdelibs4c2a. But if you insist on keeping old ABIs around for any and all ABI changes in Rawhide, we'll eventually end up with the same mess!) That's just package naming. If you are more concerned by the name of the rpm than by having users, there is priority issue. So 2 drawbacks do not seems much, or at least not several. Can you maybe explain others issues so we can find a solution that work fine ? Sorry, there is just no solution that can make soname-suffixed libraries work. That's still not explaining. 2 is not several. And I do not accept solution is not the same as there is no solution. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
