Re: Marking zapped bugs
[Finally returning to this issue. If your mail client doesn't thread across this time span, see https://lists.fedoraproject.org/pipermail/devel/2010-November/145105.html for the previous part of the thread.] On Fri, 2010-11-05 at 12:19 -0700, Adam Williamson wrote: On Thu, 2010-11-04 at 16:10 -0400, Matt McCutchen wrote: On Thu, 2010-11-04 at 09:38 -0700, Adam Williamson wrote: The practical point is that F12 is about to go EOL which means the bug must be closed... Why? Obviously it needs to be clear that nothing further should be expected from the maintainer unless/until the version is bumped. But the project can choose to indicate that by closing the bugs as WONTFIX or some other way, That's, um, exactly the process we're discussing here. We close all bugs for a given release when that release goes EOL. (I forget what resolution is used, it may well be WONTFIX). The resolution is indeed WONTFIX. We send a warning note to all bugs that will be closed under this process, a short while before they're closed, so the reporters can check if they exist in a newer version and bump the report to that version to keep it open, if they like. I'm well aware of the process. The principle behind it is that maintainers are not expected to act on bugs that have not been reproduced in a currently maintained version of Fedora, and such bugs should be marked so that users know not to expect any action. I am not disputing this. However, the generally accepted definition of WONTFIX is that the bug has at least some validity but the maintainer has decided not to address it because the benefit fails to outweigh the cost (implementation and maintenance effort + any negative side effects, to include going outside the intended scope of the software). Zapping bugs by marking them WONTFIX is semantically incorrect and makes then hard to distinguish from bugs that meet the accepted definition of WONTFIX; it has also seemed on some occasions to lead maintainers to abuse NOTABUG to mean WONTFIX. Fedora is the only project I am aware of that does this. I urge that bug zapping should be accomplished: (1) With a different resolution, like Mozilla's EXPIRED (I can file the bug against Red Hat Bugzilla), or (2) Without mutating bugs in any way, but by publicizing that non-FutureFeature bugs open against EOL Fedora versions are considered expired and no action should be expected (GNOME seems to operate this way informally). Optionally, Bugzilla could be customized to return the resolution of such bugs as EXPIRED to facilitate the exclusion of expired bugs from counts/queries of open bugs as desired. If we don't auto-close bugs we wind up with a huge pile of ancient bugs which just gets in the way of people who want to come along and actually clean up the bug list for a package. It's harder to do that if you're looking at reports from the Stone Age. What you're really saying is that most maintainers want to work from a list of unexpired bugs. But there are ways to achieve that other than marking all the expired bugs WONTFIX. Maintainers can always filter on the currently maintained Fedora versions, but it becomes tedious to configure that, which is where a virtual EXPIRED resolution exposed by Bugzilla would come in handy. My broader point is that calling expired bugs closed is an oversimplification, and possibly a disingenuously generous interpretation of the situation. I'd guess that among non-ABRT bugs, well over 50% of expired bugs are still valid two Fedora versions later. But regardless of the figure, I believe that each client querying Bugzilla should be allowed to decide whether or not to include expired bugs, as distinguished from true closed bugs, based on its own needs. By stuffing expired bugs into the WONTFIX category, Fedora is depriving them of that choice. [I am not on the list; please keep me in replies.] -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Marking zapped bugs
On Fri, 2011-09-02 at 12:29 -0700, Adam Williamson wrote: On Fri, 2011-09-02 at 14:01 -0400, Matt McCutchen wrote: What you're really saying is that most maintainers want to work from a list of unexpired bugs. But there are ways to achieve that other than marking all the expired bugs WONTFIX. Maintainers can always filter on the currently maintained Fedora versions, but it becomes tedious to configure that, which is where a virtual EXPIRED resolution exposed by Bugzilla would come in handy. Mostly your proposal makes sense, Thanks for the response. but we're trying very hard to stick to upstream Bugzilla since 3.x, as heavy customization of 2.x caused more problems than it solved. So we're reluctant to add resolutions and statuses that don't exist upstream - even if Mozilla have hacked up their own copy of their own upstream bug reporting system to add resolutions... I don't buy that: Red Hat Bugzilla currently has 4 upstream resolutions to 7 custom ones. Are all the custom resolutions actively being phased out? Otherwise, can you give some examples to illustrate the marginal harm likely to occur if an 8th custom resolution is added? I'm disappointed that you don't appear to buy that this is important enough to merit discussion of alternatives, rather than just raising a problem with one of the ones I mentioned. The status quo may be fine for a maintainer or triager going down a work list, but when I as a user review old bugs related to a topic (perhaps to see whether a new bug is merited or I should join an old one), expired is equivalent to NEW rather than WONTFIX as far as I'm concerned, and it's annoying to have to open each WONTFIX bug to determine which kind it is. We have a number of options here which vary in implementation effort and how much burden they impose on user and/or maintainer to get what they want from an inadequate representation: 1. Status quo: hard to distinguish expired from WONTFIX. 2a. Add EXPIRED resolution and use it. 2b. Co-opt an existing little-used custom resolution, e.g., CANTFIX (semantically questionable on its face, but maybe reasonable in light of the explanation on https://bugzilla.redhat.com/page.cgi?id=fields.html#status ). 3. Do not change the bug state, and have maintainers apply the same conditions now used by the bug zapper on all of their searches. Reducing mutable state is generally good in that it reduces the possible ways for things to get out of whack. But then it takes more work to see whether a non-CLOSED bug is expired. 3a. Like #3, but make it easier with a virtual EXPIRED resolution. Probably an undesirable level of customization to Bugzilla. 4. Add an Expired keyword or custom field, use it, and: 4a. Continue to close the bugs WONTFIX. Ugh, but I can use the keyword/field in search and maybe even get it to show as a column on search results. 4b. Do not change the status, and have maintainers use the keyword/field in their search. No one should object to 4a as a change (though I recognize I am still asking someone to do work, especially if existing bugs are to be reclassified). We could start with that and at least stop losing the data in the next bug zapping cycle. I would appreciate your honest consideration (Adam and any other relevant parties). -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Marking zapped bugs
On Fri, 2011-09-02 at 13:54 -0700, Adam Williamson wrote: Hum, I didn't realize our resolutions were so customized, I thought they were the upstream ones; this is what I've been told when discussing custom resolutions in the past. It's certainly something you could propose as an enhancement by filing a bug against Bugzilla, then. OK, I will do that and post the link here. Any assessment of difficulty provided by the Bugzilla team can inform a decision between 2a and 2b. 2b. Co-opt an existing little-used custom resolution, e.g., CANTFIX (semantically questionable on its face, but maybe reasonable in light of the explanation on https://bugzilla.redhat.com/page.cgi?id=fields.html#status ). As noted at the top of that page, that is the policy for RHEL, not for Fedora. Fedora policy is https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#CLOSED . It states only The resolutions CANTFIX, WONTFIX, and WORKSFORME are for use by maintainers only, and are self-explanatory. You are right. But taking a step back, the project has the power to change the policy to best meet its needs. My point stands that the resolution is little-used (less than 2% [1]), and its use for expired bugs would harmonize with the current RHEL policy. None of my 131 bugs have been marked CANTFIX [2]; maintainers seem to find that the better-known WONTFIX and NOTABUG cover the range of cases. [1] https://bugzilla.redhat.com/report.cgi?x_axis_field=versiony_axis_field=resolutionquery_format=report-tableproduct=Fedoraformat=tableaction=wrap) [2] https://bugzilla.redhat.com/report.cgi?x_axis_field=versiony_axis_field=resolutionquery_format=report-tableproduct=Fedoraemailreporter1=1emailtype1=exactemail1=matt%40mattmccutchen.netformat=tableaction=wrap 3. Do not change the bug state, and have maintainers apply the same conditions now used by the bug zapper on all of their searches. Reducing mutable state is generally good in that it reduces the possible ways for things to get out of whack. But then it takes more work to see whether a non-CLOSED bug is expired. 3a. Like #3, but make it easier with a virtual EXPIRED resolution. Probably an undesirable level of customization to Bugzilla. 4. Add an Expired keyword or custom field, use it, and: 4a. Continue to close the bugs WONTFIX. Ugh, but I can use the keyword/field in search and maybe even get it to show as a column on search results. 4b. Do not change the status, and have maintainers use the keyword/field in their search. I think if we're going to change this, the only sensible change is to use a different CLOSED resolution. All the others seem like hacks which are likely to cause more trouble/confusion than they resolve. Fair assessment. We clearly want to bugs to be CLOSED, not open with a quasi-closed keyword or whiteboard field. I'm not sure who we is, but I disagree. The generally accepted definition of CLOSED is that the resolution is final unless subsequent events invalidate the original rationale. (C.f. the RHEL policy: The bug is considered dead, the resolution is correct.) All it takes for an expired bug to be reopened is for someone to have enough interest to retest it in a maintained Fedora version. To claim that this meets the definition of CLOSED is a big stretch. I believe that expired should properly be its own major state alongside open and closed, but we have alternatives that are less radical and still solve the immediate problem with search. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Marking zapped bugs
On Fri, 2011-09-02 at 15:43 -0700, Adam Williamson wrote: On Fri, 2011-09-02 at 18:33 -0400, Matt McCutchen wrote: We clearly want to bugs to be CLOSED, not open with a quasi-closed keyword or whiteboard field. I'm not sure who we is, but I disagree. The generally accepted definition of CLOSED is that the resolution is final unless subsequent events invalidate the original rationale. (C.f. the RHEL policy: The bug is considered dead, the resolution is correct.) All it takes for an expired bug to be reopened is for someone to have enough interest to retest it in a maintained Fedora version. To claim that this meets the definition of CLOSED is a big stretch. I believe that expired should properly be its own major state alongside open and closed, but we have alternatives that are less radical and still solve the immediate problem with search. The reason for the auto-closing is 'problems with search': developers do not want to have searches for open bugs cluttered up with bugs for ancient versions. Yes, of course. I was only responding to your apparent claim (at the top) that the use of CLOSED is semantically desirable. Any change which involves not closing the old bugs will result in the auto-close procedure not solving this problem any more, because the bugs will show up in a default search, and - as you mentioned - developers will have to remember to customize their searches every time to cover only currently-active versions. You are assuming that developers start from the default search to bring up their work lists. Do they? There are alternatives: - We can set up a shortened URL for a Fedora developer default search that pre-fills the appropriate fields on the query form, e.g., https://bugzilla.redhat.com/query.cgi?classification=Fedoraproduct=Fedoraversion=14version=15version=16version=rawhide . This would also save the Refresh Components latency. - They could use a saved query, which would change either every 6 months or not at all. - They could use http://bugz.fedoraproject.org/%s, which can be changed to do whatever they generally want. If we insist that the default search exclude expired bugs, it is already customized (compare https://bugzilla.redhat.com/query.cgi to https://landfill.bugzilla.org/bugzilla-tip/query.cgi?format=advanced), so we may be able to make a further customization to exclude expired Fedora bugs without affecting other products. But IMO, the default search should target the most common use case, which may well be users if developers do most of their queries a different way. My intent in putting forth this argument is to get past preconceptions and accurately assess the real drawbacks of approaches that do not close the bugs, since they are slightly better semantically. If the community still feels the idea is too radical, using an EXPIRED or CANTFIX resolution would still solve my problem. If we were to do that we might as well not do anything to old bugs automatically at all, because it's about as easy to customize a search to 'fedora 14, fedora 15, fedora 16, rawhide' as it is to customize it to 'no bugs with keyword EXPIRED'. Not quite: you don't have to remember which Fedora versions are maintained, or alternatively, update your saved queries every six months. And aside from search, marking expired bugs has the important function of cluing in the reporter that they should expect no action under the expiration policy. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Karma of edited updates (Re: glib2/glibc problem on x86 building mono-2.10.1)
On Sat, 2011-03-12 at 16:06 -0800, Christopher Aillon wrote: On 03/12/2011 04:33 AM, Kalev Lember wrote: I believe it should be fixed with glibc-2.13.90-6, but the update is currently stuck in Bodhi with 7 karma and not getting pushed even to the requested updates-testing repo: https://admin.fedoraproject.org/updates/glibc-2.13.90-6 Perhaps a Bodhi admin could take a look at the update. As I noted in the update several days ago, the update was marked obsolete/unstable when it reached karma of -3. It got to -7 at some point. This should have been submitted as a new update instead of editing the broken one. I expressed that sentiment some months ago and was told that editing updates is accepted practice. The real problem is that the karma was not reset. I filed a ticket about it: https://fedorahosted.org/bodhi/ticket/413 -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg build version numbering discrepancy
On Thu, 2011-01-27 at 21:05 -0500, Jean-Marc Pigeon wrote: Let be straight and simple (package name doesn't matter here) 1) Spec file say version: 1.2.3 2) sources file say tar file: 1.0.0 sources as included in git and generated by fedpkg new-sources Koji build say, compiling 1.2.3 everything fine but rpm contents itself is build with 1.0.0 This what I noticed this afternoon Nope. clement-2.1.400-1.fc15.src.rpm contains clement-2.1.400.tar.gz and not clement-2.1.320.tar.gz. Sources can be in either the sources file or the git repository. Since you added clement-2.1.400.tar.gz to the repository, Koji took it from there. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpmbuild: Bad Requireflags: qualifiers: Requires(posttrans)
On Mon, 2011-01-24 at 14:02 -0500, Bill Nottingham wrote: I believe folding any requirements for %posttrans scripts into 'Requires(post)' should be sufficient. I don't think so... IIUC, Requires(post) only applies until installation is complete, but a %posttrans script also runs following uninstallation. Granted, it may not be a problem for other reasons. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pkg-config, noarch, and rpmlint
On Mon, 2011-01-17 at 15:54 -0800, Brad Bell wrote:
I have a case where a package is noarch and it provides pkg-config support.
The problem is that pkg-config expects a noarch file corresponding to
the package to be stored in
${_libdir}/pkgconfig
and rpmlint complains that
cppad.spec:112: W: libdir-macro-in-noarch-package devel
%{_libdir}/pkgconfig/%{name}.pc
Put the file in /usr/share/pkgconfig .
--
Matt
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg switch-branch behavior
On Thu, 2011-01-13 at 10:42 -0800, Jesse Keating wrote: There is the case that when we switch to the branch, your last used state is behind or ahead the local index (that is the cached metadata the repo has about the state of each branch upstream). Please call it the remote-tracking branch (or ref). The index is something completely different. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security issues with abstract namespace sockets
On Wed, 2011-01-05 at 13:52 +0100, Lennart Poettering wrote: On Tue, 04.01.11 21:31, Matt McCutchen (m...@mattmccutchen.net) wrote: On Tue, 2011-01-04 at 14:11 +0100, Lennart Poettering wrote: Of these being used, dbus is correctly implemented, since it randomizes the socket name. Same for gdm. The relevant point is not randomness or unguessability, but that dbus chooses an available name and passes the actual name being used to clients (via the DBUS_SESSION_BUS_ADDRESS environment variable). However, even this may not be enough if the session dbus-daemon dies for any reason and an attacker takes over the name and sends malicious responses. It would be preferable if process death cases (the OOM-killer, even) did not automatically become security holes. I'm not sure how best to solve this. Wean ourselves from the convenience of the abstract namespace and go back to filesystem sockets in places only writable by appropriate parties? That's precisely what I want to tell people: don't use the abstract socket namespace, unless you really know what you do. The only cases where it really makes sense to use it is if you have a privileged service that i sstarted before any user code and never goes away and hence is not vulnerable to these problems. But as I said, it's impossible to guarantee that the service never goes away. It could crash or get OOM-killed (or terminate before all potential clients have terminated during system shutdown: is that possible?), and then you have a security hole. So I would recommend filesystem sockets for everything. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security issues with abstract namespace sockets
On Wed, 2011-01-05 at 16:35 +0100, Lennart Poettering wrote: On Wed, 05.01.11 09:39, Matt McCutchen (m...@mattmccutchen.net) wrote: That's precisely what I want to tell people: don't use the abstract socket namespace, unless you really know what you do. The only cases where it really makes sense to use it is if you have a privileged service that i sstarted before any user code and never goes away and hence is not vulnerable to these problems. But as I said, it's impossible to guarantee that the service never goes away. It could crash or get OOM-killed (or terminate before all potential clients have terminated during system shutdown: is that possible?), and then you have a security hole. So I would recommend filesystem sockets for everything. Well, if PID 1 terminates the kernel halts the system. Valid point. And udev fiddles with its OOM score to avoid being killed. There could still be a bug that causes udev to crash. As a general principle, systems should fail secure. And if the dbus system bus goes away the system becomes kinda unusable too. Whether system features break for legitimate users is beside the point. As long as user applications are still running, they may connect to the system bus and be tricked into doing something harmful by an attacker who impersonates it. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Local system security
An aside: On Wed, 2011-01-05 at 11:12 -0500, Adam Jackson wrote: (And of course what we're doing here is protecting against a malicious attacker who already has enough privileges to run code on your system, which means you're pretty far into having already lost. Meh.) I've seen this viewpoint a number of places. IMO, it's a shame that the community seems to be giving up on local system security. In various situations, it would be quite convenient if I could give other people shell accounts on my machine without risking compromise of all of my data. The virtualization solutions are more work to set up. If what you say is right, the many schools that still use large shared shell servers are relying on their users not to be too evil, or alternatively the users shouldn't use the servers for anything important. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security issues with abstract namespace sockets
On Wed, 2011-01-05 at 15:25 -0500, Adam Jackson wrote: On Wed, 2011-01-05 at 13:38 -0500, Matt McCutchen wrote: The more significant DoS condition is another user taking the name you want, which can happen in the abstract namespace but not in a directory only you can write. I don't have any of those. If the X server is running as root (like in the gdm case) then I can put the socket wherever I want. If it's Xvfb, then where do I put this directory? $HOME ? Nope, might not be there. /tmp/$USER ? Won't work if someone else mkdir'd /tmp/ajax before I did. What about the XDG_RUNTIME_DIR (/var/run/user/$USER) from systemd? -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Local system security
On Wed, 2011-01-05 at 16:13 -0500, Adam Jackson wrote: On Wed, 2011-01-05 at 14:10 -0500, Matt McCutchen wrote: On Wed, 2011-01-05 at 11:12 -0500, Adam Jackson wrote: (And of course what we're doing here is protecting against a malicious attacker who already has enough privileges to run code on your system, which means you're pretty far into having already lost. Meh.) I've seen this viewpoint a number of places. IMO, it's a shame that the community seems to be giving up on local system security. In various situations, it would be quite convenient if I could give other people shell accounts on my machine without risking compromise of all of my data. The virtualization solutions are more work to set up. You're putting words in my mouth just a little. The existing discussion was about denial of service attacks. OK, I misunderstood. Reading your remark by itself, I thought it referred to confidentiality and integrity too. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security issues with abstract namespace sockets
On Wed, 2011-01-05 at 16:37 -0500, Daniel J Walsh wrote: [XDG_RUNTIME_DIR] does not exist until after the User has logged in. X starts before the user logs in. Also multiple users need to be able to talk to same xserver. On Wed, 2011-01-05 at 16:47 -0500, Adam Jackson wrote: atropine:~% ssh 10.16.61.101 t...@10.16.61.101's password: Last login: Wed Jan 5 16:42:43 2011 [t...@dhcp-10-16-61-101 ~]$ set | grep XDG [t...@dhcp-10-16-61-101 ~]$ rpm -q systemd fedora-release systemd-15-1.fc15.x86_64 fedora-release-15-0.3.noarch Console login at least gives me an XDG_SESSION_COOKIE. Yes, I guess XDG_RUNTIME_DIR won't work in its current form, but it should be easy enough for systemd to provide directories with the necessary permissions at the necessary times. I think this is the right solution. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Security issues with abstract namespace sockets
On Tue, 2011-01-04 at 14:11 +0100, Lennart Poettering wrote: Of these being used, dbus is correctly implemented, since it randomizes the socket name. Same for gdm. The relevant point is not randomness or unguessability, but that dbus chooses an available name and passes the actual name being used to clients (via the DBUS_SESSION_BUS_ADDRESS environment variable). However, even this may not be enough if the session dbus-daemon dies for any reason and an attacker takes over the name and sends malicious responses. It would be preferable if process death cases (the OOM-killer, even) did not automatically become security holes. I'm not sure how best to solve this. Wean ourselves from the convenience of the abstract namespace and go back to filesystem sockets in places only writable by appropriate parties? -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On Thu, 2010-12-23 at 09:11 -0800, Fernando Lopez-Lezcano wrote: On 12/22/2010 12:56 PM, Casey Dahlin wrote: On Mon, Dec 20, 2010 at 07:16:21PM -0800, Fernando Lopez-Lezcano wrote: (a) unix-domain sockets for non-RT communication with the server Perhaps these could become abstract domain sockets. Could you explain a bit perhaps? I'm not familiar with them... (or maybe you have a url I could surf to?) See the unix(7) man page. In /proc/net/unix, the abstract-namespace sockets are listed starting with an @ sign. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [packager interface suggestion] Adding packages to buildroot directly from updates-testing
On Tue, 2010-12-21 at 16:15 +, Adam Williamson wrote: On Mon, 2010-12-20 at 22:57 +0100, Henrik Nordström wrote: * implemented by only a change in yum dependency resolution to use fallback repositories (i.e. updates-testing). I don't think that would be a good change, as it's changing the generic functionality of a tool for one specific use case: our build system. The change could be in a yum plugin that is only enabled by koji. No big deal. it would seem to make more sense, to me, to configure bodhi to re-try the build, with updates-testing repo enabled, if a buildrequires for a build that's been submitted to updates-testing cannot be satisfied in the initial run. i.e., implement the use of the fallback repo in bodhi, not in yum. How would that work? I thought a build had to be completed before it could be added to a bodhi update. And maintainers might wish to test a package against dependencies in updates-testing without being ready to push the new package to updates-testing. Not to mention that bodhi has to figure out whether a given failure was due to a missing BuildRequires. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [packager interface suggestion] Adding packages to buildroot directly from updates-testing
On Tue, 2010-12-21 at 16:45 +, Adam Williamson wrote: On Tue, 2010-12-21 at 11:24 -0500, Matt McCutchen wrote: On Tue, 2010-12-21 at 16:15 +, Adam Williamson wrote: it would seem to make more sense, to me, to configure bodhi to re-try the build, with updates-testing repo enabled, if a buildrequires for a build that's been submitted to updates-testing cannot be satisfied in the initial run. i.e., implement the use of the fallback repo in bodhi, not in yum. How would that work? I thought a build had to be completed before it could be added to a bodhi update. And maintainers might wish to test a package against dependencies in updates-testing without being ready to push the new package to updates-testing. Not to mention that bodhi has to figure out whether a given failure was due to a missing BuildRequires. it probably makes more sense with s/bodhi/koji. =) Yes. But then we need a notion of submitting a build to updates-testing in koji to enable the automatic fallback, and at that point it's almost as easy for the maintainer to build against updates-testing explicitly. Either variant of the approach has the danger though that because a build needs one thing from updates-testing, it will end up getting something else from updates-testing that the maintainer didn't expect. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What drives RPM Provides for shared libraries?
On Tue, 2010-12-21 at 22:10 -0500, Tom Lane wrote: I'm fooling around with trying to update mysql from 5.1.x to 5.5.x. One of the things that's happened in that transition is that they've dropped the separate libmysqlclient_r.so library --- presumably everything in regular libmysqlclient.so is now thread-safe. Upstream's idea of maintaining ABI compatibility is to provide symlinks, libmysqlclient_r.so.16.0.0 - libmysqlclient.so.16.0.0 etc. I find that that only sort of works --- RPM fails to generate the --provides entries that it used to. So for example I have this with the old RPMs: $ rpm -qp mysql-libs-5.1.52-1.fc13.x86_64.rpm --provides config(mysql-libs) = 5.1.52-1.fc13 libmysqlclient.so.16()(64bit) libmysqlclient.so.16(libmysqlclient_16)(64bit) libmysqlclient_r.so.16()(64bit) libmysqlclient_r.so.16(libmysqlclient_16)(64bit) mysql-libs = 5.1.52-1.fc13 mysql-libs(x86-64) = 5.1.52-1.fc13 but the closest I've been able to get with the new ones is $ rpm -qp mysql-libs-5.5.8-1.fc13.x86_64.rpm --provides config(mysql-libs) = 5.5.8-1.fc13 libmysqlclient.so.16()(64bit) libmysqlclient.so.16(libmysqlclient_16)(64bit) mysql-libs = 5.5.8-1.fc13 mysql-libs(x86-64) = 5.5.8-1.fc13 I thought for a bit that RPM was ignoring symlinks for this purpose, but even copying instead of symlinking the library didn't get me a second set of provides items. What drives those decisions? I guess RPM is using the SONAME embedded in the library, which you can see with readelf -d. Assuming that ld.so is happy to satisfy a NEEDED entry for libmysqlclient_r.so.16 by opening a file with that name and getting a library with SONAME libmysqlclient.so.16, it seems that rpm should add the Provides based on the file name. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding packages to buildroot directly from updates-testing
On Fri, 2010-12-17 at 18:38 -0500, Orcan Ogetbil wrote: On Fri, Dec 17, 2010 at 1:36 PM, Matt McCutchen wrote: On Fri, 2010-12-17 at 13:20 -0500, Orcan Ogetbil wrote: On Thu, Dec 16, 2010 at 11:03 AM, Chris Adams wrote: That makes the push process much more fragile/difficult. If you use a updates-testing build of package A, and package B (that depends on package A) gets rebuilt, then you may have a package B that can't be pushed to stable until package A gets pushed. What if there's a security update on package B that needs to go to stable ASAP? Then you build the security update asap, and put it in testing. How does that solve the problem? The point was that the new B may need to go to stable before the new A is ready to go to stable, so there needs to be a way (at least) to build it against the old A. Ah, you mean when there is a soname bump or such change in A? That happens less frequently, but as far as I know there is a koji command koji untag-pkg tag package which will help. It's not hard to write a script to -scan for a newer A than the specified version, -untag new A(s) if exists, -build B, -retag A(s). Sorry, I missed your point in the first email. That will work, assuming the user has permission to do the tagging; it is essentially a buildroot override in reverse. So the question is just what we want to optimize for: more testing of packages while they are in testing, or less fallout when a package in testing is broken. Or if the infrastructure problems are solved, we could use custom tags and get the best of both worlds. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [packager interface suggestion] Adding packages to buildroot directly from updates-testing
On Mon, 2010-12-20 at 21:55 +0100, Henrik Nordström wrote: Suggestion on how to express this in the packaging process: BuildRequires with a version requirement pulling in from updates-testing if the required version can not be satisfied from the stable repository. I don't like this. I would prefer to be explicit about the set of packages available to build against, rather than allowing BuildRequires to automatically pick up packages from testing. But don't count my opinion for much, since I'm not a packager. Additionally, when the goal is just to test rebuilding a package against another package in testing, it may not be appropriate to change the spec file only to change it back again later. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding packages to buildroot directly from updates-testing
On Tue, 2010-12-21 at 01:29 +0100, Henrik Nordström wrote: mån 2010-12-20 klockan 18:12 -0500 skrev Matt McCutchen: That will work, assuming the user has permission to do the tagging; it is essentially a buildroot override in reverse. So the question is just what we want to optimize for: more testing of packages while they are in testing, or less fallout when a package in testing is broken. Or if the infrastructure problems are solved, we could use custom tags and get the best of both worlds. Using the buildroots for testing is not the right approach for increasing the level of testing. Any use of testing packages while building should be requested by the specific build, not as a general blanket. I feel the same way, I was just trying to be objective. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding packages to buildroot directly from updates-testing
On Fri, 2010-12-17 at 11:08 -0700, Kevin Fenzi wrote: Lets step back a bit here as I think this thread is drifting. What issue(s) is this proposed change trying to solve? * The OP talked about that we are not 'testing' the update entirely because it's not in the buildroot, so we aren't confirming that it works to build against. * Other folks mentioned delays in rel-eng buildroot override processing? Any other benefits to this change? For the first point I agree that we aren't testing it for building against (if it's not in buildroot override), but I think there is still testing going on. Other folks who build vs fedora can and do build against the testing repo. So, not sure I find this compelling. Examples? How likely are they to catch bugs that would affect Fedora's own dependent packages? I think the best solution would be to use custom tags routinely and let all packagers create their own tags, assuming the infrastructure issues can be solved to make that practical. Packagers could build against dist-fN-updates or other users' custom tags as desired. There should be a way to get a list of all active custom tags relevant to one's build. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding packages to buildroot directly from updates-testing
On Fri, 2010-12-17 at 18:32 +0100, Ralf Corsepius wrote: * we are building packages against the known-to-be-broken package The old package is already in stable. We're not doing additional harm by building against it unless the breakage is a regression that affects the building of dependent packages. At most, we waste the effort of performing the build. whose replacements already are waiting in updates-testing. * we are building packages against packages in updates, which are known to be replaced with the versions from updates-testing. The point is that is not true! A significant fraction of builds in updates-testing do not go to stable because some problem is found with them. Unfortunately, the data at https://fedorahosted.org/fesco/ticket/517 do not tell us this fraction. I have added a comment there requesting better data. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding packages to buildroot directly from updates-testing
On Fri, 2010-12-17 at 13:20 -0500, Orcan Ogetbil wrote: On Thu, Dec 16, 2010 at 11:03 AM, Chris Adams wrote: That makes the push process much more fragile/difficult. If you use a updates-testing build of package A, and package B (that depends on package A) gets rebuilt, then you may have a package B that can't be pushed to stable until package A gets pushed. What if there's a security update on package B that needs to go to stable ASAP? Then you build the security update asap, and put it in testing. How does that solve the problem? The point was that the new B may need to go to stable before the new A is ready to go to stable, so there needs to be a way (at least) to build it against the old A. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding packages to buildroot directly from updates-testing
On Thu, 2010-12-16 at 09:28 -0700, Kevin Fenzi wrote: On Thu, 16 Dec 2010 10:03:30 -0600 Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Stanislav Ochotnicky sochotni...@redhat.com said: Note that I am not saying things should go into buildroot as soon as they are built, but as soon as they are in updates-testing. There is a difference. There will still be reasons to use tags/overrides. That makes the push process much more fragile/difficult. If you use a updates-testing build of package A, and package B (that depends on package A) gets rebuilt, then you may have a package B that can't be pushed to stable until package A gets pushed. What if there's a security update on package B that needs to go to stable ASAP? Additionally, what if package A is built, after a few days serious problems are found in it and it's deleted until the maintainer can sort them out. What happens to packages B, C, D, and E that built against this version? They will have broken deps. I don't think this is worth even looking at until we have an AutoQA broken dep test live. There may even be cases in which B won't have a broken dep and still won't work with the previous version of A (or at all). All packages that were built against the new A may have to be tracked down and rebuilt, like with GCC bug 634757, which becomes a PITA. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding packages to buildroot directly from updates-testing
On Thu, 2010-12-16 at 17:49 +0100, Ralf Corsepius wrote: On 12/16/2010 05:28 PM, Kevin Fenzi wrote: On Thu, 16 Dec 2010 10:03:30 -0600 Chris Adamscmad...@hiwaay.net wrote: Once upon a time, Stanislav Ochotnickysochotni...@redhat.com said: Note that I am not saying things should go into buildroot as soon as they are built, but as soon as they are in updates-testing. There is a difference. There will still be reasons to use tags/overrides. That makes the push process much more fragile/difficult. If you use a updates-testing build of package A, and package B (that depends on package A) gets rebuilt, then you may have a package B that can't be pushed to stable until package A gets pushed. What if there's a security update on package B that needs to go to stable ASAP? Additionally, what if package A is built, after a few days serious problems are found in it and it's deleted until the maintainer can sort them out. What happens to packages B, C, D, and E that built against this version? They will have broken deps. How would this scenario be different from what we have now? As it works now, if the problem is found before A goes to stable (and we hope the testing process would find it), the build (or all of the builds in the custom tag) can just be untagged. The fallout is nicely contained. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning system-auto-death
On Thu, 2010-12-16 at 18:33 +0100, Ralf Corsepius wrote: On 12/16/2010 06:26 PM, seth vidal wrote: On Thu, 2010-12-16 at 18:13 +0100, Ralf Corsepius wrote: Just a thought: How about equipping a repo's metadata with some sort of expiration/best before date, which yum etc. could use to warn users? If we had something like this, system-auto-death etc. would become superfluous. it would mean we'd have to be able/willing to push new metadata out to the base repo so that the repo could be used at all for future installs. Not necessarily - Yum could simply issue a warning and continue to work, yum could have a --disable-expiration-warnings option, ... There are many possibilities Rather than push the issue onto the user, I think the right solution would be for the fedora repo definition to have an option updated_by=updates that causes yum not to check its expiration when the updates repo is also enabled. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning system-auto-death
On Thu, 2010-12-16 at 18:54 +0100, Ralf Corsepius wrote: On 12/16/2010 06:43 PM, Matt McCutchen wrote: On Thu, 2010-12-16 at 18:33 +0100, Ralf Corsepius wrote: On 12/16/2010 06:26 PM, seth vidal wrote: On Thu, 2010-12-16 at 18:13 +0100, Ralf Corsepius wrote: Just a thought: How about equipping a repo's metadata with some sort of expiration/best before date, which yum etc. could use to warn users? If we had something like this, system-auto-death etc. would become superfluous. it would mean we'd have to be able/willing to push new metadata out to the base repo so that the repo could be used at all for future installs. Not necessarily - Yum could simply issue a warning and continue to work, yum could have a --disable-expiration-warnings option, ... There are many possibilities Rather than push the issue onto the user, I don't think this is pushing the issue onto the user. I'd consider this to be warning them about you might be doing something unwise. I think the right solution would be for the fedora repo definition to have an option updated_by=updates that causes yum not to check its expiration when the updates repo is also enabled. Yes, this would also be an alternative, except that one also would have to take users into account who run plain DVD Fedora w/o updates and use-cases which run entirely off-line. I was referring to the issue Seth raised where using the fedora repo would produce an expiration warning that is bogus (i.e., the user is not at risk) provided that the updates repo is also enabled. That can and should be solved on our end. Showing the warning to users who don't use the updates repo is correct behavior, though we could separately have an option for the user to hide the warning if they already know about it and find it annoying. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding packages to buildroot directly from updates-testing
On Thu, 2010-12-16 at 18:11 +0100, Ralf Corsepius wrote: On 12/16/2010 06:00 PM, Matt McCutchen wrote: On Thu, 2010-12-16 at 17:49 +0100, Ralf Corsepius wrote: On 12/16/2010 05:28 PM, Kevin Fenzi wrote: On Thu, 16 Dec 2010 10:03:30 -0600 Chris Adamscmad...@hiwaay.net wrote: Once upon a time, Stanislav Ochotnickysochotni...@redhat.com said: Note that I am not saying things should go into buildroot as soon as they are built, but as soon as they are in updates-testing. There is a difference. There will still be reasons to use tags/overrides. That makes the push process much more fragile/difficult. If you use a updates-testing build of package A, and package B (that depends on package A) gets rebuilt, then you may have a package B that can't be pushed to stable until package A gets pushed. What if there's a security update on package B that needs to go to stable ASAP? Additionally, what if package A is built, after a few days serious problems are found in it and it's deleted until the maintainer can sort them out. What happens to packages B, C, D, and E that built against this version? They will have broken deps. How would this scenario be different from what we have now? As it works now, if the problem is found before A goes to stable (and we hope the testing process would find it), the build (or all of the builds in the custom tag) can just be untagged. The fallout is nicely contained. Hmm, are we talking about rawhide or release? As far as I understand, we are talking about releases ther updates-testing, where package A would land in testing in both cases. The detail which is not clear to me: What does the current buildroot contain? Does it comprise the packages in updates-testing? dist-f14-build, which consists of updates + buildroot overrides + the same inherited from previous distribution versions. You can see the details here: http://koji.fedoraproject.org/koji/search?terms=dist-f14-buildtype=tagmatch=exact (BTW, it seems that a custom tag would generally be better than a buildroot override for the reasons we are discussing even if there's only one dependent package, unless that would put some kind of strain on the infrastructure. Is a request for a custom tag more work than a buildroot override request for the releng team?) If no, then we currently are at risk of building packages depending on A against the supposed to replaced versions in release/updates, i.e. we are at risk of producing silently broken packages. But this is no different from the case of a package C built against the old A before the new A came into existence. In most cases in which a new A makes it to stable, it will be backward-compatible with packages built against the old A. If it is not, all dependent packages need to be rebuilt at some point. But if B happens to be rebuilt for some other reason while the new A is in testing, performing that build against the old A is no different from declining to rebuild C against the new A at that time. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On Thu, 2010-12-16 at 20:16 +0100, Miloslav Trmač wrote: Casey Dahlin píše v Čt 16. 12. 2010 v 11:19 -0500: On Thu, Dec 16, 2010 at 12:27:34PM +, Richard W.M. Jones wrote: What you don't understand is that you are throwing away the experience and knowledge of thousands of Unix system administrators. Almost of all of them do not even read this mailing list. Rich. I hate this argument. The experience and knowledge claim applies to everything we could possibly change. Change.\nIs.\nGoing.\nTo.\nHappen. That's a too black-and-white view. Of course there is and will be change - what would we all be doing here if there were nothing to change, after all? The thing that needs to be appreciate is that every change has _costs_ on the user-base. [...] So, yes, change is going to happen, and some change is clearly good. But when there are 10 programmers on a project and 100,000 users, each change has to be _very obviously_ good, or it might be better avoided. Especially minor changes that don't bring any measurable benefit (perhaps making the system cleaner or making programmer's life more convenient) but require time from each user to adapt are better abandoned than implemented. Looking at real costs and benefits is the right approach. But do not overlook potential benefits of making it practical to add features that will help the sysadmins or avoiding a security issue later that the sysadmins would otherwise have to scramble to fix (maybe not applicable to /dev/shm, but in general). -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding packages to buildroot directly from updates-testing
On Thu, 2010-12-16 at 12:14 -0800, Jesse Keating wrote: On 12/16/10 10:29 AM, Matt McCutchen wrote: (BTW, it seems that a custom tag would generally be better than a buildroot override for the reasons we are discussing even if there's only one dependent package, unless that would put some kind of strain on the infrastructure. Is a request for a custom tag more work than a buildroot override request for the releng team?) A custom tag would slow things down considerably. When doing a buildroot override, the newRepo task can take the pre-existing repodata into account when calling createrepo and be done fairly quickly (a few minutes of actual createrepo time). A new custom tag would require creating fresh repodata from scratch which can take an hour or more of actual createrepo time. I assume you're referring to createrepo --update? How hard would it be to seed the new tag with the repodata of one of the tags it inherits? An alternative approach would be to mirror the semantics of tag inheritance by having builds use multiple yum repositories, possibly with priorities, instead of explicitly computing the resulting repodata for every tag. Would that be feasible? -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding packages to buildroot directly from updates-testing
On Thu, 2010-12-16 at 12:28 -0800, Jesse Keating wrote: On 12/16/10 12:22 PM, Matt McCutchen wrote: An alternative approach would be to mirror the semantics of tag inheritance by having builds use multiple yum repositories, possibly with priorities, instead of explicitly computing the resulting repodata for every tag. Would that be feasible? Again it would take code, and quite a bit of logic to figure out what packages are blocked in various tags to make sure the repo config files used exclude the right packages, etc... How about shipping the block list in the repository metadata and modifying yum-plugin-priorities to read it and insert the blocks into the priority dictionary just like packages? I think that would give the right semantics. (I'm not prepared to contribute now. I'm just having fun speculating and hoping that if we reach a solution that is easy enough to be worthwhile, someone will implement it. Is there a better list for this discussion?) -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Changes to the Packaging Guidelines
On Wed, 2010-12-15 at 16:15 -0500, Jon Masters wrote: On Wed, 2010-12-15 at 22:25 +0200, Ville Skyttä wrote: Files marked as documentation must not cause additional dependencies that aren't satisfied by the package itself or its dependency chain as it would be if none of its files marked as documentation were included in the package. Doesn't this exclude things like man pages, since they need a man page formatter to display them that would not be required were those docs not included in a package? No, because rpm does not generate a dependency on man for packages that contain man pages. I guess the idea is that unlike a script which the user invokes directly and expects to work, a man page is read by invoking man, and it will be obvious to the user if man is missing and needs to be installed. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Safest way to go from x86 to x86_64
On Tue, 2010-12-14 at 14:07 +, Paul Johnson wrote: Hi, My main box decided to snuff it last week (motherboard and processor decided to fry). My erstwhile friend in the computer shop I use has said that he has a nice 64 bit processor and motherboard going for a small amount of money. The problem I have is that if I go the 64 bit route then I'll need to install the 64 bit OS (I can stay 32 bit, but what's the point with 8Gb of memory). Is there a safe way to install the x86_64 system over the 32 bit version and then clean off the 32 bit stuff that is no longer needed? I did that to my Fedora 11 system in October 2009. It took a significant amount of manual work and scripting and I hit a number of minor issues. I'm not sure I would call the procedure safe, but it did work. The procedure was like this: - Change /etc/rpm/platform to x86_64-redhat-linux and put %_transaction_color 3 in /etc/rpm/macros . - Install the x86_64 kernel and boot to it. - Install the x86_64 version of rpm. - Construct a yum script with install lines for the x86_64 versions of all installed packages. Repeatedly try to run the script and add erase lines for any i?86 packages that cause file conflicts until it succeeds. - Watch the output. When scriptlets fail, fix things manually. - Remove all unneeded i?86 packages. I needed to keep a few proprietary packages that are only available for i?86, so I used a script to walk the dependencies and figure out which i?86 packages could be removed. YMMV with rawhide. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
On Fri, 2010-12-10 at 15:06 +, Daniel P. Berrange wrote: Adding CLONE_NEWPID would be worthwhile to stop the mock process seeing any other PIDs on the machine. It's critical, or mock could ptrace some process running as root on the host and inject arbitrary code. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Firewall
On Mon, 2010-12-06 at 10:54 +0100, Michał Piotrowski wrote: On most desktop systems firewall is not needed. Many users do not even know how to configure it. In fact I disable it in most of my systems, because there is no real use for it. So I asked a simple question whether there is a need to install iptables by default? Your answer is not satisfactory for me - because not configured firewall has nothing to do with security. In fact, it can only bring false sense of security. I believe the default is to block incoming connections except for a few services. This is good if you are running a sloppily written single-user server that binds to the wildcard address. The Haskell Scion server fell in this category as of August 2009; I didn't look to see what a remote user might be able to do to me by connecting to it. Yes, the proper way to avoid problems is to bind to localhost, but the firewall can be nice. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)
On Tue, 2010-12-07 at 00:38 +0100, Michał Piotrowski wrote: Cron - but should be activated only when cron files exist It seems to me that the list: - ssh - Dbus - syslog - iptables - ip6tables - auditd - restorecond is an absolute minimum to get working system. I don't agree that ssh is required for a working system. A desktop user may never ssh to his/her own machine. (Whether to enable ssh by default is a different question.) -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)
On Tue, 2010-12-07 at 01:07 +0100, Michał Piotrowski wrote: 2010/12/7 Matt McCutchen m...@mattmccutchen.net: On Tue, 2010-12-07 at 00:38 +0100, Michał Piotrowski wrote: Cron - but should be activated only when cron files exist It seems to me that the list: - ssh - Dbus - syslog - iptables - ip6tables - auditd - restorecond is an absolute minimum to get working system. I don't agree that ssh is required for a working system. It's required for all systems without display device That is, some servers. It needs to be easy to enable sshd when installing a server, but I don't see a reason to have it enabled by default on desktops. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)
On Mon, 2010-12-06 at 17:57 -0800, Adam Williamson wrote: On Mon, 2010-12-06 at 10:54 +0100, Michał Piotrowski wrote: There are no stupid questions :) On most desktop systems firewall is not needed. Many users do not even know how to configure it. In fact I disable it in most of my systems, because there is no real use for it. So I asked a simple question whether there is a need to install iptables by default? On most laptops, however, which are the most common types of system sold today, a firewall is very definitely needed when you're connecting to hotel networks, public wifi access points... We're trying to get beyond that conventional wisdom and look at what services might actually get unintentionally exposed in the absence of a firewall and whether there is some other solution (e.g., don't enable them by default, or bind to localhost). https://lists.fedoraproject.org/pipermail/devel/2010-December/146758.html -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: old_testing_critpath notifications
On Wed, 2010-12-01 at 14:17 -0800, Adam Williamson wrote: [...] I think we need to be careful of the mindset that says 'we can't enforce any standards in Fedora because it's a volunteer project so we must just accept what people are willing to give us'. Even though packaging in Fedora is a volunteer process, we still have fairly rigorous packaging guidelines and a review process. We don't just accept any package someone turns up and submits. i.e., we're enforcing standards of quality, despite this being an entirely volunteer effort and no-one being compelled to show up and provide packages of a particular quality. The concept of having a policy requiring updates to be tested before they're issued is really no different. Correct in the sense that Fedora has the authority to impose both policies. The costs and benefits of each policy are still open for debate. I do think that for update testing to work well going forward we need to engage more groups with it and make it clear it's not something that some separate QA group is just going to do for everyone and no-one has to worry about it. That's easy to say. The fact remains that if no one feels they have a sufficient incentive to do the work of testing an update for a particular Fedora version, it simply won't get tested. When software is packaged it's reasonable to expect that someone, somewhere, uses it; if they don't, it probably shouldn't be packaged. We need to find those people and engage them in the testing process, and it seems to me that the maintainers of packages are as well placed as anyone to help find and engage their users in this process. The argument sounds reasonable on its face, but apparently some (many?) maintainers don't agree. Pestering them does not seem to be helpful. We have the option to take away their ownership of the package, potentially resulting in it getting dropped from the distribution if another maintainer can't be found, but again we have to ask whether the benefits outweigh the costs. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Proven tester signup process
On Wed, 2010-12-01 at 15:59 -0800, Adam Williamson wrote: I'm not sure I'd want to go quite that far unless the sign-up process can wave the proven testers instructions in your face quite prominently. They're short and easy to read and understand, but you can't infer them from first principles: we do want to have people read the proven tester instructions before becoming proven testers. That's actually the *only* requirement to become a proven tester. :) Would it be appropriate to allow anyone to become a proven tester just by confirming they have read the instructions? I'm an interested user and very minor contributor, not a packager, and I have been using updates-testing since April. I was turned off by the approval process, but I would probably sign up if it were automatic. Then again, I'm not using SELinux and don't wish to enable it at this time, so maybe you don't want me leaving +1s. One issue: as a proven tester, I would lose the ability to leave non-proven-tester karma if I only have interest in testing a package to lower standards. (It makes me wonder what the standards for non-proven-tester karma are assumed to be. Is proven-testership the EV of karma? Heh.) -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GCC bug 634757 F14 rebuild status
On Wed, 2010-12-01 at 20:29 -0600, Dennis Gilmore wrote: libgnome-java failed to build http://koji.fedoraproject.org/koji/taskinfo?taskID=2638084 I took a look out of curiosity, and this appears to be an intermittent problem that occurs when two instances of install(1) try to write to the same file at the same time: /usr/bin/install -c -m 644 'doc/examples/runExample.sh' '/builddir/build/BUILDROOT/libgnome-java-2.12.7-2.fc14.1.i386/usr/share/doc/libgnome-java-2.12.7/examples/runExample.sh' /usr/bin/install -c 'doc/examples/runExample.sh' '/builddir/build/BUILDROOT/libgnome-java-2.12.7-2.fc14.1.i386/usr/share/doc/libgnome-java-2.12.7/examples/runExample.sh' ... /usr/bin/install: cannot create regular file `/builddir/build/BUILDROOT/libgnome-java-2.12.7-2.fc14.1.i386/usr/share/doc/libgnome-java-2.12.7/examples/runExample.sh': File exists Indeed: $ install -c -m 644 foo bar install -c foo bar [1] 29565 [1]+ Doneinstall -c -m 644 foo bar $ install -c -m 644 foo bar install -c foo bar [1] 29567 [1]+ Doneinstall -c -m 644 foo bar $ install -c -m 644 foo bar install -c foo bar [1] 29569 install: cannot create regular file `bar': File exists [1]+ Exit 1 install -c -m 644 foo bar $ install -c -m 644 foo bar install -c foo bar [1] 29571 [1]+ Doneinstall -c -m 644 foo bar $ install -c -m 644 foo bar install -c foo bar [1] 29573 install: cannot create regular file `bar': File exists [1]+ Doneinstall -c -m 644 foo bar $ install -c -m 644 foo bar install -c foo bar [1] 29575 install: cannot create regular file `bar': File exists [1]+ Doneinstall -c -m 644 foo bar When this succeeds, the permissions are unpredictably 644 or 755. The solution: patch the package to not do that, or just try again and hope you get lucky. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: memcpy overlap: quickly detect, diagnose, work around
On Sun, 2010-11-28 at 15:13 -0800, John Reiser wrote:
This patch (with .rpms for x86_64 and i686) enables glibc optionally
to detect, diagnose, and work around overlap in memcpy/mempcpy:
http://bitwagon.com/glibc-memlap/glibc-memlap.html
What is the mass addition of commented curly braces for? It is
distracting from the substance of the patch.
diff --git a/sysdeps/x86_64/multiarch/strcmp.S
b/sysdeps/x86_64/multiarch/strcmp.S
index 1859289..e014283 100644
--- a/sysdeps/x86_64/multiarch/strcmp.S
+++ b/sysdeps/x86_64/multiarch/strcmp.S
@@ -21,7 +21,7 @@
#include sysdep.h
#include init-arch.h
-#ifdef USE_AS_STRNCMP
+#ifdef USE_AS_STRNCMP /*{*/
/* Since the counter, %r11, is unsigned, we branch to strcmp_exitz
if the new counter the old one or is 0. */
# define UPDATE_STRNCMP_COUNTER\
(etc.)
--
Matt
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: memcpy overlap: quickly detect, diagnose, work around
On Mon, 2010-11-29 at 16:08 -0800, John Reiser wrote: On 11/29/2010 03:44 PM, Matt McCutchen wrote: What is the mass addition of commented curly braces for? It is distracting from the substance of the patch. Those comments enable parenthesis matching in some text editors. The scoping of conditional compilation in sysdeps/x86_64/multiarch/strcmp.S was complicated enough that I needed help figuring it out. Indeed, it was complicated enough to help conceal a bug. I see. Still, you could split the patch into one that just adds commented curly braces to existing code and a second with the substantive changes, which would be easier for anyone interested to review. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2010-11-17)
On Sat, 2010-11-20 at 23:09 +0100, Jan Kratochvil wrote: Oh, I forgot, Fedora no longer delivers the fix in a day but ... even not in a week. Because I usually create new build during the updates-testing week so the days start to count again. https://admin.fedoraproject.org/updates/gdb-7.2-7.fc14 Date Submitted: 2010-09-22 This update has been obsoleted by gdb-7.2-12.fc14 https://admin.fedoraproject.org/updates/gdb-7.2-12.fc14 Date Submitted: 2010-09-25 This update has been obsoleted by gdb-7.2-15.fc14 https://admin.fedoraproject.org/updates/gdb-7.2-15.fc14 Date Submitted: 2010-09-27 This update has been obsoleted by gdb-7.2-16.fc14 https://admin.fedoraproject.org/updates/gdb-7.2-16.fc14 Date Submitted: 2010-09-28 2010-10-05 13:15:39 This update has been pushed to stable So it is not 7 days but 13 days in this case. One has to give up on backporting new fixes to ever get any delivered. That's not true. You can continue committing fixes and running builds in Koji; just don't submit another update until the first one goes to stable. This is analogous to the Fedora release cycle, in which in order to get one release out with sufficient testing, some fixes are deferred to the next release. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Wed, 2010-11-17 at 16:32 +, Jóhann B. Guðmundsson wrote: Dont we have an upstream mantra to uphold... Forward all Fedora users and otherwize that experience this to Adobe.. If we are going hack around this on our side where are we going to draw the line.. Are we planning to start hacking around every ill written code out there? Hopefully not; this is a particularly high-visibility issue. Looking at https://fedoraproject.org/wiki/Objectives and related pages, Fedora has to weigh the desire for things to just work for the envisioned user base against the desire not to do something technically inferior to accommodate non-free software. I'm happy to let FESCo decide this. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Sun, 2010-11-14 at 14:07 -0500, Matt McCutchen wrote: On Sun, 2010-11-14 at 10:38 -0800, John Reiser wrote: On 11/13/2010 03:41 PM, Richard W.M. Jones wrote: Anyway, I think LVM is jolly useful: [stated advantages snipped] One design error is that you cannot carve out an ordinary partition from an LVM. Once a portion of the drive is LVM, then that portion of the drive is LVM forever until the LVM is completely gone. That's not true. You can shrink the PV with pvresize and then create any desired partitions in the resulting space. Oops, that's not completely true: pvresize currently is not smart enough to move allocated data out of the area to be freed, according to its man page. But you have other options, e.g., you can attach another disk, create a PV on it, move the data there, rearrange the first disk as desired, and move the data back, all while the system is running. That's what's so fun about LVM. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans (LVM issues)
On Sun, 2010-11-14 at 13:07 -0800, John Reiser wrote: When I created 14 partitions using a DOS partition label (3 primaries, plus extended containing 10 logical partitions) and gave 6 of the partitions to an LVM setup, then I could not remove one of the partitions from the clutches of the LVM, and use the removed partition for some other purpose (keeping the rest of the LVM going), unless I removed all the LVM from that drive. vgreduce + pvremove? Did something go wrong when you tried? -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken
On Sat, 2010-11-13 at 14:22 +, Matthew Garrett wrote: On Sat, Nov 13, 2010 at 10:21:30AM +0100, Till Maas wrote: The documented issues do not seem to be as bad as a system being exploited. It is only about dependency breakage or services not working anymore. There is no major data corruption requiring access to backups and restoring the whole system. But this is what people using Fedora with proftpd and being exploited have to do. If security updates break functionality then people will stop applying security updates. That may be true in general, but I think Till has given a compelling example in which many (most?) users would prefer an update with some probability of being broken to no update. If necessary, we could have a separate repository of urgent updates that sysadmins could choose to enable or not based on their security and stability needs. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On Thu, 2010-11-04 at 19:44 +0100, Nicolas Mailhot wrote: From a practical point of view, as a bug reporter, when I get mass notifications to update scores of bugs that were opened years ago, and that the people owning the component never bothered to respond on (even to confirm they were alive), I just /dev/null the result and never look at it again. Sometimes people ask me why I let bugs get autoclosed when they hit the same problems months later, but really, I don't see the point of spending hours to re-test reports, when no one could spend minutes to ask for (human) confirmation. I think that is fine. It's not your responsibility to retest a bug you no longer care about. If someone else cares and retests, they ideally would be able to reopen it, but Bugzilla currently doesn't allow that ( https://bugzilla.redhat.com/show_bug.cgi?id=573535 ). If no one cares, the bug may not be worth fixing. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Marking zapped bugs
On Thu, 2010-11-04 at 09:38 -0700, Adam Williamson wrote: The practical point is that F12 is about to go EOL which means the bug must be closed... Why? Obviously it needs to be clear that nothing further should be expected from the maintainer unless/until the version is bumped. But the project can choose to indicate that by closing the bugs as WONTFIX or some other way, e.g., another resolution or by customizing Bugzilla to show a notice on bugs that are open against an EOL version of Fedora. Personally, I dislike the use of WONTFIX because philosophically I think it doesn't fit, and practically it makes zapped bugs impossible to distinguish from real WONTFIX bugs in searches (https://bugzilla.redhat.com/show_bug.cgi?id=528319). -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default partitioning
On Sat, 2010-10-30 at 14:03 -0800, Javier Prats wrote: Where is this info kept on the install image and how would I go about modifying it locally to start playing? I'd like to learn whether some one else does this or not. It's in anaconda. The / and /home specifications are here (line numbers may rot): http://git.fedorahosted.org/git/?p=anaconda.git;a=blob;f=pyanaconda/installclass.py#l169 The requiredSpace is checked here: http://git.fedorahosted.org/git/?p=anaconda.git;a=blob;f=pyanaconda/storage/partitioning.py#l147 You would have to modify the python files and then either rebuild anaconda or create an updates image. See: https://fedoraproject.org/wiki/Anaconda -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
On Thu, 2010-10-14 at 13:11 +0200, Thorsten Leemhuis wrote:
I tend to disagree, as including both Iceweasel and Icedove in addition
to Firefox and Thunderbird gives users, admins and especially those that
maintain a remix the option to easily chose the solution that suites
their needs best.
FWIW, there is precedent in {fedora,generic}-{release,logos,...}.
--
Matt
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2010-10-05)
On Wed, 2010-10-13 at 23:45 +0200, Kevin Kofler wrote: Firefox is NOT an essential package, the GNOME spin could just ship Epiphany (GNOME's default browser) instead, and other desktop spins ALREADY ship the respective desktop's default instead of Firefox! Epiphany is still not serious about security: https://bugzilla.redhat.com/show_bug.cgi?id=643224 Until this changes, I definitely won't use it. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging dwm
On Thu, 2010-10-14 at 01:48 +0200, Kevin Kofler wrote: Petr Sabata wrote: I've been thinking about packaging dwm [1] since we already ship dmenu and dzen2. I wonder if anybody would be interested in this fine window manager (except for me). I think it's completely unreasonable to package that software, because of this: The problem here: dwm is configured solely in C and has to be recompiled every time a user wants to change their settings (appearance, behavior, shortcuts, etc). In my opinion, we could do it like this: - install a Fedora preconfigured version along with dwm sources - copy its configuration (C header file) to some fixed location for user to customize - provide a script to recompile dwm locally using the local configuration file Such a program is basically not packagable. It can't be packaged in the sense of shipping binaries. But if a wrapper script is provided that automatically recompiles dwm for the individual user whenever necessary, the software could be packaged in the sense that it could be installed and updated with yum and would be functional without user intervention. The latter is my definition of packageable. Compare to the akmods offered by RPM Fusion. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ethtool not in default system anymore?
On Tue, 2010-10-12 at 19:37 -0400, Gregory Maxwell wrote: On Tue, Oct 12, 2010 at 7:28 PM, Chris Adams cmad...@hiwaay.net wrote: I noticed that ethtool is not in the default install anymore [...] mii-tool. The mii-tool man page claims it is deprecated in favor of ethtool. In fact, neither is in any comps groups: # yum info-groups ethtool net-tools ... Installed Packages -- Unknown -- 2 (100%) 2:ethtool-2.6.33-0.1.fc13.x86_64 net-tools-1.60-103.fc13.x86_64 Available Packages -- Unknown -- 3 (100%) 2:ethtool-2.6.33-0.1.fc13.x86_64 net-tools-1.60-102.fc13.x86_64 net-tools-1.60-103.fc13.x86_64 -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: docbook and glibc breakage [STILL BREAKING EVERYTHING]
On Mon, 2010-10-04 at 04:30 -0500, Rex Dieter wrote: I've tagged docbook-utils-0.6.14-25.fc14 (the update reportedly fixing this) for the buildroot. Please try your builds now. f14-build should appear in the Tags line here, right? https://koji.fedoraproject.org/koji/buildinfo?buildID=197223 I don't see it. Am I missing something? -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging Request: sigil
On Fri, 2010-10-01 at 08:13 +0530, A. Mani wrote: sigil is not available from yum http://code.google.com/p/sigil/ It is easy to install from source on F You can add it here: https://fedoraproject.org/wiki/PackageMaintainers/WishList -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: koji.TagError
On Fri, 2010-09-24 at 14:48 -0430, Guillermo Gómez wrote: Why is this happening? rubygem-state_machine-0.9.4-3.fc12 unsuccessfully untagged from dist-f12-updates-testing-pending by bodhi Operation failed with the error: koji.TagError: build rubygem-state_machine-0.9.4-3.fc12 not in tag dist-f12-updates-testing-pending Is it something i can fix? (action?) See: Guillermo http://www.neotechgw.com http://gomix.fedora-ve.org -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: koji.TagError
On Fri, 2010-09-24 at 16:50 -0400, Matt McCutchen wrote: On Fri, 2010-09-24 at 14:48 -0430, Guillermo Gómez wrote: Why is this happening? rubygem-state_machine-0.9.4-3.fc12 unsuccessfully untagged from dist-f12-updates-testing-pending by bodhi Operation failed with the error: koji.TagError: build rubygem-state_machine-0.9.4-3.fc12 not in tag dist-f12-updates-testing-pending Is it something i can fix? (action?) See: Oops. Somehow I hit Send instead of Paste. https://lists.fedoraproject.org/pipermail/test/2010-September/094041.html -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -static packages
On Thu, 2010-09-16 at 17:19 +0100, Richard W.M. Jones wrote: There are times when static linking is a useful. Robert clearly describes one in his original post. Only because we do not (yet) have a good per-user package manager to make installing the required dynamic libraries, or assembling a bundle containing them, comparably easy. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -static packages
On Wed, 2010-09-15 at 17:06 +0100, Robert Spanton wrote: I've recently had to link a fair amount of my work statically so that it'll run on a cluster of RHEL machines. Unfortunately, I am just a user of these machines, and so I don't have the power to get them to run Fedora or even to get the admins to install RHEL packages in a timely manner. Building statically also helps me to eliminate as many of the inevitable fractional differences between cluster nodes as possible, to achieve reproducible results from simulation runs. However, only a few packages in Fedora provide -static variants. This has meant that I've had to locally build these, which is obviously not desirable from a maintenance perspective. So, would be acceptable to register requests for -static package variants as tickets on bugzilla? Or is there a better way to try to encourage people to generate these packages? I think the answer is no: Fedora wishes to discourage static linking. You can continue to build your own -static packages, or you can install the libraries you need manually in your home directory (which probabably isn't any easier, but gives you the other benefits of dynamic linking), or you could set up a QEMU or User Mode Linux VM and install whatever you like. Ideally, we would have a packaging tool that works for per-user software collections as well as the system. That's something I plan to work on in the next few years. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Inspecting/debugging a mock build
On Sun, 2010-09-05 at 23:57 -0400, Braden McDaniel wrote:
Thanks. Now, how do I get fedpkg to preserve it? I see (when doing
fedpkg mockbuild):
INFO: Cleaning up build root ('clean_on_failure=True')
So, where do I set clean_on_failure to False?
In /etc/mock/site-defaults.cfg or the file for the root configuration
you're using. The option is actually called cleanup_on_failure; the
message is wrong.
--
Matt
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Voting in bugzilla
On Thu, 2010-09-02 at 09:17 -0600, Kevin Fenzi wrote: On Thu, 2 Sep 2010 12:18:26 +0300 (EEST) Juha Tuomala juha.tuom...@iki.fi wrote: Has it been disabled recently? Short answer: Yes. It has. Longer answer: FESCo looked at trying to use voting data to give us an idea on 'hot' bugs that we might be able to send more resources to fix. Sadly, voting isn't at all good for this, as people have many votes (100 or 1000, I forget which), It was 100. so it's hard to tell if an issue affects 10 people or 100 by that. If you simply want to know the number of people affected, Bugzilla can be configured to allow one vote per bug up to some large number of bugs. The Mozilla Core product is set up this way. See, for example, my votes: https://bugzilla.mozilla.org/votes.cgi?action=show_useruser_id=316870 But it's worth discussing whether that is the best model for Fedora. Letting each user distribute 100 votes over a set of bugs is also reasonable. If a bug affects 100 people but they did not see fit to give it many total votes, maybe it is not that important. Many people didn't see the voting interface, so they wouldn't have used it even if the problem was severe or affected a lot of people. Some people were using the voting interface, even though no maintainers ever noticed it (ie, thinking this could help the bug get solved, but it's like the maintainer and voter were in seperate worlds without any communication). So, we decided it would be less confusing to just disable it. We decided to look into using CC or comments to tell when a bug had a lot of people affected or was 'very active'. Unfortunately, this also is proving to be difficult to implement. See: https://fedorahosted.org/fedora-engineering-services/ticket/24 any help there would be appreciated. Please take care not to create an incentive for people to add me too comments, since that will annoy everyone. And a CC doesn't always indicate a desire to have the bug fixed. Google Code currently conflates CC with voting, and there is a bug to separate the two concepts (https://code.google.com/p/support/issues/detail?id=1108). The best solution may be to reenable the Bugzilla voting feature but configure and publicize it properly. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg prep
On Wed, 2010-09-01 at 14:20 +0200, Nils Philippsen wrote: On Tue, 2010-08-31 at 20:47 -0400, Matt McCutchen wrote: On Tue, 2010-08-31 at 17:36 -0700, Roland McGrath wrote: Perhaps local and so forth could be given a --dist=foo switch, and these sorts of errors could say can't figure out your dist from git, use --dist or fix your repo. Or a branch file... :D Please don't, a file in the repo which needs to be different between branches would break merging between branches (which is one thing that makes dist-git so much better than dist-cvs). No... the three-way merge in any decent version control system will propagate changes from one branch to another without messing up pre-existing differences between the branches. That's why it's called merge and not copy. If you want the branches to be identical, you could leave the branch file untracked or just use a different method of specifying the distribution version. I propose that fedpkg should consider a --dist option, a branch file, and the name of the current git branch in that order. I personally don't like fedpkg doing magic based on the name of the VCS branch I am on and would use a branch file. I don't see what the big deal is about having the branches identical; I think seeing the difference in the dist value could actually be a helpful reminder. (Yes, I should have stated this earlier, in the Question regarding dist-git aesthetics with branches thread.) -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg prep
On Wed, 2010-09-01 at 10:06 -0700, Jesse Keating wrote: On 9/1/10 9:01 AM, Garrett Holmstrom wrote: Andreas Schwab wrote: Matt McCutchen m...@mattmccutchen.net writes: I propose that fedpkg should consider a --dist option, a branch file, and the name of the current git branch in that order. Or make it a branch config (eg. git config branch.$branch.dist f14). This, please. Using magical branch names or files to decide what release a branch corresponds to seems silly when it can be a property of the branch itself. We essentially do this now. We look at the branch merge point, which tells me what upstream Fedora/RHEL branch you're tracking, which tells me how to set the macros. It's only when you aren't tracking a remote branch that things go south. Does it work if the current branch tracks another local branch which tracks an upstream branch? It looks to me that the code does not handle that, but I haven't found a good way to test it. And if I want to set up a local branch for the purpose of rebuilding a package for a different Fedora version (e.g., systemd on F13), I am out of luck. A branch file in the versioned content would Just Work in the first case and provide a solution for the second case. Magic inspection of the branch relationships is not a substitute for real configuration. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg prep
On Wed, 2010-09-01 at 11:01 -0500, Garrett Holmstrom wrote: Andreas Schwab wrote: Matt McCutchen m...@mattmccutchen.net writes: I propose that fedpkg should consider a --dist option, a branch file, and the name of the current git branch in that order. Or make it a branch config (eg. git config branch.$branch.dist f14). This, please. Using magical branch names or files to decide what release a branch corresponds to seems silly when it can be a property of the branch itself. Taking the dist value from the branch name is magical in the sense that it imposes a new interpretation on an existing datum. Taking it from a file in the working tree designated for that specific purpose (which I suppose should really be named dist, not branch) is not. I believe taking it from the git configuration file is an abuse of the git configuration file, as I said in reply to Tom. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Mon, 2010-08-30 at 22:08 -0700, Jesse Keating wrote: Developers put new features in rawhide knowing that they will be in the next release of Fedora, which would be at the /most/ 6 months from the time they drop the feature. It's more like 9 months. A feature has to wait until the next branching of a Fedora version from rawhide, and then for that Fedora version to be released. For example, a feature that landed in rawhide on 2010-02-19, just after F13 was branched, would end up in F14 on 2010-11-02. Your point is still taken. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proprietary search engines
On Tue, 2010-08-31 at 08:19 -0400, Matthew Miller wrote: Fedora gets to build and ship a slightly-modified version of Firefox while retaining the Firefox name due to a distribution partner agreement with Mozilla. Mozilla gets their money from Google. I don't think we *can* make it something else -- it's part of the price we are paying in order to use the non-Free name. See: https://wiki.mozilla.org/Firefox_Rebranding:Worksheet#Start_page Good catch. More fallout of the Mozilla trademarks... (Am I starting to sound like Kevin?) -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proprietary search engines
On Tue, 2010-08-31 at 08:27 -0700, Adam Williamson wrote: It doesn't seem to be an unavoidable requirement, it says: If you proposed Start/Home Page is not similar to the existing Firefox Start Page, please be prepared to provide a rationale for the change, and how it would benefit the end-user. I think we could manage such a rationale. We can definitely make a rationale for having a bunch of Fedora resources on the start page, but our rationale for omitting a Google search box, it's redundant and promotes a proprietary service, is not a line of reasoning I would expect Mozilla to accept. Then again, they may calculate that they are better off compromising on this issue in order to keep Fedora using their trademarks. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proprietary search engines
On Tue, 2010-08-31 at 16:30 -0500, Bruno Wolff III wrote: On Tue, Aug 31, 2010 at 17:20:23 -0400, Al Dunsmuir al.dunsm...@sympatico.ca wrote: Please do not ignore that the browser is there for the user to use, not for Fedora to stream information in spite of the user's wishes. Nor for Mozilla to track its users. There shouldn't be a start page at all as it opens a connection back to the start page server before you (easily) have a chance to disable it. It is especially annoying that that after updates you still get some Mozilla update page (that at fisrt glance appears to be from a remote server, though maybe there is some trickery going on) even though the start page is disabled. The update page is remote. If you want to disable it, set startup.homepage_override_url to the empty string. There is also startup.homepage_welcome_url for the first run of the browser. I'm not commenting on what the default should be. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Creating a rawhide/f15 private kernel branch
On Tue, 2010-08-31 at 22:14 -0400, Steve Dickson wrote: When I do a: git push --dry-run origin origin/master:refs/heads/f15/user/steved/pnfs-f15 To ssh://ste...@pkgs.fedoraproject.org/kernel * [new branch] origin/master - f15/user/steved/pnfs-f15 which appears to do what I want.. but when I remove the --dry-run I get: $ git push origin origin/master:refs/heads/f15/user/steved/pnfs-f15Total 0 (delta 0), reused 0 (delta 0) remote: C refs/heads/f15/user/steved/pnfs-f15 steved DENIED by refs/heads/f[0-9][0-9] remote: error: hook declined to update refs/heads/f15/user/steved/pnfs-f15 To ssh://ste...@pkgs.fedoraproject.org/kernel ! [remote rejected] origin/master - f15/user/steved/pnfs-f15 (hook declined) error: failed to push some refs to 'ssh://ste...@pkgs.fedoraproject.org/kernel' Where is the pilot error? IIUC, the f15/ namespace will not exist until F15 is branched. You should just push to refs/heads/user/steved/pnfs-f15 . -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Proprietary search engines (was: Fedora Notifications System.)
On Sun, 2010-08-29 at 14:13 -0500, Mike McGrath wrote: On Sun, 29 Aug 2010, Manuel Escudero wrote: 3) We're already using a GOOGLE SEARCH BOX!! in http://start.fedoraproject.org/ ¿Do you have the code for this one? NO. And Fedora Project is using it. I'm sharing a Fedora Solution an applied search engine for the community. and I can add as many collaborators as I want, I can share my code, I can Modify it, it's more opensource that the one that we're already using... Just to make this clear on 3). We grandfathered that in, meaning it is now against policy to do more of it but we didn't remove it because it had historical significance. Though I believe we're in the works to replace the start page with something else. Interesting. I can understand not wanting to promote a proprietary search engine on the Fedora start page, but if the idea is that Fedora users and contributors should be able to avoid using them altogether, I think that's currently pretty unrealistic. People have questions all the time, and being able to search the whole web for an answer at once is great. Without a web search, one has to do a separate search of each data source (wiki, bug database, mailing lists) of each relevant project, assuming those search features even exist and that it is possible to identify all the relevant projects in advance (harder when searching for work to reuse). -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Search Engine Proposal
On Sun, 2010-08-29 at 15:07 -0500, Manuel Escudero wrote: AGAIN AND AGAIN AND AGAIN... http://start.fedoraproject.org/ is using a Google Search Box... YOU DON'T HAVE THE CODE TO PLAY WITH IT OR ANYTHING... With Fedora's engine I'm giving you the chance of having something more opensource Passing additional configuration to the Google search does not make the whole any more open source (or less). and also more specific and useful for the fedora users... I'll buy that. But there's no point in improving the Google search on http://start.fedoraproject.org if it is going to be replaced anyway with something that complies with the free software policy. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proprietary search engines
On Mon, 2010-08-30 at 02:46 +0530, Rahul Sundaram wrote: On 08/30/2010 01:01 AM, Matt McCutchen wrote: Interesting. I can understand not wanting to promote a proprietary search engine on the Fedora start page, but if the idea is that Fedora users and contributors should be able to avoid using them altogether, I think that's currently pretty unrealistic. I don't think there is any expectation for users. This is just a Fedora infrastructure policy so that we don't end up relying on things that we can't build upon or fork if necessary. So why would the policy apply to the search box on http://start.fedoraproject.org , which is just meant for users and is not really a piece of infrastructure? -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Wed, 2010-08-25 at 09:49 +0200, Kevin Kofler wrote: Matt McCutchen wrote: I think that's precisely the concern. In the event that F14 goes back to upstart, the final release will use a configuration that may not have received much testing. Don't Do That Then. :-) It's just another reason to stick with systemd. That's no answer. As for any feature, we need a contingency plan in case a problem is discovered that cannot be fixed in time. At least, I believe FESCo accepted the systemd feature with the understanding that it could be rolled back if necessary. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 1 more git problem
On Thu, 2010-08-26 at 15:16 -0400, Neal Becker wrote:
But, I hope this doesn't mean f12 is out of sync with f13, f14, master.
They should all be identical.
It looks like f12, f14, and rawhide are all the same, and f13 has one
extra commit:
$ git show-branch remotes/origin/{f12/,f13/,f14/,}master
! [remotes/origin/f12/master] Update to 1.6.3
! [remotes/origin/f13/master] Update to 1.6.3
! [remotes/origin/f14/master] Update to 1.6.3
! [remotes/origin/master] Update to 1.6.3
+ [remotes/origin/f13/master] Update to 1.6.3
[remotes/origin/f12/master] Update to 1.6.3
The difference in f13 is:
$ git diff refs/remotes/origin/{f12,f13}/master
diff --git a/mercurial.spec b/mercurial.spec
index 60e2588..9f3d1ce 100644
--- a/mercurial.spec
+++ b/mercurial.spec
@@ -151,13 +151,16 @@ rm -rf $RPM_BUILD_ROOT
%dir %{python_sitearch}/hgext
%files -n emacs-%{pkg}
+%defattr(-,root,root,-)
%{emacs_lispdir}/*.elc
%{emacs_startdir}/*.el
%files -n emacs-%{pkg}-el
+%defattr(-,root,root,-)
%{emacs_lispdir}/*.el
%files hgk -f %{name}-hgk.files
+%defattr(-,root,root,-)
%{_libexecdir}/mercurial/
%{_sysconfdir}/mercurial/hgrc.d/hgk.rc
If you didn't want the extra commit, you can revert it with git revert
after switching to the f13 branch.
--
Matt
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 1 more git problem
On Thu, 2010-08-26 at 15:56 -0400, Matt McCutchen wrote:
$ git show-branch remotes/origin/{f12/,f13/,f14/,}master
$ git diff refs/remotes/origin/{f12,f13}/master
To avoid any possible confusion: the inconsistency in the arguments I
used was just sloppy, it doesn't have a special meaning. git
automatically tries several common prefixes on its arguments (see the
git-rev-parse man page), so it doesn't matter whether the
remote-tracking branch names are written in full or without the leading
refs/ or refs/remotes/ .
Please pardon the noise.
--
Matt
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, 2010-08-24 at 10:23 -0700, Adam Williamson wrote: On Tue, 2010-08-24 at 12:14 -0500, Mike McGrath wrote: The intent is not to do so in the final release, AIUI. We're only keeping it around during pre-release, so that if we decide we need to fall back to upstart for final release, it's easy to do. As far as I know, the plan is to decide later (presumably after beta) which one we're going with, and dump the other. So the alpha and beta will be tested in a configuration that the final release will not? Hmm, I'd say 'not really, no' (unless we decide to fall back to upstart) I think that's precisely the concern. In the event that F14 goes back to upstart, the final release will use a configuration that may not have received much testing. If we want to claim that it's safe to switch back to upstart after beta, we need to be testing that configuration now, along with the systemd configuration. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, 2010-08-24 at 22:32 +0200, drago01 wrote: [...] In the event that F14 goes back to upstart, the final release will use a configuration that may not have received much testing. If we want to claim that it's safe to switch back to upstart after beta, we need to be testing that configuration now, along with the systemd configuration. Well that wouldn't be a systemd issue but a flaw in our feature process. We have Feature foo with rollback plan to go back to bar. We decide to revert foo due to bug X, Y and Z and we and up with foo after beta ... It is a potential problem with all features, but more so for replacing the init system because the stakes are higher and the amount of testing required is greater. The contingency plans on most of the feature pages seem to state only what the rolled-back configuration is, not how it will be tested. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does X run as root?
On Mon, 2010-08-23 at 13:16 -0400, Matthew Miller wrote: On Fri, Aug 20, 2010 at 09:24:42PM +0200, Till Maas wrote: On Thu, Aug 19, 2010 at 06:49:33PM +0100, Matthew Garrett wrote: I think run X as user Xorg if you're on KMS would be a fine F15Feature to aim for. Ubuntu's been working on it too: Of course, doing so just turns it from Running code as X gives you root to Running code as X gives you root the moment someone types in a root password, even if they're on a different terminal. I accept that This sounds like yet another good argument for removing the need to ever type a root password. How does this make it better? Then someone would spy on the user password of someone with sudo capabilities. If sudo is configured to give root access with the user password with no further restrictions, you're right. But it opens the doors to other possibilities, like requiring kerberos or key- or cert-based authentication for login. I know it's not feasible for most end-user desktops, but here we use two-factor authentication tokens for administrative access. More generally, the situation would be, Running code as X lets you read anything typed on any terminal. IMO, that's still pretty bad, and we can hardly claim success in reducing the privileges of X without fixing it. Users are going to be entering secrets of one kind or another on the keyboard for the foreseeable future. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum appmarket
On Mon, 2010-08-23 at 08:12 +0200, Kevin Kofler wrote: Roberto Ragusa wrote: Some more tags for functionally comparable to and the name of some well known programs for Windows or Macintosh would let people cope with the original names of Linux apps. Nero - k3b, xcdroast Adobe Illustrator - inkscape Adobe Reader - evince, kpdf, okular I think that would not fly for trademark reasons. I know there are sites which do that kind of mapping and that some upstream projects advertise their program as comparable with (popular proprietary program XYZ), but they're treading on a very fine line legally. I don't know where the law stands, but the current packaging guidelines prohibit this kind of comparison in package summaries: https://fedoraproject.org/wiki/Packaging:Guidelines#Trademarks_in_Summary_or_Description BAD: It is similar to Adobe Photoshop. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Get rid of file requires outside of the primary paths
On Thu, 2010-08-19 at 07:41 +0100, Richard W.M. Jones wrote: On Wed, Aug 18, 2010 at 07:29:35PM -0700, Matt McCutchen wrote: On Wed, 2010-08-18 at 22:43 +0100, Richard W.M. Jones wrote: On Wed, Aug 18, 2010 at 08:02:13AM -0400, seth vidal wrote: I am a libguestfs user and I'm complaining. It means I have to schlep down a bunch of extra info on every update of libguestfs and that sucks on my bandwidth. This is basically a hard problem to solve. We rely on copying files directly from the host into our appliance, so we rely on file dependencies. We could change it so we didn't need file dependencies, but that would cause silent breakage on updates. There are plenty of other kinds of breakage that cannot be caught by RPM dependencies. Why do you insist on using RPM dependencies to catch this kind, rather than testing and communication with the maintainers of the packages you depend on? So you're proposing that all maintainers of every dependent package should have to email me before they can move any file around? Either that, or you set up a nightly job to check that all the files are still where you expect them in updates-testing and, if not, get the offending update delayed until you can prepare a corresponding libguestfs update. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Get rid of file requires outside of the primary paths
On Wed, 2010-08-18 at 22:43 +0100, Richard W.M. Jones wrote: On Wed, Aug 18, 2010 at 08:02:13AM -0400, seth vidal wrote: I am a libguestfs user and I'm complaining. It means I have to schlep down a bunch of extra info on every update of libguestfs and that sucks on my bandwidth. This is basically a hard problem to solve. We rely on copying files directly from the host into our appliance, so we rely on file dependencies. We could change it so we didn't need file dependencies, but that would cause silent breakage on updates. There are plenty of other kinds of breakage that cannot be caught by RPM dependencies. Why do you insist on using RPM dependencies to catch this kind, rather than testing and communication with the maintainers of the packages you depend on? The benefit of catching a moved file at RPM install time rather than in testing has to be weighed against the cost for all your users to download the file list. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Javascript JIT in web browsers
On Tue, 2010-08-17 at 21:31 +0200, Kevin Kofler wrote: Adam Williamson wrote: Shipping a Firefox with no ability to use Javascript would be more or less equal to not shipping it, frankly. No-one would use the thing. What I suggest is just to use the same old JavaScript interpreter we have used before the JIT was introduced, which they undoubtedly keep working for those platforms which don't have JIT support available at all. That doesn't mean no JavaScript support, just a performance impact which is probably negligible on most sites Gmail makes very heavy use of JavaScript, so I bet the difference there is significant. There may be Free Software web applications for which the same is true, I'm just not familiar with them. I know you won't believe me; someone who knows how will have to perform a test. and much better security. You haven't convinced me of this. Are vulnerabilities that let one inject enough code to exploit the JIT (particularly after the SELinux patch) really that easy to find? But others have a better understanding of attacks in machine code than I do. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Javascript JIT in web browsers
On Sun, 2010-08-15 at 18:26 +0200, Kevin Kofler wrote: But the end effect is, we're allowing a web browser to disable memory protection, exposing all users to a severe security risk from merely browsing web sites. IMHO, the performance improvements in JavaScript aren't worth that risk. An alternative is to run the JavaScript in a less-privileged process, like I believe Chromium does. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Javascript JIT in web browsers
On Sun, 2010-08-15 at 22:41 +0200, drago01 wrote: On Sun, Aug 15, 2010 at 9:45 PM, Matt McCutchen m...@mattmccutchen.net wrote: On Sun, 2010-08-15 at 18:26 +0200, Kevin Kofler wrote: But the end effect is, we're allowing a web browser to disable memory protection, exposing all users to a severe security risk from merely browsing web sites. IMHO, the performance improvements in JavaScript aren't worth that risk. An alternative is to run the JavaScript in a less-privileged process, like I believe Chromium does. The problem is fixable there is a patch that is being discussed upstream to fix the issue and allow selinux memory protection it is just not merged yet. I'm not holding my breath. The patch would avoid one particularly risky behavior, but the browser still has a very large attack surface. OS-level sandboxing is a good idea in any case. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Javascript JIT in web browsers
On Mon, 2010-08-16 at 01:15 +0200, Kevin Kofler wrote: Some web sites are indeed abusing JavaScript. A web site is not and should not be an application, an application is not and should not be a web site. Just because you said so? Web applications bring enormous practical benefits to their users and administrators. It is a vehicle for proprietary software, where people often aren't even aware they're using non-Free code, or just ignore the issue. See also http://www.gnu.org/philosophy/javascript-trap.html . If you use a non-free web site, you have already lost the freedom to read, distribute, and modify the code you are relying on (http://www.gnu.org/philosophy/who-does-that-server-really-serve.html). I fail to see how running the site's non-free JavaScript for the sole purpose of interacting with that site makes the situation any worse. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Fri, 2010-08-13 at 22:59 +0200, Julian Sikorski wrote: Is the karma getting reset upon an edit? I don't have an answer to the question, but FYI, there is an open ticket about it: https://fedorahosted.org/bodhi/ticket/388 -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
On Thu, 2010-08-12 at 23:29 -0700, Jesse Keating wrote: On 08/12/2010 10:59 PM, Matt McCutchen wrote: That's why I'm so frustrated that Fedora seems to be committed to keeping the Mozilla trademarks, which moot any discussion of whether to deviate for those packages. But this is only my opinion. Fedora is welcome to set its own course, and I am welcome to fork (in theory at least). You're making an assumption here that it's the trademarks that prevent any deviation from upstream, when in fact the maintainer has stated many times that regardless of trademarks, he would not deviate from upstream given the sensitivity of a software suite that has to connect to the wild wild web. The maintenance burden of upstream deviation is greater than the maintainer would like to undertake, as is the risk of security issues and stability. I am aware of that. But FESCo has the authority to override the maintainer, and in their recent discussion of the SELinux patch, they decided not to move forward on the basis of the trademarks: https://meetbot.fedoraproject.org/fedora-meeting/2010-08-03/fesco.2010-08-03-19.30.log.html#l-66 Maybe the maintenance burden alone would also be enough to block further consideration of the patch, but there is no way to tell that from their discussion. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Fri, 2010-08-13 at 07:56 +0200, Ralf Corsepius wrote: On 08/13/2010 07:11 AM, Matt McCutchen wrote: Let's try that again. Fedora has no obligation to you; nothing entitles you (or anyone for that matter) to push updates or even to post to this list. ... and people are free to have their own opinions about Fedora and the people involved into its leadership. Indeed. If you want me to put it into a popular slogan which had been applied wrt. other governments: It's time for a change! Under the social contract, governments have an obligation to their people. The same does not apply to Fedora. The best option for people who do not see their concerns heeded is probably to fork. It is the prerogative of the board or others acting on their behalf to set the direction of the project and block you from participating in ways they believe are harmful. Period. ... and it's everybody's right to disagree with them and to pronounce their disagreement. Yes. And it's Fedora's right not to allow such pronouncements to be posted to the Fedora mailing lists. I believe the Fedora leadership recognizes the value of entertaining certain forms of dissent, and I believe many in the commmunity would agree that the repetitive, combative posts we have seen in the past few months are not one of them. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Where can I find the list of all Fedora Git repos?
On Thu, 2010-08-12 at 10:59 +0200, Andreas Schwab wrote: Martin Gieseking martin.giesek...@uos.de writes: Am 12.08.2010 10:32, schrieb Jaroslav Reznik: But as you can see on [1]: http://pkgs.fedoraproject.org/gitweb/ BROKEN (listing 10K+ packages does not work). Use e.g. http://pkgs.fedoraproject.org/gitweb/?p=erlang.git directly for the erlang package (also broken, unfortunately) Oops, sorry, I didn't notice that. Maybe I should have had a look at the wiki page first. :) Except that both are working fine. I went to https://pkgs.fedoraproject.org/gitweb/ and it sat there Generating for 5 minutes before I ran out of patience. I wouldn't consider that working fine. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Where can I find the list of all Fedora Git repos?
On Thu, 2010-08-12 at 11:20 +0200, Andreas Schwab wrote: Matt McCutchen m...@mattmccutchen.net writes: I went to https://pkgs.fedoraproject.org/gitweb/ and it sat there Generating for 5 minutes before I ran out of patience. I wouldn't consider that working fine. Try http://pkgs.fedoraproject.org/gitweb/ instead. That works. And now https://pkgs.fedoraproject.org/gitweb/ also works. It would appear that generation of the package list works but is extremely slow and there is a cache in front of gitweb that had already cached the content for the http URL but not the https URL. I propose that the cache should consider the http and https URLs equivalent, unless there is a difference in the content served that I haven't seen. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Fri, 2010-08-13 at 03:33 +0200, Kevin Kofler wrote: Chris Adams wrote: Why are you here? All you do is shout about how everything that is done is done wrong, and how you wanted to do it different but were out-voted. Why don't you go start your own distribution? If you are right, then you should have no trouble getting a large group of developers, producing an awesome OS, and then you can prove FESCo wrong. Are you providing the infrastructure? A distribution needs a lot of infrastructure, not just manpower. (And getting existing contributors to move to a new distribution is also not going to happen overnight, even if it's clearly better. [...]) Let's try that again. Fedora has no obligation to you; nothing entitles you (or anyone for that matter) to push updates or even to post to this list. It is the prerogative of the board or others acting on their behalf to set the direction of the project and block you from participating in ways they believe are harmful. Period. Chris was suggesting that you might consider starting your own project (which is always one's ultimate remedy in the F/OSS world), and that may be difficult, but none of that changes the foregoing. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Staying close to upstream
On Thu, 2010-08-12 at 22:26 -0700, Jesse Keating wrote: Do you have any sort of proof that it's a political reason? It would seem to me that our kernel maintainers do not wish to include code that hasn't been blessed by Linus in our packages. Doing so has burned us in the past, and perhaps this code has real issues that are keeping it out of upstream. We should not presume to be smarter than upstream, particularly when the kernel is involved. The package maintainer ultimately has control over what does or does not go into their package, and in this case they seem to be favoring sticking close to upstream as opposed to throwing in code willy nilly because it looks cool. Upstream has a code review process for a reason. IMO, staying close to upstream is simply a means to the end of shipping better software, and Fedora should be prepared to deviate from upstream when the benefit is compelling compared to the additional maintenance cost (though it's hard to say whether this standard is met in any given case). That's why I'm so frustrated that Fedora seems to be committed to keeping the Mozilla trademarks, which moot any discussion of whether to deviate for those packages. But this is only my opinion. Fedora is welcome to set its own course, and I am welcome to fork (in theory at least). -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora's ssh known hosts file
On Tue, 2010-08-10 at 09:07 -0600, Stephen John Smoogen wrote: On Sun, Aug 8, 2010 at 14:04, Matt McCutchen m...@mattmccutchen.net wrote: On Thu, 2010-08-05 at 22:23 +0200, Till Maas wrote: Yes ssh is secure if used properly. To get the proper known_hosts entry, one has to download https://admin.fedoraproject.org/ssh_known_hosts btw. I'm very glad to see that Fedora provides such a list. I just installed it on my computer (after filtering out hostnames not ending with fedoraproject.org, for obvious reasons). Is it documented anywhere? For full security, every packager should install it rather than allowing ssh to add host keys on first use. Well I am not sure that file would be all that useful as it contains lots of hosts a packager would not get to AND could conflict with other networks as it contains a lot of 10.X.X. and 192.X.X. ips. Then let's post an excerpt that would be useful to packagers. It also gets updated from time to time as we rebuild hosts. That just speaks to the need for better tooling to maintain personal known-hosts files, or for Fedora to operate an ssh certificate authority. It appears that the ssh folks rejected X.509 out of disgust for the public CAs, found themselves left with no solution at all to authenticate hosts the first time, and are now reimplementing it incompatibly. The man page claims the ssh implementation is much simpler -- perhaps, but it won't integrate with X.509-based systems and will be playing catch-up on features for a while. CRLs or OCSP, anyone? A thread from 2002 with some frank discussion that is still valid now: http://marc.info/?t=10117975211r=1w=2 -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Integrity protection of fetches
On Mon, 2010-08-09 at 12:11 -0700, Adam Williamson wrote: On Sun, 2010-08-08 at 11:34 -0700, Matt McCutchen wrote: On Fri, 2010-08-06 at 11:29 -0500, Steve Bonneville wrote: i.g...@comcast.net wrote: Ideally (from this perspective), the host would validate the response itself. Exactly, if sshd is sufficiently paranoid it should make a query with CD set in the request and do all the validation client-side. If you let your nameserver do the validation, I think it's still possible to MITM this by messing with the communication between the stub resolver and the name server, which isn't secured. Not to mention that one has to trust one's own nameserver, which is a bad idea when using a public wireless access point. In order to achieve I believe that can be simplified to 'using a public wireless access point is a bad idea' =) No, it just means that everything is untrustworthy until proven otherwise. If you use SSL or equivalent, you're fine. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: abrt thoughts pre-rfe q?
On Sun, 2010-08-08 at 09:24 +0100, Frank Murphy wrote: On 08/08/10 03:25, Matt McCutchen wrote: snip Would it be any benefit to the maintainers\bugzappers. If abrt opened the existing link, before it would report? And then what? Encourage the user not to add a comment unless they have new information? If that is the proposal, I am in favor. Yes that was the hope. But the main idea, was to get them to read the existing info. Users should already be reading the existing information, because abrt provides the link after it makes its changes (adding the user to CC and adding a comment with the how to reproduce text, if it was nonempty). The proposal would just be to reverse the order of the steps so that users can, and hopefully will, avoid adding redundant comments. So there wouldn't need be be so many replies of please try xyz?, to help cut down on noise. I don't understand this part. The noise I've seen consists of abrt-added me-too comments with steps to reproduce. I have never seen someone repost the same workaround in response to such a comment. By that I mean the maintainer\Co-Maintainer\Good Citizen retelling the same fix\workaround posted earlier in the bug. To either enable\updates-testing or do xyz. Because the bug report hasn't been read by the added to person. As I said, I have never seen that happen. Do you have an example? -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
