Re: rawhide report: possible improvements ?
On Sat, 2010-01-09 at 13:06 +1100, David Timms wrote: On 09/01/10 00:32, Rawhide Report wrote: Compose started at Fri Jan 8 08:15:04 UTC 2010 Broken deps for i386 -- ... ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 Hi, I noticed that some broken ones are duped (usually together), making it look like there is nearly twice as many as there really is. Would sort -u dedupe those ? Also, it could be cleaner and easier to read to invert or summarize the unsatisfied requires like: Broken dependencies: ghc-HTTP-devel-4000.0.6-6.fc13.i686 ghc-cairo-devel-0.10.1-5.fc12.i686 ghc-fgl-devel-5.4.2.2-1.fc12.i686 ghc-gconf-devel-0.10.1-5.fc12.i686 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 all require ghc = 0:6.10.4, which is not available. or ghc-doc = 0:6.10.4 is not available, but is required by: ghc-HTTP-doc-4000.0.6-6.fc13.i686 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 ghc-fgl-doc-5.4.2.2-1.fc12.i686 It might be nice to see the headings indented, and the package n-v-r-a info not indented, (since long package names, makes for more difficult to read emails, due to replies inserting quoting ( ) characters and oveflowing a single line. Also the report subject could include say '-' separators between y, m, day, like 2010-01-08 (which is another variant of the iso format that still sorts by date nicely ;) Reviewing patches. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Question about dist-cvs make targets
As I proceed to port our make system over into fedpkg, I've ran across a couple targets that are giving me pause. Is anybody out there making use of the following targets? check export patch unused-patches unused-fedora-patches If so, please reply to which one, and in what scenario you use those targets. Thanks! -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Question about dist-cvs make targets
On Thu, 2010-01-07 at 19:47 +0100, Enrico Scholz wrote: Jonathan Underwood jonathan.underw...@gmail.com writes: I have used make patch quite a bit when developing patches. I guess it's just a wrapper around gendiff though, so it maybe redundant i.e. in my use case I could have been using gendiff. fwiw, 'gendiff' does not retain comments in patches and fails when one file is touched by multiple patches. I wrote a wrapper around 'quilt' which is used like | %apply -n23 -p1 This expands to | quilt import -p 1 %PATCH23 | quilt push -f resp. | %patch23 -p1 on systems without this macro. Refreshing and developing of patches is very easy in this way. Enrico I think the patch target could be replaced by my exploded tree with git approach. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [PATCH] Bodhi No Frozen Rawhide Critical Path support
On Thu, 2010-01-07 at 14:34 -0500, James Laska wrote: Just to properly set expectations, I'd like to point out that while I agree that critical path package updates should meet a higher degree of quality, we've not yet collectively determined what testing updates means. QA is working on the infrastructure to support test automation and bouncing around ideas as to what a quality package update might look like. Until then, the same procedures in place for updates-testing now will be used for critical path packages [1]. During the freezes for F-12, releng at least took time to install, and minimally run the packages that were critical before allowing them to break freeze. That's what is expected out of this as well, a minimal look to ensure no brown paper bag updates get through. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Goals for F13?
On Wed, 2010-01-06 at 10:35 -0600, Mike McGrath wrote: What does everyone else have? 1) no frozen rawhide which requires faster composes 2) dist-git 3) A functioning message bus with services passing messages -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Our static Libraries packaging guidelines once more
On Tue, 2010-01-05 at 12:27 -0500, Tom Lane wrote: Tom \spot\ Callaway tcall...@redhat.com writes: On 01/05/2010 11:30 AM, Jesse Keating wrote: On Tue, 2010-01-05 at 11:03 -0500, Tom Lane wrote: On the other hand, with the guideline being so widely ignored, I'm not in a hurry to do work to comply with it ... Isn't that a chicken/egg problem? It really is. Well, fwiw, I have to fix the same two spec files for the %define problem, so I'm going to take care of this today while it's fresh in mind. But there's a general issue that new things keep getting added to the packaging guidelines and there's no very good mechanism to detect whether existing packages ever get updated to comply. regards, tom lane In the future when we have AutoQA online we'll be able to add new tests for new guidelines and alert maintainers who's specs fall out of.. er.. spec. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Phase 3 of dist-git project under way
Over the holiday break I coded up the framework for fedpkg, the utility to replace Make within dist-git. I'm now ready to accept help with developing this tool. See https://fedoraproject.org/wiki/Dist_Git_Project#fedpkg if you would like to help develop / test and then contact me. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
On Dec 23, 2009, at 7:20, Rahul Sundaram sunda...@fedoraproject.org wrote: On 12/22/2009 09:07 PM, Seth Vidal wrote: FWIW - I agree with both jesse and jarod. Official builds are from main branch. Anything built anywhere else will never be official. How about scratch builds? Those can come from anywhere, even srpms for packages no enev in our source control. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
On Dec 23, 2009, at 7:38, Rahul Sundaram sunda...@fedoraproject.org wrote: On 12/23/2009 09:04 PM, Josh Boyer wrote: On Wed, Dec 23, 2009 at 08:50:11PM +0530, Rahul Sundaram wrote: On 12/22/2009 09:07 PM, Seth Vidal wrote: FWIW - I agree with both jesse and jarod. Official builds are from main branch. Anything built anywhere else will never be official. How about scratch builds? What about them? Scratch builds are not official by definition. They don't show up in repos, are only available for a couple weeks, etc. The question was, are they ok to build from private branches? Yes How does this tie into http://fedoraproject.org/wiki/JesseKeating/KojiPersonalRepos It doesn't really. -- jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
On Wed, 2009-12-23 at 19:28 +0100, Kevin Kofler wrote: The whole problem is that such branches do not exist at all in the new git setup! If you get eaten by raptors, you can't expect another maintainer to come in after you and have to dig around for a private branch to update a build. That's why we need non-private branches (more than one per release), as allowed by our current CVS setup. Perhaps we have a terminology clash. The dist-git proof of concept allows branches to be created by maintainers, and pushed to the central repo, so long as the branch name starts with private-. These repos can be written to by anybody with file system write access, that is anybody in the 'packager' group. At this time, I am not planning to allow official tagged builds to come from these branches, instead they can only come from origin/master or origin/F-?? -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
On Wed, 2009-12-23 at 15:46 -0500, Jarod Wilson wrote: Okay, we've definitely got some slight misunderstanding here... :) I was objecting to Kevin's suggestion that we should be able to build official packages from branches named ^private-*. But building from a branch tagged something !^private- is actually necessary sometimes. The kernel folks have had to do just that from time to time. For example, say the F12 cvs head moves on towards 2.6.32 and an official build is submitted to updates-testing. Meanwhile, a security update for the already-released-to-users 2.6.31.x kernel needs to get pushed out. We create an F12-specific 2.6.31.x branch and build an *official* kernel to push to updates post-haste to fix the security issue. This *does* need to be allowed. But it wouldn't be on a branch named private-*, it would be quite blatant and obvious in naming, such as f12-2_6_31_x-kernel-branch or similar. I think there was some confusion in my use of private branch, where I was referring to branches with a name ^private-*, while Kevin was thinking in a more general sense, which would encompass the above kernel example. I understand the use case, I'm still not super keen on having official built packages come out of a branch. Makes discovery somewhat difficult, and leads to problems if we have to bump+build something and don't realize that the real live code is actually on a branch. So this needs some more thinking, and discussion, which is happening here, which is a good thing. Healthy debate is good, lets just endeavor to keep it healthy (: -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
On Wed, 2009-12-23 at 14:23 -0800, Roland McGrath wrote: I understand the use case, I'm still not super keen on having official built packages come out of a branch. Makes discovery somewhat difficult, and leads to problems if we have to bump+build something and don't realize that the real live code is actually on a branch. Surely all previous builds will be easy to discover in koji and that will tell you the exact commit id. AIUI there should be an automagic git tag pushed by koji so that just directly in git alone it is trivial and reliable to find the commit matching a given build. In git the idea of a branch is not inherently a permanent thing, and only the ancestry graph of a particular commit is truly meaningful as historical information. Just the commit id of interest is what you need to ascertain whether it is the head or ancestor of which branches at the time you ask the question. Right, but when I as a releng person need to bump something in an emergency or when a maintainer is out, I expect origin/master to be live for rawhide, ditto origin/F-12 for Fedora 12. I don't expect that I'd have to go hunting down where the commit hash for the previous build came from, then try to discover which branch that commit hash currently lives on, so that I can commit on top of it and keep going. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
On Mon, 2009-12-21 at 18:59 -0800, Josh Stone wrote: Perhaps this should be locked down to private-$USERNAME-*? Otherwise, anyone could push into a branch that I'm trying to work with. Also, I wasn't able to delete a branch that I had pushed -- not sure if you meant to allow that. If the ACL system were to keep everybody in their own $username namespace, no two people could collaborate on a single branch, which kinda defeats the purpose of having the server side branch. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
On Tue, 2009-12-22 at 14:02 +0100, Hans Ulrich Niedermann wrote:
On Mon, 21 Dec 2009 18:59:53 -0800
Josh Stone jist...@redhat.com wrote:
On 12/21/2009 06:10 PM, Jesse Keating wrote:
This has been done. The way the ACLs now work, if you are a
packager, you can create branches in any package that start with
private-. This makes it even easier to pass changes around as
you can tell the maintainer to pull from or merge from a private
branch you've created.
Perhaps this should be locked down to private-$USERNAME-*? Otherwise,
anyone could push into a branch that I'm trying to work with.
Good catch IMHO. My first thought also would be to separate the
branches the package (co-)maintainers create, and those that
every contributor can create to reduce conflicts. However, I would
try to make them distinguishable, e.g.:
private-foo
for branches where all people in the pkg ACLs can push to
private/${FAS_ACCOUNT}/*
for the any contributor can push branches
Having private-foo-baar for feature foo-bar and private-foo-bar for user
foo's bar branch could end up being quite confusing.
Having ACLs based on the username committing would take a fair amount of
hacking on the ACL tool, but not impossible.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
signature.asc
Description: This is a digitally signed message part
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
On Tue, 2009-12-22 at 08:41 -0800, Josh Stone wrote: On 12/22/2009 08:09 AM, Jesse Keating wrote: On Mon, 2009-12-21 at 18:59 -0800, Josh Stone wrote: Perhaps this should be locked down to private-$USERNAME-*? Otherwise, anyone could push into a branch that I'm trying to work with. Also, I wasn't able to delete a branch that I had pushed -- not sure if you meant to allow that. If the ACL system were to keep everybody in their own $username namespace, no two people could collaborate on a single branch, which kinda defeats the purpose of having the server side branch. Not entirely, as those two people could still pull from each other's branches. Or as Hans said, some other namespace could be pushable for the maintainers to collaborate on. Either we trust that no packager will ever misbehave, or we need to lock this down... Josh Since no official builds would be able to come from the private branches, and since you can create other branches from other devel points along the way, I think I'm going to fall on the side of trust here, since we can relatively easily clean up from either mistakes or malicious intent. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Mass rebuild for F13?
On Dec 21, 2009, at 4:38, Orcan Ogetbil oget.fed...@gmail.com wrote: On Mon, Dec 21, 2009 at 7:21 AM, Jakub Jelinek wrote: On Mon, Dec 21, 2009 at 07:03:13AM -0500, Orcan Ogetbil wrote: It would be nice if you folks add these little explanations as comments next to the patches of the gcc SPEC file. (this is also a packaging requirement [1]). 1) gcc-4.4-RH has its own svn branch in upstream repository, so the src.rpm contains only very few patches, most of the changes are simply committed to the svn branch. svn commit logs contain all relevant info. 2) the patches (~ 20) that are left have comments in their bodies, rather than in the spec file, which is much more maintainable. Yeah, those comments in the patches are quite informative, like libtool sucks. Seriously, this comment about the patch in the specfile is a packaging requirement, not a personal request. With git style patches (and others) where there is lots of context and info in the patch file itself, duplicating it into the spec file is rather pointless. Let's have some thinking about the guidelines instead of blind following. The guideline is there so that we don't just have raw diffs without any context. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git help wanted: write me a regex!
On Mon, 2009-12-21 at 11:07 -0500, James Cassell wrote: On Mon, 21 Dec 2009 01:53:42 -0500, Bruno Wolff III br...@wolff.to wrote: /((Mon|Tues?|Wed|Thu(rs?)?|Fri|Sat|Sun)\s+(Jan|Feb|Mar|Apr|May|June?|July?|Aug|Sep|Oct|Nov|Dec)\s+[0-3]?[0-9]\s+(19|20)[0-9][0-9]\s+[A-Za-z0-9\s]+[...@]+@[^\s@]+\s+2.[4-6].[0-9.-]+\s*)/ I don't think this will catch a period in the comment part of the email address (as people often do after initials). Also if anyone is using hyphenated names, I don't think those will get picked up. Since those entries are utf-8, you need to worry about nonascii letters in the name. I am not sure how those collate compared to ascii letters, but it might be safer to use [^]+ (instead of [A-Za-z0-9\s]+) You are correct. Here's the improved version: /((Mon|Tues?|Wed|Thu(rs?)?|Fri|Sat|Sun)\s+(Jan|Feb|Mar|Apr|May|June?|July?|Aug|Sep|Oct|Nov|Dec)\s+[0-3]?[0-9]\s+(19|20)[0-9][0-9]\s+[^]+[...@]+@[^\s@]+\s+2.[4-6].[0-9.-]+\s*)/ -- James Cassell I'm having some difficulty applying this. It's going into a perl file thusly: $logmsg =~ s|/((Mon|Tues?|Wed|Thu(rs?)?|Fri|Sat|Sun)\s+(Jan|Feb|Mar|Apr| May|June?|July?|Aug|Sep|Oct|Nov|Dec)\s+[0-3]?[0-9]\s+(19|20)[0-9][0-9]\s +[^]+[...@]+@[^\s@]+\s+2.[4-6].[0-9.-]+\s*)/|mg But that gives me Unmatched ( in regex; marked by -- HERE in m/(( -- HERE or something along those lines. The added s|...|mg is coming from other lines in this script which look like: $logmsg =~ s|^\s*\d\d*-\d\d*-\d\d*\s*[^\n]*[^\n]*\s*$|* \n|mg; so I'm sure I'm screwing something up when putting it in the script. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git help wanted: write me a regex!
On Mon, 2009-12-21 at 11:40 -0600, Jeffrey Ollie wrote: On Mon, Dec 21, 2009 at 11:24 AM, Jesse Keating jkeat...@redhat.com wrote: I'm having some difficulty applying this. It's going into a perl file thusly: $logmsg =~ s|/((Mon|Tues?|Wed|Thu(rs?)?|Fri|Sat|Sun)\s+(Jan|Feb|Mar|Apr| May|June?|July?|Aug|Sep|Oct|Nov|Dec)\s+[0-3]?[0-9]\s+(19|20)[0-9][0-9]\s +[^]+[...@]+@[^\s@]+\s+2.[4-6].[0-9.-]+\s*)/|mg But that gives me Unmatched ( in regex; marked by -- HERE in m/(( -- HERE or something along those lines. The added s|...|mg is coming from other lines in this script which look like: $logmsg =~ s|^\s*\d\d*-\d\d*-\d\d*\s*[^\n]*[^\n]*\s*$|* \n|mg; so I'm sure I'm screwing something up when putting it in the script. You can't use | in the s|||mg command since it's used inside the regex. IIRC you should be able to use %: s%%%mg. Ricky helped me get this regex going, thanks all! -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Mass rebuild for F13?
On Mon, 2009-12-21 at 14:41 -0500, Orcan Ogetbil wrote: On Mon, Dec 21, 2009 at 10:52 AM, Jesse Keating wrote: On Dec 21, 2009, at 4:38, Orcan Ogetbil wrote: Yeah, those comments in the patches are quite informative, like libtool sucks. Seriously, this comment about the patch in the specfile is a packaging requirement, not a personal request. With git style patches (and others) where there is lots of context and info in the patch file itself, duplicating it into the spec file is rather pointless. Let's have some thinking about the guidelines instead of blind following. The guideline is there so that we don't just have raw diffs without any context. Then I would say, let's have a look at the comments of gcc's patches before blindly believing in that they all have explanatory comments in them. Many don't. Some do, but those comments are sometimes 2 word comments such as the one given above. I fail to see the consistency here. Orcan Whether they do or don't have the comments wasn't what I was replying to. Whether the comments could exist in the patch files or whether they are required to be in the .spec file is the issue I was addressing. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
On Mon, 2009-12-21 at 19:56 +0100, Kevin Kofler wrote: Jesse Keating wrote: Treat the origin/F-?? as the master for that release, do your long running not immediately ready for build work on topic branches thereof and only merge them when you're ready to build. This requires us to know in advance that the work will be long running. In my experience, this is usually only noticed once the new version has been imported (with the intent to build it right away), or even once it made it to testing and got massive negative karma (after all, that's what testing is for: as the name says, stuff there needs to get tested and can fail). One case where I had to branch off an old build: I noticed on December 14 that the September 30 kde-plasma-networkmanagement snapshot had been pushed only to F11 updates and not to F12, breaking the upgrade path. By then, the F-12 branch had moved on to an October 24 snapshot, but I didn't want to rush out a newer, untested snapshot to fix the upgrade path, but instead queue the same one as on F11. (In addition, the October 24 snapshot is outdated too, Rawhide has a newer one, but current snapshots require Qt 4.6.) But the corresponding F12 build had already been deleted by Koji, so I had to branch and rebuild a new one. I used the create a branch with a name which looks like a build tag to the tag validator hack and branched kde-plasma-networkmanagement-0_9-0_3_20090930svn_fc12_x, then built off that branch. Kevin Kofler While I need to digest this a bit more, it really sounds like you're trying to do wy to active development on /released/ Fedora branches, eg a problem of your own creation. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
On Sun, 2009-12-20 at 19:31 -0800, Jesse Keating wrote: On Sun, 2009-12-20 at 10:28 +0100, Hans Ulrich Niedermann wrote: Currently, it appears that I can push arbitrarily named branches, at least if the package does not have per branch ACLs: Yes, that makes sense given the way the ACL system works, it just wasn't fully expected by me. A small change to the ACL generation script will make sure that this sort of loophole is closed. This has been done. The way the ACLs now work, if you are a packager, you can create branches in any package that start with private-. This makes it even easier to pass changes around as you can tell the maintainer to pull from or merge from a private branch you've created. Nobody should be able to create any branches that do not start with private-. If we wanted to lock this down more, and only allow you to commit to a private- branch only if you already have write access to some other branch (F-12, master, EL-5, whatever) then I'll have to add more logic to the ACL generation tool. But for now, I like the freedom we have. We'll make sure that the buildsystem will not allow any official (non-scratch) builds to happen from a private-* branch. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
On Sun, 2009-12-20 at 09:46 +0100, Kevin Kofler wrote: Either way, you want to branch from an old revision, create new ones in the branch, and, what's different from a private topic branch, build the packages from the branch for dist-f12-updates-candidate and eventually queue them in Bodhi. What's the best way to handle this? Right now, in CVS, you can create a CVS branch within the F-12 branch as long as you manage to create a branch name which passes validation and build from there. (AFAIK, private-* branches can be abused for builds, and it's also possible to create branches with names which look like build tags, which also get through validation.) I'm not a real fan of allowing official builds to happen from branches like this. I'm ok with them being created and shared for various topics, but the official builds should come from origin/master or origin/F-?? Coming up with namespaces that we allow for shared repo branches will be a discussion to have. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
On Sun, 2009-12-20 at 10:28 +0100, Hans Ulrich Niedermann wrote: Currently, it appears that I can push arbitrarily named branches, at least if the package does not have per branch ACLs: Yes, that makes sense given the way the ACL system works, it just wasn't fully expected by me. A small change to the ACL generation script will make sure that this sort of loophole is closed. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
On Mon, 2009-12-21 at 05:06 +0100, Kevin Kofler wrote: So what do you suggest doing in such a case? Temporarily reverting the F-n branch to the old release, build, then bump it up again? This sounds really suboptimal to me (in addition to being a regression from our current CVS setup, which does allow creating such branches)! Branching is really part of what VCSs are for. You're right, branching is a real part, that's why you would start the foo-1.1 work on a topic branch, and only merge it into origin/F-12 when you're ready to build it and push it through bodhi. Just like you'd work on a new feature on a feature branch and only bring it over to origin/master when you're ready to merge it with everything else. Treat the origin/F-?? as the master for that release, do your long running not immediately ready for build work on topic branches thereof and only merge them when you're ready to build. This reduces the surprise should another developer need to quickly build out an update that is unrelated to any major change you may have cooking. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
dist-git help wanted: write me a regex!
The kernel module is full of changelogs that start with: Thu Dec 17 2009 Jarod Wilson ja...@redhat.com 2.6.32.1-11 of course the date, name, email and revision will change, but the format is the same. This data is not really necessary in git, as we have all of that already, and it makes shortlog rather useless. parsecvs has a feature that allows one to filter out parts of log messages, and it requires a perl regex to find the lines to strip out. I'm no regex hacker, but I bet some of you are. Can somebody please write me a regex that will catch the above line, and others like it? Thanks! -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
On Dec 19, 2009, at 8:42, Jonathan Underwood jonathan.underw...@gmail.com wrote: 2009/12/18 Jesse Keating jkeat...@redhat.com: Phase two, write access with ACLs, is ready for testing. Please not that URLs have changed since my original announcement. git clone ssh://[fedoraacco...@]pkgs.fedoraproject.org/package will get you a cone via ssh, in which you can git pull and git push. The repos are the same from phase1, although I've done a few commits here and there to test things. They are not tied to the CVS repos, so changes you make here are truly throw away. Please test cloning and writing to packages and branches of packages that you would normally have write access to, or normally would /not/ have write access to. I'm interested in seeing both of those cases tried. I checked out emacs-vm and the commited and pushed a change to the spec file and was quite surprised to find that the change was pushed to all branches. Is that intended ? Um, no. I'll look at this module and see what happened. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
On Sat, 2009-12-19 at 12:41 -0500, Ray Strode wrote: So one thing I tried is to create a custom topic branch (a la private- branches in pkgs cvs), and pushing it failed. Is this something we want to support? Or should topic branches be pushed to separate private respositories? We definitely want to allow topic branches pushed to the main repo. I think we'll have to agree on a namespace to use for these, perhaps following the dist-cvs example and call them private-* The way the ACL system works is that it matches on the refs you're pushing up, so for packages that have per-branch ACLs only the refs that match the branch have ACLs on them, and the assumption is that without an ACL you have no rights to it. That's likely why your push failed, but I'd like to see the message to confirm. It shouldn't be too hard to tweak the ACL creation script to add W access to anybody who has W access already to the private-* namespace. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
On Dec 19, 2009, at 15:02, Jeff Garzik jgar...@pobox.com wrote: Sorry, if I missed this in previous messages... Are the cvs tags going to become git tags, or git branches? When I checked out ~48 hours ago, it seemed like everything was a git branch, which is not what I expected for the build tags. kernel.org admins recommend either 'git tag -a' or 'git tag -s' tags, and not plain 'git tag'. The cvs tags should become gi tags. If they aren't I'll have to look into it. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Thu, 2009-12-17 at 23:28 -0600, Adam Miller wrote: +1 to Adam W because I'm an ultra git neophyte (and a CVS one for that matter) but the current make file automation essentially removes that as an issue. I'm not saying I'm against learning git if need be, but I agree that it would be an unfortunate regression. You guys do realize that there is really only 2 things the Make system handles on the CVS side for you? Creating a tag (which we won't need in dist-git), and importing an srpm. Other than that you've been using the real cvs directly. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Fri, 2009-12-18 at 14:02 -0600, Adam Miller wrote: True, but the only two commands I need to know are 'cvs up' and 'cvs commit'. It just seems as though from the conversation in this thread there will be a bit more knowledge needed with the git branching and what not (or could potentially be needed). Again, I'm not against this ... I've been looking for an excuse to force myself to learn git a bit better, but I do think this is something that might want to be taken into consideration. It has been in the plans all along to hide most/all of git behind fedpkg calls, even more than cvs was hidden. I just wanted to make the point that very very little of CVS was hidden. The only added potentially sticky point is how to get from the rawhide view of content to say the F-12 view. But as I said, that'll be hidden behind fedpkg for those that don't want to use git directly. I'm a big fan of mercurial and I've been told that it would be an easy transition to git, so I'm really not trying give push back on this. Just wanted to point out that I agree with AdamW that there is potential for a regression. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
dist-git proof of concept phase 2 ready for testing
Phase two, write access with ACLs, is ready for testing. Please not that URLs have changed since my original announcement. git clone ssh://[fedoraacco...@]pkgs.fedoraproject.org/package will get you a cone via ssh, in which you can git pull and git push. The repos are the same from phase1, although I've done a few commits here and there to test things. They are not tied to the CVS repos, so changes you make here are truly throw away. Please test cloning and writing to packages and branches of packages that you would normally have write access to, or normally would /not/ have write access to. I'm interested in seeing both of those cases tried. Thanks again for your help in this project! -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
On Dec 18, 2009, at 16:37, Hans Ulrich Niedermann h...@n- dimensional.de wrote: On Fri, 18 Dec 2009 15:31:49 -0800 Jesse Keating jkeat...@redhat.com wrote: Phase two, write access with ACLs, is ready for testing. Please not that URLs have changed since my original announcement. git clone ssh://[fedoraacco...@]pkgs.fedoraproject.org/package git clone ssh://[fedoraacco...@]pkgs.stg.fedoraproject.org/package as far as I can tell. Crap. I did it again. Thanks for catching that. That is what I get for rushing a message out before taking off. -- Jes-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Mon, 2009-12-14 at 19:21 -0800, Jesse Keating wrote: git://publictest5.fedoraproject.org/git/pkgs/package eg if you wished to clone the kernel, you'd type: git clone git://publictest5.fedoraproject.org/git/pkgs/kernel Just an FYI, the hostname (and path) changed slightly. git clone git://pkgs.stg.fedoraproject.org/kernel I hope to have ssh authenticated push support ready in the next day or so, complete with the same ACLs we have currently with CVS. I could use a lot of people cloning and committing to test the performance of the ACL system. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Possible wrong versions tagged into f12-final
On Mon, 2009-11-09 at 11:19 +, Quentin Armitage wrote: I've noticed what might be a couple of anomalies regarding which versions of packages have been tagged into f12-final. freenx-client: 0.9-9.fc12 was built as part of the dist-f12-rebuild, but 0.9-10.fc11 tagged has been tagged into f12-final. gauche: 0.8.14.3.fc12 was built during the mass F12 rebuild, but 0.8.14.3.fc11 has been tagged into f12-final. It appears that 0.8.14-2.fc12 was built after 0.8.14-3.fc12 (during the mass F12 rebuild). Quentin Armitage Yeah, looks like some fallout around the mass rebuild and getting things tagged over. Too late to do anything about F12 now, owners of those packages might consider issuing updates (which would then be picked up in F13) -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: acctcom for linux
On Tue, 2007-05-01 at 08:38 -0400, William W. Austin wrote: 05/01/2007 05:38:26 AM (Tue, 01 May 2007 08:38:26 -0400) Your date is still wrong. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Tue, 2009-12-15 at 05:55 -0500, Jon Masters wrote: Can you explain the tags a little Jesse? e.g. F-12-split F-12-start I have absolutely no interest in the idea of doing one giant tree btw, though I doubt that will ever get serious traction :) Also, on the subject of branches, can you include a summary of branches too? There are two types of tags that exist. Tags that reflect when CVS branches were made, and tags that reflect the make tag action of a maintainer, presumably as part of a build process. F-12-split is a tag that indicates at what point the F-12 directory on the CVS server was created, and on the F-12 branch there would be an 'F-12-start' tag as well. The build tags exist on whichever branch they were made from. As for branches, there are 2 kinds of branches. One kind has the form of F-12 or EL-5 and that reflects the CVS directory in dist-cvs. These are generated by infrastructure, and it will likely not be possible to create branches in this form in git by yourself. The other kind of branch is private-* type branches, which were real CVS branches that allowed developers to work on stuff without messing up HEAD. We'll likely continue to allow remote branches of a specific pretext, such as private- if you wish to work with multiple people on a branch. Otherwise git allows you infinite number of local branches to do your work. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Tue, 2009-12-15 at 09:49 +, Richard W.M. Jones wrote: Why not put everything in a single git repository? The cost to clone that repo would be enormous. The kernel alone is 57M once cloned, 44 megs across the wire. Also git remote branches are quite painful, requiring non-obvious changes to .git/config or hard to use commands. I'd rather do this once (for an everything-in-one-repository model) than for every single package I maintain. Why would you have to do anything special? Our helper script can check things out for you in a way that git pull/push/whatever does the right thing by tracking the upstream branch. You shouldn't have to touch your .git/config at all. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Tue, 2009-12-15 at 11:11 +, Daniel P. Berrange wrote: I was wondering if you could set up some meta repository, which had a GIT sub-module for each package, but it seems sub-modules always have to specify an explicit commit hash so they wouldn't seemlessly follow changes. I briefly looked at submodule stuff, but it really isn't in a shape we can easily use. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Tue, 2009-12-15 at 15:57 +0100, Hans Ulrich Niedermann wrote: I would presume that the to-be-written package handling tool (the code name is fpkg AFAIR) would set up local tracking branches when... uhm... needed (the exact triggers need to be worked out). It should work out to fpkg calling $ git branch F-$n origin/F-$n for appropriate values of $n, which is not much magic. Right. fpkg checkout --full kernel that would give you kernel/devel kernel/F-12 kernel/F-11 etc... where each of those subdirs map to the appropriate origin/F-1? (or in the case of devel, to origin/master). Any git push/pull from those dirs would do the right thing. fpkg checkout kernel that would just get you kernel/ and in that directory would be the .spec and all the other stuff. It would be the origin/master. From there if you did: fpkg checkout F-12 It would essentially do a git checkout -b F-12 --track origin/F-12 (unless the local F-12 branch already existed). So again push/pull would do the right thing. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Tue, 2009-12-15 at 11:24 +0100, Ralf Ertzinger wrote: Hi. On Mon, 14 Dec 2009 19:21:19 -0800, Jesse Keating wrote: In my effort to create a proof of concept for using git to manage our package source control, I have completed what I am calling phase one, that is taking our current dist-cvs and converting it into git format. That's just the naked content converted into git, right? All the scripts/ Makefiles in it still assume that CVS is used and thus do not do much? That is correct. This is just phase 1, getting the CVS content into git format. As Hans replied, the Makefiles will be going away, and fpkg will be written to take over that job. I hope to have a framework for fpkg up in the next few days to allow people to start hacking on it with me. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Tue, 2009-12-15 at 12:15 +0100, Haïkel Guémar wrote: Do you have any plan about hooks ? Since 1 package = 1 repository, does that mean package maintainers will be able to define their own hooks ? (bad idea) will we have some pre-defined hooks (like bz integration) ? or something like github webhooks or bitbucket brokers ? We'll definitely have some mandatory hooks. The first one we're looking at is a hook to do branch level ACLs. Also, I seem to recall that you would need shell access to the remote repo in order to add a hook, so it would not be possible for maintainers to add their own remote hooks. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Tue, 2009-12-15 at 15:50 +0100, Hans Ulrich Niedermann wrote: Will older history be available in the final production git repos? This might come in handy for the remaining merge reviews, or for historical purposes, or just be dead weight. I'm not sure which one. I had originally wanted to import history from FC1 forward, but when I thought some more about it, the FC-1 through FC-6 branches wouldn't share a common history with the origin/master made from the external dist-cvs. That would make importing the FC-1~6 stuff rather more difficult. I /might/ be able to do something with a graph point but I honestly haven't looked very hard. If anybody is interested... -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Tue, 2009-12-15 at 16:17 +0100, Hans Ulrich Niedermann wrote: In two of my packages which go back some time (id3v2, soundtracker), there are two CVS commit authors which are not converted into proper names of the Firstname Lastname e...@mail variety: cvsextras and gafton. Both CVS authors get the default conversion to $1 $1. Is this on purpose? Ah, yes, there are going to be a few authors missed. The conversion script just looks for a cvs author name in a file, and that file expands that author name out to Full Name u...@fedoraproject.org. The file I have now is not 100% complete, there are some newer offerings from folks that have more data from FAS but I suspect there will be a few names I'll have to add manually. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Tue, 2009-12-15 at 19:01 +0100, Andreas Schwab wrote: There are also author names that where expanded to user u...@fedoraproject.org. Yeah, that might be a privacy thing, not sure if full name can be hidden behind the privacy shield, we might not be able to get to them. That data will be coming from FAS. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Tue, 2009-12-15 at 13:16 -0500, Todd Zullinger wrote: I'd like to suggest (again ;) that origin/devel be used. Either that, or use master as the local dir, e.g. kernel/master. Having it differ seems like a recipe for unneeded confusion. I'm willing to listen to other opinions on this. Personally I'd really rather not change the meaning of origin/master. devel would show up as a directory in the classic view only to match what CVS did. I'd even be willing to make two directories, one a symlink to the other. You'd get kernel/master and you'd also get kernel/devel as a symlink to kernel/master -- Jesse Keating RHCE (http://jkeating.livejournal.com) Fedora Project (http://fedoraproject.org/wiki/JesseKeating) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) identi.ca (http://identi.ca/jkeating) signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Tue, 2009-12-15 at 19:24 +0100, Nicolas Mailhot wrote: BTW, please make sure the new system has something like cvs-import (ie put the files in this srpm as new changeset in the vcs, I don't want to know how your vcs works, this is a good srpm just eat it) Yep, that functionality would continue to exist. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Tue, 2009-12-15 at 13:33 -0500, Todd Zullinger wrote: My thinking is that we don't use origin/next or origin/maint either and both are common upstream in git and the kernel. While origin/master is common, origin/master isn't common, it's the friggin default. Every single git repo I interact with has development happening on origin/master. It's way more than just common. for our use, 'git push origin devel' (or rawhide) makes more sense as it matches the use for other branches, git push origin F-12. There's nothing magical or required about using master as the main branch. If our maintainer has to type that out, i think we've failed the conversion. The thought here is that you'd be doing git push and stuff will just happen right. But /if/ you wanted to do things manually then it should match just about every other git repo out there, where the main branch is origin/master Whether other users will be more confused by the incongruity of master versus devel or that it differs from what they think git may require, I don't know. Yep, it's an opinion thing :/ -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Tue, 2009-12-15 at 13:32 -0600, Chris Adams wrote: Once upon a time, Ville Skyttä ville.sky...@iki.fi said: The first two Google hits I get for fpkg are already two different tools that have something to do with software packaging, so I suggest not adding the third but coming up with some other name for this one. fedpak fpak Either of those works for me. I hadn't actually done any looking around for fpkg uses. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Tue, 2009-12-15 at 15:49 -0500, Dave Jones wrote: I'm on vacation, but I couldn't resist taking a look-see. Something looks odd. It appears to have collapsed every CVS branch onto the master git branch instead of making a new branch for each CVS branch. Running git log on the master branch should only show the commits that happened to HEAD in cvs. This might not matter much for most packages, but the kernel does have a lot of (mostly useless) branches, so the history looks a bit messy. That's strange, when I clone and do a git branch -r, I see 142 branches, lots of those private-* branches. What things that were CVS branches are you seeing on origin/master ? -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Tue, 2009-12-15 at 22:16 +0100, Hans Ulrich Niedermann wrote: On Tue, 15 Dec 2009 16:05:07 -0500 Dave Jones da...@redhat.com wrote: On Tue, Dec 15, 2009 at 12:54:44PM -0800, Jesse Keating wrote: What things that were CVS branches are you seeing on origin/master ? run git log, and see all the myoung commits for example. Run git log -p, and you notice that those are empty commits without any actual changes. Smells like the CVS-git conversion tool has confused something. Neat! Guess that'll have to be worked on. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
dist-git proof of concept phase 1 complete
In my effort to create a proof of concept for using git to manage our package source control, I have completed what I am calling phase one, that is taking our current dist-cvs and converting it into git format. pkgs/rpms/package/devel is now the git origin/master. All release subdirs have been turned into git branches. History back to F7, as well as the EPEL branches have been converted, from a snapshot of the CVS tree I took last week. Currently I only have anonymous git:// access setup, as we play with some options for authenticated writing. If you wish to play around with the repos, you can access it via: git://publictest5.fedoraproject.org/git/pkgs/package eg if you wished to clone the kernel, you'd type: git clone git://publictest5.fedoraproject.org/git/pkgs/kernel Give it a spin, see what you think. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Datacenter, git, and cvs
On Mon, 2009-12-14 at 19:55 -0500, Jeff Garzik wrote: I think of it less as a question of /liking/ CVS, and more an admission that a global workflow change has real costs for each individual developer. A flag day-style transition is clean and efficient, but often locks out developers who are not able to march in lock-step with the transition schedule. I am very pro-git (naturally, being a kernel developer) and want this switch, but it nonetheless means my home-written scripts for maintaining related project packages (cld, chunkd, tabled) must be updated and tested. Even without local script updates, developers have to learn new stuff just to keep functioning at the same level as before. Because we are not just moving source control backends, but also changing workflow, a cvs gateway to the git server wouldn't get you very far, unless it's a pretty hacked up gateway. If somebody wants to work on a gateway that's cool, I'm not considering it a blocker to rolling out the change, once we have a working proof of concept and a solid migration plan blessed by FESCo. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Mon, 2009-12-14 at 21:48 -0600, Sir Gallantmon wrote: Do you have the webview set up yet? Not as of yet. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Mon, 2009-12-14 at 19:21 -0800, Jesse Keating wrote: git clone git://publictest5.fedoraproject.org/git/pkgs/kernel This was the wrong path: git clone git://publictest5.fedoraproject.org/pkgs/kernel -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Tue, 2009-12-15 at 04:29 +, John5342 wrote: Gitosis which is already in fedora does a pretty good job of this including key based auth as well as multiple authorized users per git repo, gitweb interface etc. Might be a good starting point if you weren't already aware of it... gitosis was the first idea, which led me to a rewrite somebody has done, gitolite http://github.com/sitaramc/gitolite which I'm trying to bend to our will. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: parsecvs repo? [Re: Help wanted with dist-cvs to git conversion
On Sat, 2009-12-12 at 15:43 +0100, Jim Meyering wrote: Does anyone know of a public and *maintained* repository for parsecvs? I've looked numerous times (as recently as a few weeks ago), and tried to contact Keith Packard, hoping he would still be maintaining it, but have had no luck. Kristian Høgsberg has a repo for the changes he made and used for gnome conversion: http://cgit.freedesktop.org/~krh/parsecvs It is slightly newer than Keith's repo. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Help wanted with dist-cvs to git conversion
On Fri, 2009-12-11 at 08:12 -0500, Seth Vidal wrote: And let me put it this way: if fedora decides to post my non @fp.o address somewhere, like in git entries, I'm going to be extremely pissed off about it. I think this would depend on what gets configured for your git client for fedora package repos, probably another file in .fedora/. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora release criteria completely revised
On Fri, 2009-12-11 at 10:53 -0500, James Laska wrote: Not sure if this has been raised yet, but are we specifying when in the release that packages should be signed with a valid signature? I believe packages are signed at all release milestones, but I'd like to clear up that assumption. I have 3 answers for that. 1) if we get koji autosign builds working, every official build that comes out of koji will be signed automatically 2) failing that, if we get no frozen rawhide working right, every build will be signed once we branch away from rawhide as we'll be using bodhi to manage it. 3) failing that, the builds will be signed leading up to the release milestones. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Help wanted with dist-cvs to git conversion
I'm currently playing with a utility called parsecvs to convert our cvs stuff into git. This utility can also translate the raw usernames that CVS has into more useful names+email addresses that you'd typically get out of git. But to make this conversion it needs a translation file. It would be really helpful if somebody could generate a file for me that is in the format of: username=firstname lastname email eg: jkeating=Jesse Keating jkeat...@fedoraproject.org notting=Bill Nottingham nott...@fedoraproject.org For the initial testing, just giving every user a @feodraproject.org domain would be sufficient, however we should have a discussion about whether to use this email address or to use the user's real email address. Should be easy enough to get a list of users from FAS for this purpose. Thanks in advance! -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Help wanted with dist-cvs to git conversion
On Thu, 2009-12-10 at 22:00 -0600, Sir Gallantmon wrote: Is it even possible to get a listing of all the users so such a file could be generated? FAS should provide this information. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide and tagging requests
On Wed, 2009-12-09 at 06:43 -0800, Jesse Keating wrote: All the broken deps preventing a compose attempt have been cleared out. However the new rpm build was busted in a way that it made the compose fall over, a new build of rpm is coming and I hope to kick off another rawhide attempt when it lands. Ugh, things are still broken on the rpm front. My attempt from earlier fell over, may not get a fix in place for tonight's attempt either :/ -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Can I avoid the ppc builder?
On Sun, 2009-12-06 at 10:27 -0500, David Juran wrote: Hello. Is there a way I can keep my builds away from the ppc builders? I'm trying to push an update to my noarch (java) package (http://koji.fedoraproject.org/koji/taskinfo?taskID=1847061) but it seems to end up on a ppc64 builder and fail miserably )-: Now I promise I will try to dig in to the root cause of the build failure but since ppc no longer is a primary architecture, the failed build on PPC shouldn't hold up the release on the primary architectures. Not really, that is a bit of a problem. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Proposed F13 feature: drop separate updates repository
On Thu, 2009-12-03 at 06:51 +0100, Ralf Corsepius wrote: We wouldn't be talking about removing the original GA set - just adding updated pkgs into the path. Woa!!! With all due respect, but this would seem an stupid and silly plan to me. The only way not to do that would be to maintain yet another directory of packages that matches the GA set, for GPL compliance. Now we're just getting silly. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Dec 3, 2009, at 5:28, James Antill ja...@fedoraproject.org wrote: On Thu, 2009-12-03 at 10:29 +0100, Nicolas Mailhot wrote: Le Mer 2 décembre 2009 23:56, Matt Domsch a écrit : On Wed, Dec 02, 2009 at 07:35:03PM +0100, Nicolas Mailhot wrote: 3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org (make sure it works with web infrastructure instead of fighting it) Sorry, I don't understand this. Can you elaborate? That would help me scope the impact to MirrorManager. Right now the same package moves from master URL to master URL as it is pushed from testing to updates to GA to whatever. That means the same package gets downloaded many times over because it changed URL (and browsers, proxies, etc understand new url = new file) It only moves once, at least in the vast majority of cases. My proposal is to never move a package, put it in a single unchanging place after a koji build, and just index it or not in the relevant repodata when it gets promoted or demoted. One problem is that atm. when it moves from testing to updates, or rawhide to GA, it also gets resigned with a different key ... so the bits are not the same. Having the URL be the same will not be helpful until that changes. -- That is no longer true. We used a single key for all of f11 and a single key for all of f12. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Wed, 2009-12-02 at 15:52 -0500, Seth Vidal wrote: Isn't this, eventually, what the packagedb is supposed to be able to do? I gather it's a ls in a directory kind of thing, not an interface to one tool or another kind of thing. But I could be wrong. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Wed, 2009-12-02 at 16:58 -0600, Matt Domsch wrote: On Wed, Dec 02, 2009 at 11:09:41AM -0500, Bill Nottingham wrote: The separate Everything tree that does not get obsoleted is required in some form for GPL compliance, with respect to the ISO images that we ship. Any new solution would have to preserve this. ? We provide Fedora-*-source-disc*.iso and Fedora-*-source-DVD.iso images on the mirrors already. As stated elsewhere, that doesn't carry the packages found on all the live images we produce. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12: Emacs is not for software development
On Mon, 2009-11-30 at 11:26 -0500, Casey Dahlin wrote: On 11/28/2009 10:23 AM, Kevin Kofler wrote: Debayan Banerjee wrote: Well one does need an editor for development. Assuming vim and emacs have roughly equal user bases, chosing emacs over vim for the distribution shows Fedora packagers' personal preference too. I guess both vim and emacs should be available. Both vim and Emacs are obsolescent and hard to use. Kate FTW! Kevin Kofler On the contrary, they're both quite easy to use. They're just hard to learn. This is intentional. If you're smart enough to use a real man's editor then you're smart enough to send patches to other real men who are writing real men's software. We don't actually want just /anyone/ writing code, do we? (well, Java people do, but its impossible to do anything useful in Java anyway. That's why you need a gigantic resource-intensive IDE to do everything for you). --CJD I guess all the female hackers are just SOL? -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12: Emacs is not for software development
On Fri, 2009-11-27 at 16:06 -0500, Sam Varshavchik wrote: Let's say I want to do software development. I make an appropriate selection when intalling Fedora 12. What editor am I expected to use? The development group in comps does not list any editor by default. Those come from the Editors group. It does however list a number of optional emacs packages one could pick from when fine tuning the group selection. For better or worse, the default editor in the editors group is vim-enhanced. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
On Nov 26, 2009, at 6:01, Terry Barnaby ter...@beam.ltd.uk wrote: Ok, controversial title. I have just tried to test install F12 on some of my systems, (5 different ones). All of these bar 1 has problems with the graphics (X11 lockups, system lockups and other problems) mainly in 3D but also in 2D. I still am using F8 on most of my systems as the Graphics systems have not been stable enough for 3D in Fedora since around those times. I know there is a lot of work going on in the graphics front, I myself have worked on and fed back issues as time and ability allow. During F11 I helped with some issues, but unfortunately none of these made it back into updates for F11 and now F12 is out with yet more issues. The Linux kernel is generally relatively stable, as is the main system libraries etc in Fedora. The core issues most people seem to be facing is Graphics and Sound issues. Obviously a major issue with Graphics is the sheer number of different graphics chip sets in use and the lack of documentation for quite a few of them. Due to this it requires a lot of user testing and feedback to get these issues sorted out. Unfortunately the very fast Fedora new release schedule gets in the way of getting this testing done and things do not get fixed prior to a new release which introduces yet another set of problems. The new release speed also uses a lot of developer and user time in just managing to create a new release and updating systems to use it. I know the quick release cycle is one of Fedora's features in its aim to be close to the leading edge, but this has to be balanced with usability otherwise there will be few people actually using it in anger and thus actually testing the software. This could lead to the demise of Fedora. As an idea, at this stage, how about canceling the F13 release and just fixing and updating the F12 release ? This will concentrate developers and users into one system release. Similar to the pre- release test days we could have post-release test days. For example a Graphics test day for F12 where a certain set of tests with a test suite and a set of well known applications could be run. As F12 would be out longer, more people could participate in this. If a commitment, all round, to producing updates fixing the issues in F12 were made, I think more people would be willing to participate as users could expect to see a stable system for their efforts. You make the assumption that if fedora stopped, s -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
On Nov 26, 2009, at 6:01, Terry Barnaby ter...@beam.ltd.uk wrote: Ok, controversial title. I have just tried to test install F12 on some of my systems, (5 different ones). All of these bar 1 has problems with the graphics (X11 lockups, system lockups and other problems) mainly in 3D but also in 2D. I still am using F8 on most of my systems as the Graphics systems have not been stable enough for 3D in Fedora since around those times. I know there is a lot of work going on in the graphics front, I myself have worked on and fed back issues as time and ability allow. During F11 I helped with some issues, but unfortunately none of these made it back into updates for F11 and now F12 is out with yet more issues. The Linux kernel is generally relatively stable, as is the main system libraries etc in Fedora. The core issues most people seem to be facing is Graphics and Sound issues. Obviously a major issue with Graphics is the sheer number of different graphics chip sets in use and the lack of documentation for quite a few of them. Due to this it requires a lot of user testing and feedback to get these issues sorted out. Unfortunately the very fast Fedora new release schedule gets in the way of getting this testing done and things do not get fixed prior to a new release which introduces yet another set of problems. The new release speed also uses a lot of developer and user time in just managing to create a new release and updating systems to use it. I know the quick release cycle is one of Fedora's features in its aim to be close to the leading edge, but this has to be balanced with usability otherwise there will be few people actually using it in anger and thus actually testing the software. This could lead to the demise of Fedora. As an idea, at this stage, how about canceling the F13 release and just fixing and updating the F12 release ? This will concentrate developers and users into one system release. Similar to the pre- release test days we could have post-release test days. For example a Graphics test day for F12 where a certain set of tests with a test suite and a set of well known applications could be run. As F12 would be out longer, more people could participate in this. If a commitment, all round, to producing updates fixing the issues in F12 were made, I think more people would be willing to participate as users could expect to see a stable system for their efforts. You make the assumption that if fedora stopped, so would upstream. You also state that the kernel is stable, yet most of the graphics work is going on at the kernel level so we have to continue to bring in new kernels to pick up these changes. Graphics work is not a fedora issue alone. It is an upstream issue first and formost. By abandoning upstream and trying to stagnate will ultimatly damage upstreams ability to gennew changes tested and released. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
On Nov 26, 2009, at 9:27, Terry Barnaby ter...@beam.ltd.uk wrote: On 11/26/2009 05:05 PM, Jesse Keating wrote: On Nov 26, 2009, at 6:01, Terry Barnaby ter...@beam.ltd.uk wrote: Ok, controversial title. I have just tried to test install F12 on some of my systems, (5 different ones). All of these bar 1 has problems with the graphics (X11 lockups, system lockups and other problems) mainly in 3D but also in 2D. I still am using F8 on most of my systems as the Graphics systems have not been stable enough for 3D in Fedora since around those times. I know there is a lot of work going on in the graphics front, I myself have worked on and fed back issues as time and ability allow. During F11 I helped with some issues, but unfortunately none of these made it back into updates for F11 and now F12 is out with yet more issues. The Linux kernel is generally relatively stable, as is the main system libraries etc in Fedora. The core issues most people seem to be facing is Graphics and Sound issues. Obviously a major issue with Graphics is the sheer number of different graphics chip sets in use and the lack of documentation for quite a few of them. Due to this it requires a lot of user testing and feedback to get these issues sorted out. Unfortunately the very fast Fedora new release schedule gets in the way of getting this testing done and things do not get fixed prior to a new release which introduces yet another set of problems. The new release speed also uses a lot of developer and user time in just managing to create a new release and updating systems to use it. I know the quick release cycle is one of Fedora's features in its aim to be close to the leading edge, but this has to be balanced with usability otherwise there will be few people actually using it in anger and thus actually testing the software. This could lead to the demise of Fedora. As an idea, at this stage, how about canceling the F13 release and just fixing and updating the F12 release ? This will concentrate developers and users into one system release. Similar to the pre-release test days we could have post-release test days. For example a Graphics test day for F12 where a certain set of tests with a test suite and a set of well known applications could be run. As F12 would be out longer, more people could participate in this. If a commitment, all round, to producing updates fixing the issues in F12 were made, I think more people would be willing to participate as users could expect to see a stable system for their efforts. You make the assumption that if fedora stopped, so would upstream. You also state that the kernel is stable, yet most of the graphics work is going on at the kernel level so we have to continue to bring in new kernels to pick up these changes. Graphics work is not a fedora issue alone. It is an upstream issue first and formost. By abandoning upstream and trying to stagnate will ultimatly damage upstreams ability to gennew changes tested and released. -- Jes I'm not suggesting F12 should not be updated, in fact the opposite. As you state most of the Graphics work is being done up-stream, but it is the distributions role to package, release and allow users to test this and feed back bugs. I am saying that a focus on Graphics with a quick update cycle will help upstream get the testing they need and the users to get fixes. This is what rawhide is for. Rapid updates with fast feedback and upstream snapshots. It is not the role of a stable release to be grabbing upstream new stuff and throwing it at users without abandon. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFC] unified i386/x86_64 install media.
On Nov 24, 2009, at 22:49, Jeff Garzik jgar...@pobox.com wrote: On 11/25/2009 01:32 AM, Jesse Keating wrote: On Nov 24, 2009, at 19:30, Jeff Garzik jgar...@pobox.com wrote: On 11/24/2009 09:58 PM, Matthew Miller wrote: On Tue, Nov 24, 2009 at 09:19:22PM -0500, Jeff Garzik wrote: So would this mean one disk with two repositories on it, or is everything mashed together all in one repository? The current x86-64 has both 32-bit and 64-bit mashed together, so that sort of configuration would be more of the same. Well, it's currently only half-mashed. In Fedora 12, the i686 and x86-64 rpms are in the same directory, on the x86-64 DVD ISO. That's sufficiently mashed for my purposes, but whatever... :) Look closer. It is only a small subset of the i686 content in the x86_64 repo for multilib purposes. That's merely a space issue, not any failure to or absence of mash Jeff Wow. Ok let me be clear here. The 32 bit packages you see are specifically selected to fulfill a multilib role. We cannot put every package in as there would be lots of conflicts in the packages that are nit suitable for multilib. Please stop making assumptions about our compose process and strategy which you clearly don't understand. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 x86 DVD images
On Tue, 2009-11-24 at 10:38 +0100, Andrea Musuruane wrote: Hi all, some Fedora users just pointed me out that the x86 DVD image names are not accurate. The install DVD is called Fedora-12-i386-DVD.iso while the live DVD is called Fedora-12-i686-Live.iso. Please note the i386 text in the install DVD file name. This is creating some confusion among users because they tend to believe that packages are still compiled for i386 and not for i686. Bye. Andrea. The base arch of the family is i386, just like we call the ppc spin ppc even though it only supports a subset of the ppc family, ditto sparc, arm, etc... -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 x86 DVD images
On Tue, 2009-11-24 at 12:24 -0600, Sir Gallantmon wrote: Why not label it x86_32 instead of i386? That is far less confusing and illustrates that it is 32-bit on the x86 architecture, since x86_64 says it is 64-bit on x86 architecture. Because that's not what uname says. Change that, and then we'll talk. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 x86 DVD images
On Tue, 2009-11-24 at 20:38 +0100, Andrea Musuruane wrote: On Tue, Nov 24, 2009 at 5:22 PM, Jesse Keating jkeat...@redhat.com wrote: The base arch of the family is i386, just like we call the ppc spin ppc even though it only supports a subset of the ppc family, ditto sparc, arm, etc... Then why the Live DVD and the Install DVD have different names? And why the same is true for the directory labels (i386/ for install DVD and i686/ for live DVD)? Can we at least have some consistency? Thanks! Andrea. Yes, we may rename the Live images to i386. When they were first introduced, we had both an i586 and an i686 kernel in Fedora, and the Live images were only usable on i686, they had no i586. Now that we don't have i586 anymore, we can change the live image name to i386. It was too late to do this for F12 at the time somebody suggested it. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFC] unified i386/x86_64 install media.
On Tue, 2009-11-24 at 16:48 -0500, Adam Jackson wrote: On Tue, 2009-11-24 at 13:50 -0600, Dennis Gilmore wrote: syslinux would need to be able to detect the arch to install and likely also have a flag to force 32 bit we could easily implement the 64 bit kernel and 32 bit userland idea that was put forward a few releases ago. pungi will need to learn how to make the new iso. but i think it is achievable. As I'm actually trying this on one of the laptops on my desk, I'd point out that this almost certainly requires yum changes to work well. yum gets its idea of arch from uname, which reports what the kernel is, not what the current glibc is. Not that it's not a good idea - it seems to work surprisingly well - but it's not turnkey yet. - ajax From what I understand, this isn't about delivering a 64bit kernel and a 32bit userland. That's a different ball of fun. This is about having one single piece of media that can serve as either a 32bit install media, or a 64bit install media, and which you get would depend on the syslinux menu item you boot, which would be driven by what arch CPU you have (or forced by the user). That shouldn't require any yum hackery at all. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFC] unified i386/x86_64 install media.
On Nov 24, 2009, at 17:31, Matthew Miller mat...@mattdm.org wrote: On Tue, Nov 24, 2009 at 06:17:08PM -0600, Dennis Gilmore wrote: the goal for F-13 is to have unified media, for F-14 and beyond we could look at other options like having a 64 bit kernel and 32 bit userland. i should have stated that a bit more clearly So would this mean one disk with two repositories on it, or is everything mashed together all in one repository? -- Two repos, but with hardlinks. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFC] unified i386/x86_64 install media.
On Nov 24, 2009, at 19:30, Jeff Garzik jgar...@pobox.com wrote: On 11/24/2009 09:58 PM, Matthew Miller wrote: On Tue, Nov 24, 2009 at 09:19:22PM -0500, Jeff Garzik wrote: So would this mean one disk with two repositories on it, or is everything mashed together all in one repository? The current x86-64 has both 32-bit and 64-bit mashed together, so that sort of configuration would be more of the same. Well, it's currently only half-mashed. In Fedora 12, the i686 and x86-64 rpms are in the same directory, on the x86-64 DVD ISO. That's sufficiently mashed for my purposes, but whatever... :) Jeff Look closer. It is only a small subset of the i686 content in the x86_64 repo for multilib purposes. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Creating a trusted sha256sum.exe binary for verifying *-CHECKSUM files on Windows
On Tue, 2009-11-24 at 10:33 -0500, Todd Zullinger wrote: Some of you might be aware that the instructions for verifying our *-CHECKSUM files on Windows have been broken since we moved to SHA256. Previously, we linked users to a sha1sum.exe built by the GnuPG project. With SHA256, we don't have that ability. Fortunately, the good folks working on MingW have made it possible for us to build a sha256sum.exe from the coreutils sources. We can do this in koji even. (A huge thanks to Richard Jones for his help and patches.) Much of this is discussed at https://bugzilla.redhat.com/527060. I've created a simple mingw32-sha256sum package, built it in koji and tested it on the lone Windows XP system I have readily available. Of course, I just built this as a scratch build, so it will expire at some point. What I'm here for is to gather ideas for how to properly go about building the mingw32-sha256sum and keeping it around so that when I extract the sha256sum.exe and upload it to fedoraproject.org we will have the koji built rpm to compare the binary against. Otherwise, the whole process falls back to Trust that Todd didn't trojan the executable. And while I'd be flattered if folks had that much trust in me, I think it would be unwise to encourage or expect. :) (I really don't want to maintain the mingw32-sha256sum package for Fedora, as it's just a quick and dirty hack to built a small subset of of coreutils for Windows.) Thoughts? Well, if you have to use a tool from the project, to verify other bits from the project, the verification just became a lot less trusted. If you don't trust the bits you got from the project, why would you trust the tool the project gives you to verify the bits? Here use this tool to verify our bits. Trust us, we swear! -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Creating a trusted sha256sum.exe binary for verifying *-CHECKSUM files on Windows
On Tue, 2009-11-24 at 13:06 -0500, Todd Zullinger wrote: I believe that providing a sha256sum.exe via https://fp.o/ is surely an improvement over Download the .iso and hope it works or check it with some third-party checksum tool that we can't even hope to verify. I agree, I just wanted to point out the catch-22. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: livecds in the future
On Mon, 2009-11-23 at 15:51 -0500, Ben Williams wrote: If release engineering would like to release liveusb.iso for people to use to install or just to look at the new features, that is fine But from the #fedora channel the # of people installing off of the livecd images are very high (if you want to search the logs i am sure they can be provided, and yes the # installing useing the livecd.iso on usb is high as well.) the current livecd isos need to continue (yes i know the size sux, but not everyone has highspeed internet thats why they are downloading the livecd and not the dvd) I say if you want to offer more choice, that is great, but do not shoot yourself in the foot yet, for f13 we can always try a liveusb image as well as the livecd iso if someone is willing to help release engineering make this happen so much the better for all of us if the people wanting a localized spin step up and do and maintain one for your locale. -- Ben Williams Windows-Linux Specialist 460 McBryde Hall Blacksburg VA 24061-0123 540 231-2739 Given the amount of bandwidth it takes to keep a Fedora install up to date, the jump from 700M to 1.4G is not that big, and on par with the other bandwidth requirements of Fedora. For the really network starved, there is netinst.iso where you start with 200M~ and only download the specific packages you wish to install, minimally about 200 packages. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: livecds in the future
On Mon, 2009-11-23 at 22:56 +0100, Mathieu Bridon (bochecha) wrote: For the really network starved, there is netinst.iso where you start with 200M~ and only download the specific packages you wish to install, minimally about 200 packages. I think Ben is talking about /users/ with poor network access, the ones who come on IRC asking for help because they have trouble installing with the LiveCD. Not sure the netinst.iso would fit their needs... -- Mathieu Bridon (bochecha) The netinst.iso would involve less downloaded content than the 700M live image. How would it not fit their needs? -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Mon, 2009-11-23 at 14:08 -0800, Adam Williamson wrote: This list of packages would be what the QA team would test with regard to the security policy. We also believe there ought to be a process for maintaining this list, and additions to the packaging guidelines for any new package which would be on this list or any existing package for which a proposed change would add it to this list. We could also hook AutoQA into this process, to run additional tests on security-sensitive packages or alert us when a package change was submitted which added security-sensitive elements to an existing package. I would warn against trying to have a manual static list of packages here, same as crit-path. These packages need to be discoverable via software. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: livecds in the future
On Mon, 2009-11-23 at 14:57 -0800, John Reiser wrote: The netinst.iso would involve less downloaded content than the 700M live image. How would it not fit their needs? *IF* netinst.iso works the first time (no hardware failure, no user error, no user misunderstanding, no power failure, no ISP failure, no phoneline failure, no installer bug, no kernel bug, no X11 bug, ...), and *IF* the netinst.iso is used only once (only one machine, user doesn't change his mind, ...), then the 200MB netinst.iso (plus needed packages) does involve less downloading than a 700MB LiveCD. However, not so long ago my network connection was 150KB/s DSL, and I much preferred to download an entire 700MB CD (1.5 hrs) before installation instead of using netinst.iso. By experience, waiting for the entire CD was faster on average. Something would go wrong during the first install attempt, and I would have to start over. Or, I would install again on a different partition in order to compare two setups. Or, I would give the CD to a friend. The 700MB CD was a cache of time, and paid for itself after only *two* uses. -- And to wait for a 1.4G live image, you'd have to wait another 1.5 hours. When you're already waiting 1.5 hours, waiting 3 doesn't seem outrageous. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Mon, 2009-11-23 at 17:55 -0500, Matthias Clasen wrote: On Mon, 2009-11-23 at 14:08 -0800, Adam Williamson wrote: It's not QA's role to define exactly what the security policy should look like or what it should cover, but from the point of view of testing, what we really need are concrete requirements. The policy does not have to be immediately comprehensive - try and cover every possible security-related issue - to be valuable. Something as simple as spot's proposed list of things an unprivileged user must not be able to do - http://spot.livejournal.com/312216.html - would serve a valuable purpose here. I don't think spots list is too useful, unfortunately; discussing an abstract 'unprivileged user' without defining some roles and use cases doesn't make much sense to me. There is probably a difference between a guest account and a regular (non-admin) user in what I want them to be able to do; 'unprivileged user' does not allow that distinction. And there is certainly a difference between what a regular user is expected to be allowed on a family computer vs a university computer lab. Sure, I don't disagree, but I think we can take spots list and use it for the 'guest account'. Then you start picking things off the list as you move up the stack to 'university computer lab user (is that really much different from guest?)', to 'non-admin user', to 'admin user'. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Mon, 2009-11-23 at 18:06 -0500, Gregory Maxwell wrote: This isn't mutually exclusive with finer-grained elevations but would allow finer grained elevations to stay out of the default install: When additional privileged is needed, the system prompts you to authenticate via a secure prompt. At that point if you have the required credentials you could authorize the activity and, optionally, permit that account to perform the same operation in the future. This is precisely the dialog that has been removed from F12 and is not planned to be returned. -- Jesse Keating RHCE (http://jkeating.livejournal.com) Fedora Project (http://fedoraproject.org/wiki/JesseKeating) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) identi.ca (http://identi.ca/jkeating) signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Mon, 2009-11-23 at 14:08 -0800, Adam Williamson wrote: This list of packages would be what the QA team would test with regard to the security policy. We also believe there ought to be a process for maintaining this list, and additions to the packaging guidelines for any new package which would be on this list or any existing package for which a proposed change would add it to this list. We could also hook AutoQA into this process, to run additional tests on security-sensitive packages or alert us when a package change was submitted which added security-sensitive elements to an existing package. I would warn against trying to have a manual static list of packages here, same as crit-path. These packages need to be discoverable via software. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- Fedora-security-list mailing list Fedora-security-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-security-list
Re: Improve the way rpm decides what is newer
On Sat, 2009-11-21 at 08:16 -0800, Adam Williamson wrote: it has the problem that we'd have to do something horrible one time to switch to that system, of course, but that seems the 'cleanest' way to do it. I'm still not sure it's necessary. I think as Jesse does - any time this is broken indicates maintainer error, our work should focus on helping maintainers not make errors. Right, even if you do this horrible hack one day, the very next day we could have somebody submitting an update for f12 that is a major version newer than what gets put out on f13 and now you've got an upgrade in the form of a downgrade. Hope you didn't want to keep that data! -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On Nov 21, 2009, at 1:38, drago01 drag...@gmail.com wrote: On Sat, Nov 21, 2009 at 3:17 AM, Adam Williamson awill...@redhat.com wrote: On Sat, 2009-11-21 at 00:58 +0100, Christian Iseli wrote: Hi folks, I also got bitten by the FC11 packages 'newer' than FC12 hickup, and while going through the yum remove/add maneuver I pondered: - is there ever a time when, while upgrading from Fedora n to Fedora n+1 I would expect a package .fcn to be kept instead of getting the .fcn+1 instance ? My answer was: no So I wondered if there would be a simple way to make this happen regardless of whether a maintainer blunders and gets things slightly out of sync between the 2 or 3 current Fedora releases. To me, this is the wrong fix. The problem here isn't RPM's version comparison logic, which is perfectly sound. Instead of nerfing up RPM comparisons, which are already full of enough hidden mines, we should just improve Fedora's package versioning conventions so this doesn't happen, or at least happens less often. We should just use release epochs, people might hate them for whatever reasons, but they would easily prevent such issues from happing. Which sounds great until 3.0.1 goes out on f11 while 2.5 is out on f12. Really don't want to see that upgrade happen. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Question about tagging
On Thu, 2009-11-19 at 12:02 +, Mat Booth wrote: Exciting times. In your plan, what will be replacing CVS? If I had my way and did it today, git. Each package would be its own module, and each fedora release would be represented by a real branch in the git module. We'd have a userland tool, as part of fedora-packager, that would allow simple commands to clone the module (and get master, which would build things for rawhide), or clone the module and all its release branches and construct a directory layout much like dist-cvs is today. Build commands would be part of fedora-packager, not makefiles in every module. Decisions on where to build the package would be based on what branch is being built from, programatically so that we don't have to keep updating some file somewhere to figure it out. Maintainers would not tag themselves, as the buildsystem would build from git hashsums, and only successful builds would have a human readable tag applied to a given hashsum, and that would be done by the build system. There would be no need to translate %dist values on the local user's system. That's what I got so far, I'm hoping to walk through a typical scenario with folks at FUDCon to see how well my plan stands up. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Thu, 2009-11-19 at 06:50 +, Keith G. Robertson-Turner wrote: The desktop users on my network might have difficulty doing any of those things, since their desktop access is via VNC tunnelled through ssh. However, now it seems they can arbitrarily install software into /usr, on a server that is (for some of them) in a foreign country, because of something called PackageKit. That is incorrect, unless somehow your ssh tunneled VNC registers as local console login, which I doubt. In your case, none of your users would be allowed to install software/updates. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12: where did window properties go?
On Thu, 2009-11-19 at 10:01 -0500, Tom Lane wrote: Upstream change or not, you're pissing off users to save 59k out of however many gigabytes a minimal GNOME install is. I shouldn't really presume to speak for others, but for me focus-follows-mouse is wired into the fingertips --- it's not a negotiable UI change, it WILL cause me to leave a distro. Or stop using GNOME, if they are stupid enough to try to kill it altogether. You're making the assumption that the change was made to save space. It wasn't. I can't find the original thread right now, but it's part of a cleanup on configuration tools. Upstream felt it no longer necessary to expose this, our Fedora maintainer decided to make it available via a subpackage. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security policy oversight needed?
On Thu, 2009-11-19 at 10:05 -0500, Peter Jones wrote:
Mike's suggestion of a distro-wide policy is one way to do that, and on it's
face, it's certainly a lot more practical than a distro wide change control
board auditing for security relevant changes, or even sillier, expecting
package maintainers to identify when a change has security implications and
come asking what they should do. A command infrastructure does not fit
Fedora or Linux very well.
I think the policy should be in two parts, though. Mike's suggestion is good;
we need general guidelines as to what roles which classes of users are
expected
to fulfill. We probably also need some packaging policy for applications
providing escalated privileges via policy kit, like we already have for setuid
utilities.
I am in strong agreement here. A guiding (set of) polic{y,ies} is what
is needed, to help the maintainers who have control make decisions that
fit well with what the Fedora project (or individual spin) is trying to
offer. We don't need more rubber stamp meetings, just better
guidelines.
Should this be part of the Packaging guidelines, or a different set of
design guidelines?
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
signature.asc
Description: This is a digitally signed message part
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security policy oversight needed?
On Thu, 2009-11-19 at 13:05 +0100, Matěj Cepl wrote: Where do you see Fedora 12 Server Edition? Nowhere, because we don't have it. I was shouting whole morning on IRC to Server Spin folks about it, but I think we are really missing Server Spin. Something which wouldn't be useful as enterprise grade server (because we don't have enough long time support for Fedora; please, don't go into this flamewar now!), but as a project to develop such beast. And of course, it is yet another post, where I ask somebody else to do something, which I won't do :). We have a server spin, and it's boot.iso/netinst.iso. And no, I am not joking. Servers are installed by starting with the smallest possible package set to get the system booted and on the network, then adding the specific functionality you want the server to perform, such as http server, or mail server. Nothing more. It is the very essence of start from nothing, add what you want. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security policy oversight needed?
On Thu, 2009-11-19 at 09:14 -0500, Owen Taylor wrote: It doesn't work practically: configuration for packages needs to live with the package. Putting gigantic amounts of configuration into the %post of a kickstart file quickly becomes unmanageable. And the idea that we make configuration changes in the %post of the kickstart really falls part badly once people start upgrading their install to the next version of Fedora. Which is why you do it with specifically selected policy packages, and not trying to write out files in %post. Create a set of policy packages that define certain user cases, and pick from those as you construct a spin. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Vote for the bug (was Re: Local users get to play root?)
On Nov 19, 2009, at 13:51, Jeff Garzik jgar...@pobox.com wrote: Note to all... Please add your vote to https://bugzilla.redhat.com/show_bug.cgi?id=534047 (Active local console users get to install signed software on a machine they do not have the root password to) I agree with Rahul that it is less productive to +1 on this email thread. Jeff Yes because what we really need here is more noise... Please do /not/ pile on to the bug. It will not help no matter what your opinion is. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Vote for the bug (was Re: Local users get to play root?)
On Nov 19, 2009, at 17:15, Jeff Garzik jgar...@pobox.com wrote: On 11/19/2009 07:48 PM, Jesse Keating wrote: On Nov 19, 2009, at 13:51, Jeff Garzik jgar...@pobox.com wrote: Note to all... Please add your vote to https://bugzilla.redhat.com/show_bug.cgi?id=534047 (Active local console users get to install signed software on a machine they do not have the root password to) I agree with Rahul that it is less productive to +1 on this email thread. Yes because what we really need here is more noise... Please do /not/ pile on to the bug. It will not help no matter what your opinion is. huh? Are you not familiar with the concept of bugzilla votes? Try clicking on the '(vote)' link sometime. I'm familiar. I also know that it isn't goig to accomplish anything in this case. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Question about tagging
On Fri, 2009-11-20 at 00:50 +0100, Kevin Kofler wrote: And why can't all this be done with s/git/SVN/? All we really need apart from what CVS already provides is atomic commit IDs, to make the maintainers would not tag themselves part easily implementable. I don't see why SVN revision IDs wouldn't be as good as git hashsums for that. In fact, in principle, it could even be done with CVS, but instead of tagging a single revision ID, the build system would have to tag the revision ID it checked out for each file. Having atomic commits just allows dragging around just one revision ID instead of a set of IDs. With sufficient hackery it could be done with either svn or cvs, however many of our upstreams are moving or have moved to git, and there is a strong desire for our scm to follow suit. This really will wind up being decided by the person putting in the work to get it done, which at the moment is me. The added benefit of offline operation makes git even more appealing, and while I know you can hack svn into doing something like that, I'd rather go with something that is designed for it. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 2009-11-18 at 13:22 -0500, James Antill wrote: 7. And the most obvious one ... how hard is it to get a bad package into one of the repos. that the machine has enabled. Right, PK is counting on this being sufficiently difficult enough to prevent bad things from happening. While I'd like to think that, and would like to say that, I can't. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 2009-11-18 at 20:34 +0100, nodata wrote: If the servers are in locked racks and you require a reboot to get access to a grub prompt which is not password protected, then the outage would trip the monitoring system. The server is in a locked rack, but the console access to the server isn't? How far down the strawman path are where? -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
