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=Fedora&product=Fedora&version=14&version=15&version=16&version=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
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=version&y_axis_field=resolution&query_format=report-table&product=Fedora&format=table&action=wrap) [2] https://bugzilla.redhat.com/report.cgi?x_axis_field=version&y_axis_field=resolution&query_format=report-table&product=Fedora&emailreporter1=1&emailtype1=exact&email1=matt%40mattmccutchen.net&format=table&action=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 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
[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
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 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
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 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
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 11:12 -0500, Adam Jackson wrote: > The deeper problem is that clients authenticate themselves to the > server, but then simply trust that the server is the server they were > hoping for. If you don't have a process tree relationship (like the gdm > +displayfd case) then you have to go all the way to something like > Kerberos for that kind of bidirectional auth. Not quite: you can use the xauth cookie as a pre-shared key. > Simply moving back to > filesystem sockets does not solve that - Right; what solves it is putting the socket in a place that is writable only by the user running the server. > and indeed, has _more_ DoS > conditions than abstract sockets since they don't get garbage-collected > on system crash They do if you use a tmpfs (e.g., /var/run with systemd), but in any event it's easy enough to unlink the socket or try another name. 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. -- 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
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
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: 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: [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: [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: 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: [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 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 > 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: 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 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 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 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: 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: 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 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 Adams wrote: > >>> > >>>> Once upon a time, Stanislav Ochotnicky 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-build&type=tag&match=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: 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: 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: 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 Adams wrote: > > > >> Once upon a time, Stanislav Ochotnicky 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: 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 wrote: > > > Once upon a time, Stanislav Ochotnicky 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: [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
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: 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 : > > 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 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
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: 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
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: 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
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: 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
#include
-#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: 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 (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: 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
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. Or did you mean something different? -- 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
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: 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
Re: Polyinstantiated /tmp
On Wed, 2010-10-20 at 08:13 -0400, Daniel J Walsh wrote: > I have been trying to get system processes to stop using /tmp for years. > > http://danwalsh.livejournal.com/11467.html > > As some one who lives with polyinstatiated namespace /tmp, The only > problem I know of now is handing of kerberos tickets. Whenever a system > process (root) needs to communicate with a user via /tmp. namespace > /tmp breaks it. sssd can not create kerberos tickets in my /tmp and > gssd can not find my kerberos tickets in /tmp. I believe the solution > to both is to move the tickets to be managed by sssd and leave /tmp to > users. > > BTW, X has solved this problem a couple of years ago by using virtual > namespace for its sockets. In the abstract namespace, don't you have the same problem where if the real X server dies for any reason, other users can create a socket at the same path and mess with your applications? -- 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: Git commit in all available branches
On Sun, 2010-10-17 at 20:36 +0400, Pavel Alexeev (aka Pahan-Hubbitus) wrote:
> I want fill it, but bugzilla even do not contain such component as
> fedpkg. Why?
$ rpm -q --qf '%{SOURCERPM}\n' fedpkg
fedora-packager-0.5.1.4-5.fc13.src.rpm
So the component to file bugs is "fedora-packager".
--
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: 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: 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 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 09:59 +0100, Richard Hughes wrote: > On 27 September 2010 20:31, Richard Hughes wrote: > > Right, but you could argue it's a regression as the behavior changed. > > Could somebody please fix docbook-utils, otherwise all the GNOME koji > > builds are going to fail. > > All my F14 builds are still failing with: > > docbook2man zif.sgml > /dev/null > grep: character class syntax is [[:space:]], not [:space:] > grep: character class syntax is [[:space:]], not [:space:] > jw: There is no frontend called "/docbook/utils-0.6.14/frontends/docbook". docbook-utils-0.6.14-26.fc14 with the fix appears to have gone into the repository in Koji: https://koji.fedoraproject.org/koji/getfile?taskID=2510888&name=createrepo.log Your builds should work now. -- 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 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: 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: -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 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_user&user_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 09:00 -0700, Jesse Keating wrote: > On 8/31/10 5:36 PM, 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". > > Yeah, I've been working in my head a fallback route, which might > eventually fall back to forcing a --branch or --dist option, something > like: See if there is a branch.merge setting, if not see if there is a > branch.dist setting, if not see if the local branch name matches a > regex, if not tell the user to provide --dist. Having the command-line option take priority whenever it is given would be a more conventional design. And it would be useful if branch.dist (or a working-tree file, as I am advocating) could override the local and upstream branch names even when they do follow the pattern for a dist value. -- 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 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: fedpkg prep
On Wed, 2010-09-01 at 13:33 -0400, Tom Lane wrote: > Matt McCutchen writes: > > 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. > > So would a configurable branch attribute. No, in the first case, the "dist" attribute would need to be set manually unless fedpkg either (1) provides a "new branch" command that sets it or (2) makes a branch inherit the "dist" attribute from the branch it tracks. > I have to admit I like that > idea a lot better than "branch" files, I don't. The "dist" value constitutes configuration for the build system, which does not belong in the version control system's configuration file. The natural place for such configuration is in the working tree, along with all the other artifacts manipulated by the build system. You wouldn't put the ./configure arguments for an autoconf-based package in the git configuration file, would you? > and especially better than some > complicated rule with multiple places to look for the information. It's not really that bad: you can specify the information in whichever place is most appropriate under the circumstances, and it will be found. -- 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 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: Packager, package, version summary
On Wed, 2010-09-01 at 21:41 +0530, Shakthi Kannan wrote: > I would like to know if something like the following exists or is it > possible to display the following for each packager: > > Package EL-6 EL-5 F-14 F-13 > > in a web-page (for example) that can be populated from Koji > (perhaps?). For example: > > Package EL-6 EL-5 F-14 F-13 > nesc--1.3.2-3 1.3.2-3 > vrq -1.0.741.0.771.0.77 > > If it is a new package in testing, then it could be indicated with a > different colour, perhaps? Right now, I am maintaining it in an > OpenOffice document, but, it will be helpful to see which versions are > available under which releases on a web page. The Fedora Community app has this information in a nice format, but for one package at a time: https://admin.fedoraproject.org/community/package_maintenance?package=%s -- 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: 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
Re: fedpkg prep
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 -- 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 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: 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 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: 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 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: 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
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: 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: 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: 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: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, 2010-08-24 at 23:31 +0200, Lennart Poettering wrote: > On Tue, 24.08.10 16:38, Bill Nottingham (nott...@redhat.com) wrote: > > Lennart Poettering (mzerq...@0pointer.de) said: > > > > - init shall support a mechanism to re-exec itself to not cause dirty > > > > inodes on shutdown; initscripts will use this method on shutdown. > > > > > > This is bad. While we support this just fine I think it is a really bad > > > idea to reexec init at shutdown. What's the point of this, can you > > > elaborate on > > > this? This smells to me as a workaround for brokeness in older init > > > systems, and I don't see a reason why reexecing itself would be > > > necessary for systemd. > > > > If the libraries or binaries used by systemd are replaced during runtime, > > and it is not re-executed on shutdown, the filesystem will have busy inodes > > on shutdown. (If you'd like to take the filesystem semantics up with the > > kernel, feel free to tilt at that windmill.) > > Hmm, so this is about files that are deleted but still mapped by init, > and which can only be deleted when init stops referencing them, but that > is required to remount the fs r/o? Did I get this right? Yes, that's right. > I am not really convinced that reexecing is the right answer for this > problem. But well, since this already works anyway I guess this doesn't > really matter too much. Indeed, it's a hack, but there's no better option in sight, so I don't see the point in complaining. > > Sure, I suppose individual maintainers want to push their code over the > > wall and > > then sit in their silo and claim 'that's not my problem' and 'someone else > > needs to fix that', well, that's their right to be lame. But we, as Fedora, > > as producers of a product that we ship to our users, don't have that luxury. > > But you enable them to block out change. For example, if somebody > refuses to merge a patch that adds a systemd equivalent for an upstart > config hook he has, he can sink the whole systemd in fedora project. If that happens, take it to FESCo. -- 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: 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: 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: 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: 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: 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
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 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: 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 > 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
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
