Re: dist-git proof of concept phase 1 complete
On Tue, 2009-12-15 at 12:35 -0800, Toshio Kuratomi wrote: > master makes a lot of sense from a git perspective. devel (or rawhide) > makes sense from what we actually call the code that that branch eventually > makes. A symlink might alleviate the confusion but it could also add to it. > (For instance, I was operating in the kernel/devel branch but when I want to > git checkout -b devel git gives me a strange error.) > > I don't see a clear answer for what's best here, yet. :-( I think those of us who follow rawhide will quickly realize the change in naming (ok maybe a symbol is vaguely useful, and also needs to be explained somewhere when people inevitably ask) and move on. Conversely, someone who is new or hasn't followed "devel" branches before should just be able to use git how they have elsewhere and it should work. Summary: easier to make life easier for new developers. Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
RE: packages requiring me to reboot...
On Tue, 2009-12-15 at 12:01 -0600, Otto Haliburton wrote: > I am not sure what the argument is, factually there are packages that have > files open, locks and etc. that need to be shutdown to update, if they are > running and you replace the executable, doesn't mean that the memory image > is replaced. It is quicker and simpler to just reboot, also the list of the > packages that cause you to reboot is probably longer than the ones that are > flagged. I think that a reboot should be made whether necessary or not, > clears up a lot of grief. Wow. That's twice today that the suggestion of forcing the user to reboot whether they like it or not has been made. What a long way we've come since the early days :) Personally, I think a dialog box is pretty simple for most users (no forcing, just persuasion), and allows those who know what they're doing to ignore it. And obviously reducing the number of times you ask to just absolute necessity is a win-win. But please, no more forced reboot suggestions. This isn't MSFT. Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Once upon a time, Paul Jakma said: > My data-point is that I ran an x86-64 kernel on i386 F10 for a few > months until I got tired of yum not being able to update kernel > packages. The kernel side apparently works fine AFAICT. The .1% is > yum. No, it's the whole development environment. For example, if you need to build a kernel module, gcc on i386 is not capable of building for x86_64 (IIRC it isn't a gcc configuration issue, it is an issue with gcc itself). You could just always install the x86_64 gcc, but then you need all the development tools and libraries to match. "gcc hello.c" is going to generate native code, and native will still be x86_64, so you have to have the x86_64 shared libraries and support in place (and now you're back to a multilib system, which loses on RAM usage, disk space, install time, update downloads, etc.). Also, part of your justification was that in the "real world", people run some 32 bit anyway (like wine). Well, what happens with some of those "real world" binary modules people use, like nVidia? Do they work with a split 32/64 user/kernel space (and development stack somewhere in between)? If they don't, users are going to blame Fedora, not nVidia (or whoever else ships binary modules). Again, most of the Fedora people developing things like yum, anaconda, etc. don't appear to be interested in this; there just doesn't seem to be a significant benefit (okay, you save a little RAM, but for the majority of 64 bit systems, that isn't a big deal). If you think otherwise, nobody is stopping you from doing the work to make it happen, and if it proves to work and be a benefit, I bet it would be accepted. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages requiring me to reboot...
On 12/15/2009 12:42 PM, Seth Vidal wrote: > this is what colin and I talked about at fudcon in toronto. I just added > some code to yum so it returns to you a list of all pkgs on the system > that own a file that is currently open/used in a running process. > > should make that part of your lookup easier. > > YumBase.rpmdb.return_running_packages() > This seems to be compounding the problem rather than try9ing to avoid it all together. As an alternate suggestion: It may make a lot more sense, to instead install apps in a shadow directory (named by version for example) with the usual spot being a link to the right place. When installing a new one simply install it in the shadow area and flip the link. The existing running app will see home base in the same place and have zero problems. The last part is a clean up phase which could be deferred to reboot or perhaps something a little more clever. firefox will work perfectly if done this way for example. gene -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Wed, 16 Dec 2009, Paul Jakma wrote: My data-point is that I ran an x86-64 kernel on i386 F10 for a few months until I got tired of yum not being able to update kernel packages. The kernel side apparently works fine AFAICT. The .1% is yum. Oh, I don't quite remember the details, but I think libvirt also gets a bit confused when its 32bit and the kernel is 64. Another data-point is that I've used and developed on other 32/64 x86-64 systems for a number of years and those manage it just fine. It really shouldn't be hard, if you decide its worth supporting. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: Life is like an onion: you peel off layer after layer and then you find there is nothing in it. -- James Huneker -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Tue, 15 Dec 2009, Matthew Garrett wrote: And the remaining 0.1% of the work is probably the other 99.9% of the time. I think you massively underestimate the number of corner cases present in an utterly untested configuration. My data-point is that I ran an x86-64 kernel on i386 F10 for a few months until I got tired of yum not being able to update kernel packages. The kernel side apparently works fine AFAICT. The .1% is yum. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: Lots of folks confuse bad management with destiny. -- Frank Hubbard -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages requiring me to reboot...
Am 2009-12-15 17:50, schrieb Nathanael D. Noblet: Hello, I feel like there are an increasing number of packages requiring a system reboot. I'm wondering why. The following updates were installed today, and required a full system reboot. I can't seem to find any package in the list that I can conceivably see requiring a reboot, is it that PK doesn't have the concept of X logout vs reboot? Is it a bug in the packaging or PK or is there anything I can do/file to improve the situation? Dec 15 09:07:21 Updated: glib2-2.22.3-1.fc12.x86_64 Dec 15 09:07:23 Updated: mysql-libs-5.1.40-1.fc12.x86_64 Dec 15 09:07:23 Updated: gpm-libs-1.20.6-9.fc12.x86_64 Dec 15 09:07:25 Updated: mysql-5.1.40-1.fc12.x86_64 Dec 15 09:07:28 Updated: PyQt4-4.6.2-5.fc12.x86_64 Dec 15 09:07:32 Updated: mysql-server-5.1.40-1.fc12.x86_64 Dec 15 09:07:34 Updated: gpm-1.20.6-9.fc12.x86_64 Dec 15 09:07:37 Updated: 1:tk-8.5.7-3.fc12.x86_64 Dec 15 09:07:37 Updated: mpfr-2.4.1-5.fc12.x86_64 Dec 15 09:07:39 Updated: foomatic-4.0.3-5.fc12.x86_64 Dec 15 09:07:40 Updated: mysql-embedded-5.1.40-1.fc12.x86_64 Dec 15 09:07:41 Updated: glib2-2.22.3-1.fc12.i686 Dec 15 09:07:45 Updated: gtk2-2.18.4-3.fc12.x86_64 Dec 15 09:07:58 Updated: 1:gdm-2.28.1-25.fc12.x86_64 Dec 15 09:07:58 Updated: ibus-libs-1.2.0.20091204-2.fc12.x86_64 Dec 15 09:07:59 Updated: imsettings-libs-0.107.4-4.fc12.x86_64 Dec 15 09:08:02 Updated: glib2-devel-2.22.3-1.fc12.x86_64 Dec 15 09:08:07 Updated: yelp-2.28.1-1.fc12.x86_64 Dec 15 09:08:10 Updated: f-spot-0.6.1.5-1.fc12.x86_64 Dec 15 09:08:13 Updated: 1:xscreensaver-base-5.10-4.fc12.x86_64 Dec 15 09:08:13 Updated: 1:xscreensaver-gl-base-5.10-4.fc12.x86_64 Dec 15 09:08:16 Updated: gtk2-devel-2.18.4-3.fc12.x86_64 Dec 15 09:08:25 Updated: totem-2.28.4-1.fc12.x86_64 Dec 15 09:08:25 Updated: totem-nautilus-2.28.4-1.fc12.x86_64 Dec 15 09:08:27 Updated: 1:xscreensaver-gl-extras-5.10-4.fc12.x86_64 Dec 15 09:08:29 Updated: 1:xscreensaver-extras-5.10-4.fc12.x86_64 Dec 15 09:08:34 Updated: imsettings-0.107.4-4.fc12.x86_64 Dec 15 09:08:34 Updated: 1:gdm-user-switch-applet-2.28.1-25.fc12.x86_64 Dec 15 09:08:35 Updated: 1:gdm-plugin-fingerprint-2.28.1-25.fc12.x86_64 Dec 15 09:08:35 Updated: totem-mozplugin-2.28.4-1.fc12.x86_64 Dec 15 09:08:37 Updated: python-reportlab-2.3-1.fc12.x86_64 Dec 15 09:08:38 Updated: jna-3.2.4-1.fc12.x86_64 Dec 15 09:08:38 Updated: memcached-1.4.4-1.fc12.x86_64 Dec 15 09:08:38 Updated: less-436-3.fc12.x86_64 Dec 15 09:08:40 Updated: cscope-15.6-6.fc12.x86_64 Dec 15 09:08:40 Updated: xorg-x11-drv-mouse-1.5.0-1.fc12.x86_64 Dec 15 09:08:40 Updated: f-spot-screensaver-0.6.1.5-1.fc12.x86_64 Dec 15 09:08:46 Updated: gtk2-devel-docs-2.18.4-3.fc12.x86_64 Dec 15 09:08:46 Updated: gpm-devel-1.20.6-9.fc12.x86_64 Dec 15 09:08:46 Updated: liveusb-creator-3.9-1.fc12.noarch Dec 15 09:08:48 Updated: mysql-devel-5.1.40-1.fc12.x86_64 Dec 15 09:08:53 Updated: etoys-4.0.2339-1.fc12.noarch Dec 15 09:08:59 Updated: ibus-1.2.0.20091204-2.fc12.x86_64 Dec 15 09:08:59 Updated: ibus-gtk-1.2.0.20091204-2.fc12.x86_64 Wouldn't it be sufficient to logout? Is it a bug? I'd like for the icon that reboots to be more difficult to click on. Or to confirm. Or anything. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages requiring me to reboot...
On Tue, 15 Dec 2009 13:29:25 -0500 Bill Nottingham wrote: > Nathanael D. Noblet (nathan...@gnat.ca) said: > > I'm also curious why gdm is still running once I've logged in. > > When you start a display manager, you start an X server; the display > manager then draws on this. Then, when you log in, you have to > stat an user session, as the authenticated user (which has a connection > to the X server, so it can know when it goes away.) > > You also have to tell the init daemon which process it's supposed to > be tracking, so it can respawn it when it exits. > > Having that process be the gdm daemon (which forks and execs both > the X server and the user session) is arguably a lot simpler than > trying to architect it such that the daemon goes away entirely and > init then ends up tracking either the X serve or the user session. > > Bill > > Isn't GDM just doing a wait(2) on the user-session? Clark signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Tue, Dec 15, 2009 at 10:54 PM, Paul Jakma wrote: > On Tue, 15 Dec 2009, Paul Jakma wrote: > >> I would like to have the advantages of *both* 32 and 64bit, as and where >> each one is appropriate. I'd like to be able to use that 30-60% of memory on >> more VMs, e.g., rather than bigger gnome-*, etc. processes. > > Ah, and to get the memory benefits, you need a "generally-32bit" userspace > (32bit apps on x86-64 obviously works just fine, but there's no savings > benefit when most of userspace is 64bit). > > Sorry again for the noise. :) There are shops that sells stuff called "ram sticks" ;) (sorry I will shut up already) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Tue, 15 Dec 2009, Paul Jakma wrote: I would like to have the advantages of *both* 32 and 64bit, as and where each one is appropriate. I'd like to be able to use that 30-60% of memory on more VMs, e.g., rather than bigger gnome-*, etc. processes. Ah, and to get the memory benefits, you need a "generally-32bit" userspace (32bit apps on x86-64 obviously works just fine, but there's no savings benefit when most of userspace is 64bit). Sorry again for the noise. :) regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: Your own qualities will help prevent your advancement in the world. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Tue, Dec 15, 2009 at 10:28 PM, Paul Jakma wrote: > - I am incredulous at the people who keep arguing that "x86-64 is > better" because it has PC-relative addressing, or because the ABI > is pass-by-register by default. I am extremely sceptical that > these respondents would be able to distinguish between a 32bit > and a 64bit "cp" or "nautilus" or "ls" or "gnome-panel" or ... etc. > > It'd be interesting to see if this applied even to browsers. > (E.g. Chrome on 32bit is extremely fast, hard to see that it'd > get much faster on 64. Firefox is slow on 64bit too). Well while there was no x86_64 chromium build midori (which uses webkit) was faster in every JS while the whole web was praising google's V8 as the fastest JS engine ... Once the 64bit chromium come out, this was indeed the case. So a software that is supposed to be slower than another one was faster only because it was running an x86_64 version. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Tue, Dec 15, 2009 at 09:28:10PM +, Paul Jakma wrote: > And again, far from being some incredibly difficult thing that I'm > asking for, the support is pretty much 99.9% there.. And the remaining 0.1% of the work is probably the other 99.9% of the time. I think you massively underestimate the number of corner cases present in an utterly untested configuration. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Tue, 15 Dec 2009, Jon Masters wrote: But again, Apples to Oranges. x86_64 (we should formally call it "Intel 64", or similar, since I'm not aware of x86_64 having a formal blessing) doesn't have the fixed instruction width that you get on most RISC ISAs. It's not about the instruction set. If you look back at the posts, from myself and the poster who gave a toy test case, the extra memory usage is from data, not from programme text. Programme text is not too significant in size when compared to data (about a 10:1 data:text ratio for cases I've looked at). So the instructions being compact is simply not very relevant - pointers and longs in *data* double up in size on 64bit. (This transcends specific ISAs..). the US, but here at least someone drew my attention to a ludicrously cheap laptop on sale last weekend that also had 3GB of RAM installed. Right. I.e. a 64bit *kernel* is very useful (and much faster than a PAE one). That's precisely what I am arguing for. Again, there is a difference between aggregate usage (e.g. of RAM) and per-process memory requirements, similarly for performance. I.e. in the aggregate, a system can make good use of *both* 32 and 64 bit. I.e.: - In the aggregate, systems now need to make efficient use of >3GB of memory - PAE (slow, other problems) - 64bit - more and more systems have this, it'd be nice to be able to use this with a 32bit install. - On a per-process basis, few processes need 64bit pointers - those which do, can easily be 64bit on a 32/64 system. - those which can be 32bit can avoid a circa 30 to 60% memory overhead - On a per-process basis, few processes need the advantages of x86-64 - I am incredulous at the people who keep arguing that "x86-64 is better" because it has PC-relative addressing, or because the ABI is pass-by-register by default. I am extremely sceptical that these respondents would be able to distinguish between a 32bit and a 64bit "cp" or "nautilus" or "ls" or "gnome-panel" or ... etc. It'd be interesting to see if this applied even to browsers. (E.g. Chrome on 32bit is extremely fast, hard to see that it'd get much faster on 64. Firefox is slow on 64bit too). - those processes which do, can be 64bit I would like to have the advantages of *both* 32 and 64bit, as and where each one is appropriate. I'd like to be able to use that 30-60% of memory on more VMs, e.g., rather than bigger gnome-*, etc. processes. A lot of respondents have argued as if this is a binary matter, approaching the debate as if it's an either-or choice between 32 OR 64, which was not my intention at all. And again, far from being some incredibly difficult thing that I'm asking for, the support is pretty much 99.9% there.. Anyway :) Sorry for extending this thread, but it seemed I miscommunicated in previous emails and failed to get the basic points across properly. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: Seeing is believing. You wouldn't have seen it if you hadn't believed it. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: MariaDB and Fedora
On Tue, Dec 15, 2009 at 21:30:50 +0100, Benny Amorsen wrote: > > That will give you an installation with quite reasonable defaults > including Unix-socket connectivity. > > Of course then you discover all the PHP toys written for MySQL which > can't be told to connect a) by Unix sockets and b) without a username > and password. I am pretty sure Postgres also listens on the loopback interface by default. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wiki Feature Dashboard Additional Category
On 12/14/2009 11:45 PM, John Poelstra wrote: > You have an interesting idea about tagging feature pages needing an > owner. In reality that pretty much represents all the pages in > 'Category:FeaturePageIncomplete' If they had an active owner or > developer working on the feature they wouldn't be there. As somebody who's owned a feature page put into this category, I just don't think this is true at all. There are a couple of reasons for this. Certainly, the cost/benefit of working on updating the wiki, which can sometimes consume a significant amount of time, vs that of working on the feature itself skews heavily towards the decision to work on the feature instead of updating the page immediately, which means the Feature page on the wiki suffers. It's also useful, as a developer, to queue changes to the Feature page instead of re-editing it every time anything on it changes - it's just easier to work on one thing at a time. The form also puts a lot of burden on whomever is developing a feature (and maintaining the form), for several reasons, listed below. Some of these reasons are probably more true for people working in an RH office than for RH remotees or non-RH contributors. To wit: a) The form isn't especially clear - the field names are basically all you've got to go on, and they're not terribly descriptive. It's hard to know what put in several places, and many people have different expectations. If you don't get it right (and it's not possible to get it right) you wind up having people coming to tell you so on a fairly constant basis. And they'll conflict, of course. b) There's a strong pressure to update the forms *very often*, even for features which it's clear will be slow to make progress. c) There's not really a clear audience to the form. Is it for the general population of Fedora users? Fedora developers? FESCo? The Board? RH management? Clearly a feature that's submitted is queued for FESCo's approval, though it's still unclear as to why FESCo has to actually *approve* every feature, or is interested in doing so, especially since it's obvious to everybody that they *don't* approve every feature, nor would they be able to if everybody implementing a feature actually filled out a Feature page and submitted it. Thus raising item d: d) Some member of every group I listed above thinks they're not only the target audience for the form, but also that if there's something on it they don't understand or even just don't see, they're going to lose their livelihood if that's not rectified *immediately*. e) Many of the people mentioned in "d" seem to be basically unwilling to actually read the content of the form in order to get their question answered. If they think something is missing from "Benefit to Fedora", the odds are you'll get an email (or worse, they'll show up at your desk and interrupt you in real time) about the "Benefit to Fedora" section even if the confusion is easily solved by reading the "Summary" or "Detailed Description" sections. Which brings us to: f) There are several fields which are basically redundant. If neither "Summary" nor "Detailed description" adequately include at least some large amount of "Benefit to Fedora", then the form really just isn't filled in. Likewise, if "Scope", "Dependencies", and "User Experience" are left empty or are sparse, it's it's likely because the developer filling out the form thought that had been explained well enough already and was tired of explaining things repeatedly. g) There are fields that don't /actually/ have a purpose. You'll get complaints if "Documentation" is empty, but not if you put in link to a pdf that's irrelevant to the actual Feature. h) There are fields that are essentially punitive. Not every Feature needs a release note (though some would argue that it's the only reason to bother with the Feature process at all...), but if you don't put text there for one, you're back in email-flood land. And it's really there because we don't trust developers to actually submit things for the release notes, anyway. Yes, there's plenty of data to support the fact that we usually won't write release notes, but this isn't a very good way to fix that. It's certainly not a convenient place to track it - especially since you've got to put something in that field even before you've actually implemented the feature, when you basically can't possibly know what would go there. But if you don't put something there when you first propose the Feature, guess whatyour inbox looks like? i) There's a field that's just there for people who don't understand wikis, AFAICT. I randomly sampled some Features in Category:FeatureAcceptedF11 (since that's pretty stable data at this point in time) to see what they said for "Comments and Discussion". All of them just listed a link to the Feature page's "Talk:
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 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
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Tue, Dec 15, 2009 at 9:24 PM, Chris Adams wrote: > Once upon a time, Jon Masters said: >> But again, Apples to Oranges. x86_64 (we should formally call it "Intel >> 64", or similar, since I'm not aware of x86_64 having a formal blessing) > > "Intel 64" has no "formal blessing" either (it is Intel's marketing name > for their copy of AMD's instruction set). If you want to call it after > a vendor, it should be "AMD 64" anyway, since AMD created it. They > called it "x86-64" (which is where the "x86_64" name came from), until > marketing got in the way and they changed to "AMD 64". > > "Intel 64" is confusing anyway, since Intel has pushed multiple 64 bit > architectures. Also there is the x64 marketing bullshit floating around -- 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, 15 Dec 2009 16:05:07 -0500 Dave Jones 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. -- Hans Ulrich Niedermann -- 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, Dec 15, 2009 at 10:45:54AM -0800, Jesse Keating wrote: > 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". +1 > > 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 :/ I did the mistake with origin/devel for util-linux-ng upstream three years ago. People was confused. Now we use origin/master like all other projects. Karel -- Karel Zak -- 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, Dec 15, 2009 at 12:54:44PM -0800, Jesse Keating wrote: > 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. Right I see those too. But locally, there's just '* master', and all the private-* commits seem to have been squashed onto that. > What things that were CVS branches are you seeing on origin/master ? run git log, and see all the myoung commits for example. Dave -- 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: Yum "Cannot retrieve repository metadata" error
I have this problem too. I believe the problem is in libcurl 7.19.7-8.fc13. If I downgrade to curl/libcurl 7.19.6-10.fc12 the problem goes away. If I run from a command line: $ curl 'https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=i386' I now get: curl: (7) Failed to connect to 2610:28:200:1::fed0:2: Network is unreachable despite the fact that IPv6 is disabled. The ifcfg script includes IPV6INIT=no. $ ifconfig eth1 Link encap:Ethernet HWaddr 00:0C:29:38:C9:7E inet addr:10.117.25.148 Bcast:10.117.25.255 Mask:255.255.255.0 inet6 addr: fe80::20c:29ff:fe38:c97e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1184 errors:0 dropped:0 overruns:0 frame:0 TX packets:1487 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:541164 (528.4 KiB) TX bytes:137185 (133.9 KiB) Interrupt:19 Base address:0x10a4 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:40 errors:0 dropped:0 overruns:0 frame:0 TX packets:40 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:2000 (1.9 KiB) TX bytes:2000 (1.9 KiB) My understanding is that Scope:Link means that is it can not be used for internet access. All other networking appears normal and works okay. -- 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, Dec 14, 2009 at 08:22:09PM -0800, Jesse Keating wrote: > 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 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. Dave -- 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
Already discussed later in thread. Sorry for unnecessary noise. -- Lorenzo Villani 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 Tuesday 15 December 2009 07:33:58 Jesse Keating wrote: > > Right now? Not all that hard. You'd have to write a script that has > all the package names and just cycles over them cloning them one by one. > Once we start working on fpkg we'll likely wire something up that gets a > list of active packages from pkgdb and does the cycle for you. It'd > just be slow. > What about a 'meta-module' referencing all packages using git submodules? -- Lorenzo Villani 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, Dec 15, 2009 at 10:22:35AM -0800, Jesse Keating wrote: > 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 > master makes a lot of sense from a git perspective. devel (or rawhide) makes sense from what we actually call the code that that branch eventually makes. A symlink might alleviate the confusion but it could also add to it. (For instance, I was operating in the kernel/devel branch but when I want to git checkout -b devel git gives me a strange error.) I don't see a clear answer for what's best here, yet. :-( -Toshio pgplCdosPYly5.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: MariaDB and Fedora
Nathanael Noblet writes: > However the setup/configuration of postgreSQL compared to MySQL is > basically something easy, versus something where I don't have a clue > what is going on, and there are million ways to do it, and when I'm > done I have no idea if I'm wide open to the entire world, or as secure > as on MySQL. We're on a Fedora list here. Setting up PostgreSQL consists of doing yum install postgresql-server, chkconfig postgresql on, service postgresql start. That will give you an installation with quite reasonable defaults including Unix-socket connectivity. Of course then you discover all the PHP toys written for MySQL which can't be told to connect a) by Unix sockets and b) without a username and password. /Benny -- 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ä 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: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Once upon a time, Jon Masters said: > But again, Apples to Oranges. x86_64 (we should formally call it "Intel > 64", or similar, since I'm not aware of x86_64 having a formal blessing) "Intel 64" has no "formal blessing" either (it is Intel's marketing name for their copy of AMD's instruction set). If you want to call it after a vendor, it should be "AMD 64" anyway, since AMD created it. They called it "x86-64" (which is where the "x86_64" name came from), until marketing got in the way and they changed to "AMD 64". "Intel 64" is confusing anyway, since Intel has pushed multiple 64 bit architectures. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Tue, 2009-12-15 at 16:54 +, Paul Jakma wrote: > On Mon, 14 Dec 2009, Chris Adams wrote: > > > Have you actually shown any concrete benefits, or has it all just been > > hand-waving? > > Well, the benefits were already known from the introduction of 64bit > systems in the mid 90s. E.g. a rule of thumb with AXP systems was > that they required at least 30% odd more RAM, compared to other Unix > systems (either 32bit, or 32-userspace/64kernel systems - which is > what most of the other Unix RISC vendors went with when they went to > 64bit CPUs). But again, Apples to Oranges. x86_64 (we should formally call it "Intel 64", or similar, since I'm not aware of x86_64 having a formal blessing) doesn't have the fixed instruction width that you get on most RISC ISAs. Not that any of it matters when we're already creeping up the minimum memory requirements over time and not so interested in older hardware anyway (e.g. recent i586/i686 changes). I know not everyone is living in the US, but here at least someone drew my attention to a ludicrously cheap laptop on sale last weekend that also had 3GB of RAM installed. I think we should treat it like migrating to i686 and once everyone has a 64-bit capable (x86) CPU just plan to do a gradual migration over. Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FUDConF13 videos
On Tue, 2009-12-15 at 09:31 -0600, Matt Domsch wrote: > If anyone else has video or audio from this or other Fedora events > you'd care to share, please contact me and I'll help you get it into > proper ogg format, tagged, and posted to Fedora Infrastructure servers > for distribution. You rock :) Jon. -- 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
Once upon a time, Ville Skyttä 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 -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- 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 Tuesday 15 December 2009, Jesse Keating wrote: > fpkg checkout --full kernel > fpkg checkout kernel > fpkg checkout F-12 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. http://foxlx.acmesystems.it/?id=157 http://www.freshports.org/sysutils/fpkg/ -- 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, 14 Dec 2009, 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. pkgs/rpms//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. Having trouble cloning at the moment, but wanting to take a look at a few packages in git. Are there any plans to import history back to FC-1? Since we're changing version control systems, it's a nice opportunity to get this in to the version control system. Complete history is nice to have on occassion. 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/ 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. -- David Cantrell Red Hat / Honolulu, HI -- 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 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
Jesse Keating wrote: > 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 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, 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. 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. -- ToddOpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ A thing worth having is a thing worth cheating for. -- W. C. Fields pgpp64s7GYmWK.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages requiring me to reboot...
Nathanael D. Noblet (nathan...@gnat.ca) said: > I'm also curious why gdm is still running once I've logged in. When you start a display manager, you start an X server; the display manager then draws on this. Then, when you log in, you have to stat an user session, as the authenticated user (which has a connection to the X server, so it can know when it goes away.) You also have to tell the init daemon which process it's supposed to be tracking, so it can respawn it when it exits. Having that process be the gdm daemon (which forks and execs both the X server and the user session) is arguably a lot simpler than trying to architect it such that the daemon goes away entirely and init then ends up tracking either the X serve or the user session. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Le mardi 15 décembre 2009 à 16:54 +, Paul Jakma a écrit : > I personally think the model used by many Unixes from the 90s makes a > lot of sense - 32bit userpace by default, 64bit kernel, 64bit for a > select few applications that actually need the benefits of x86_64 > (memory/bit more performance), but hey.. Apples and oranges. 64bit on other arches only changes memory accesses, x86_64 changes a lot more than just that, and the other changes in x86_64 trump the memory costs. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- 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
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") -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- 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
Jesse Keating wrote: > 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. 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. -- ToddOpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ I figure that if God actually does exist, He's big enough to understand an honest difference of opinion. -- Isaac Asimov pgpnnBBwOmeGC.pgp Description: PGP signature -- 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 > ". > > 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
Andreas Schwab wrote: > There are also author names that where expanded to "user > ". These are for accounts that have set the private flag, so their name and other data is not available. (Nevermind that they end up putting a name in the rpm changelog most of the time.) -- ToddOpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ Ambition is a poor excuse for not having enough sense to be lazy. pgpPZdGINf6SH.pgp Description: PGP signature -- 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
Jesse Keating writes: > 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 ". There are also author names that where expanded to "user ". Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different." -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
RE: packages requiring me to reboot...
> -Original Message- > From: fedora-devel-list-boun...@redhat.com [mailto:fedora-devel-list- > boun...@redhat.com] On Behalf Of Colin Walters > Sent: Tuesday, December 15, 2009 11:44 > To: Development discussions related to Fedora > Subject: Re: packages requiring me to reboot... > > On Tue, Dec 15, 2009 at 5:40 PM, Richard Hughes > wrote: > > 2009/12/15 Seth Vidal : > >> Now, having said that - how would you feel if the updater stopped you > before > >> it ran and said "you're running an app I'm trying to update, please > close > >> the app so I can update it". Would that be a pain or ok? > > > > That's exactly the PackageKit functionality I've added for packages > > like firefox, that explode internally when they get updated. The trick > > it to offer to close them down, and bring them back when done. > > > This exists? Can you point me to the code? > > -- I am not sure what the argument is, factually there are packages that have files open, locks and etc. that need to be shutdown to update, if they are running and you replace the executable, doesn't mean that the memory image is replaced. It is quicker and simpler to just reboot, also the list of the packages that cause you to reboot is probably longer than the ones that are flagged. I think that a reboot should be made whether necessary or not, clears up a lot of grief. > 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: 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 " 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 ". 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 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 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: packages requiring me to reboot...
On Tue, Dec 15, 2009 at 5:40 PM, Richard Hughes wrote: > 2009/12/15 Seth Vidal : >> Now, having said that - how would you feel if the updater stopped you before >> it ran and said "you're running an app I'm trying to update, please close >> the app so I can update it". Would that be a pain or ok? > > That's exactly the PackageKit functionality I've added for packages > like firefox, that explode internally when they get updated. The trick > it to offer to close them down, and bring them back when done. > This exists? Can you point me to the code? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages requiring me to reboot...
On Tue, 15 Dec 2009, Richard Hughes wrote: 2009/12/15 Seth Vidal : Now, having said that - how would you feel if the updater stopped you before it ran and said "you're running an app I'm trying to update, please close the app so I can update it". Would that be a pain or ok? That's exactly the PackageKit functionality I've added for packages like firefox, that explode internally when they get updated. The trick it to offer to close them down, and bring them back when done. this is what colin and I talked about at fudcon in toronto. I just added some code to yum so it returns to you a list of all pkgs on the system that own a file that is currently open/used in a running process. should make that part of your lookup easier. YumBase.rpmdb.return_running_packages() -sv -- 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: packages requiring me to reboot...
On 15/12/09 16:50, Nathanael D. Noblet wrote: > Hello, > I feel like there are an increasing number of packages requiring a > system reboot. I'm wondering why. The following updates were installed > today, and required a full system reboot. I can't seem to find any > package in the list that I can conceivably see requiring a reboot, is it > that PK doesn't have the concept of X logout vs reboot? Is it a bug in > the packaging or PK or is there anything I can do/file to improve the > situation? > > Personally, I just update, ignore the "restart". Shut-down going to bed. Or keep the updates, till bedtime. -- Regards, Frank Murphy UTF_8 Encoded. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages requiring me to reboot...
On Tue, 2009-12-15 at 10:00 -0700, Nathanael D. Noblet wrote: > On 12/15/2009 09:54 AM, Seth Vidal wrote: > > > Does gdm entirely restart when you logout? I don't believe so. I suspect > > you get the same result by killing X then going back to that runlevel > > but for many many many users a reboot is going to be less error-prone. > > Isn't there gdm-restart for that purpose? I don't really know, but I'm > just confused as to why a program that lets me login requires a reboot... > > I *really* don't want to sound whiny or anything like that, or be one of > those that compare us to windows... but one of my favorite things from > years ago was that I only had to reboot with a new kernel. Now I feel > like I reboot every update. I mean, even the ibus stuff was stating I > needed a reboot. As far as I know that is used for alternative language > input, which I don't use, fair enough it doesn't know that. But what > about it needs a reboot? Because often you cannot tell if a reboot is required or not. Consider a shared library which gets updated. If the old version of the library contains a security bug and you have already say ten apps running using that library, then after the update of the library the apps will still use the old buggy library. Only after closing and restarting the particular apps will help. From a novice point of view you cannot expect that he/she knows what app to close, so a restart is probably the easiest and safest way. Another problem may raise up if you want to update daemons. During the update the daemon shouldn't be restarted because it might be a critical service I'm using right now. Therefore, having a convenient way for novices is just to say "please restart". For all others, just check what gets updated and then decide on your own if you really need to restart the whole system or only some apps/services and then klick on "hide this icon" ;-) Coming back to your fist post: > Wouldn't it be sufficient to logout? In some cases I would say so, but not in all. cheers, Stefan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages requiring me to reboot...
2009/12/15 Seth Vidal : > Now, having said that - how would you feel if the updater stopped you before > it ran and said "you're running an app I'm trying to update, please close > the app so I can update it". Would that be a pain or ok? That's exactly the PackageKit functionality I've added for packages like firefox, that explode internally when they get updated. The trick it to offer to close them down, and bring them back when done. Richard. -- 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: packages requiring me to reboot...
On Tue, 15 Dec 2009, Nathanael D. Noblet wrote: On 12/15/2009 09:54 AM, Seth Vidal wrote: Does gdm entirely restart when you logout? I don't believe so. I suspect you get the same result by killing X then going back to that runlevel but for many many many users a reboot is going to be less error-prone. Isn't there gdm-restart for that purpose? I don't really know, but I'm just confused as to why a program that lets me login requires a reboot... I *really* don't want to sound whiny or anything like that, or be one of those that compare us to windows... but one of my favorite things from years ago was that I only had to reboot with a new kernel. Now I feel like I reboot every update. I mean, even the ibus stuff was stating I needed a reboot. As far as I know that is used for alternative language input, which I don't use, fair enough it doesn't know that. But what about it needs a reboot? I'm also curious why gdm is still running once I've logged in. I see the user-switch stuff but I'm just wondering. I mean rebooting isn't the end of the world but man it sure happens a lot now I don't have a good answer. You might want to ask on the fedora-desktop-list and/or in a bug for that component. I was just trying to explain the specific behavior you saw. Now, having said that - how would you feel if the updater stopped you before it ran and said "you're running an app I'm trying to update, please close the app so I can update it". Would that be a pain or ok? -sv -- 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 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 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
KDE-SIG weekly report (51/2009)
This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply to this email or add it to the related meeting page. -- = Weekly KDE Summary = Week: 51/2009 Time: 2009-12-15 14:00 UTC Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-12-15 Meeting minutes: http://meetbot.fedoraproject.org/fedora- meeting/2009-12-15/fedora-meeting.2009-12-15-14.08.html Meeting log: http://meetbot.fedoraproject.org/fedora- meeting/2009-12-15/fedora-meeting.2009-12-15-14.08.log.html -- = Participants = * BenBoeckel * JaroslavReznik * KevinKofler * RexDieter * SebastianVahl * ThanNgo -- = Agenda = * kde-4.3.4 status * KDE Rebranding * multilibbing KCMs, i.e. putting them into the -libs subpackages (KCMs can be embedded into applications; if embedded into a 32-bit app, the 32-bit KCM is needed) = Summary = KDE 4.3.4 status: * Update for F-12 will be queued for updates-testing asap. [1] * LukasTinkl was working on updates for F-11. * Early adopters could use kde-testing (at kde-redhat) in the meantime. KDE Rebranding (#547361): [2] * Since upstream proposed a rebranding we have to adopt the new name at various places: o SPECs (JaroslavReznik, RexDieter, ThanNgo) o comps.xml o Wiki (JaroslavReznik) o Spins page (JaroslavReznik) multilibbing KCMs: * KCMs (KDE Configuration Modules, used in System Settings and in the preferences of some applications) will be moved to the -libs subpackages so 32-bit multilibs will be provided. * KParts will need a similar treatment. -- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-12-22 -- = Links = [1] http://tinyurl.com/kde434-f12-2 [2] https://bugzilla.redhat.com/show_bug.cgi?id=547361 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: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
> I personally think the model used by many Unixes from the 90s makes a lot of > sense - 32bit userpace by default, 64bit kernel, 64bit for a select few > applications that actually need the benefits of x86_64 (memory/bit more > performance), but hey.. Assuming this was the case and somebody decided to install (say) a 64 bit Epiphany then she will end up with two copies of the entire GNOME stack. That will come with its own storage and network costs, among other things. Running the 64-bit Epiphany will cause two copies of shared libraries to be kept in memory. Is this really worth it? Cheers, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages requiring me to reboot...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 15.12.2009 18:00, Nathanael D. Noblet napsal(a): > On 12/15/2009 09:54 AM, Seth Vidal wrote: > >> Does gdm entirely restart when you logout? I don't believe so. I suspect >> you get the same result by killing X then going back to that runlevel >> but for many many many users a reboot is going to be less error-prone. > > Isn't there gdm-restart for that purpose? I don't really know, but I'm > just confused as to why a program that lets me login requires a reboot... > > I *really* don't want to sound whiny or anything like that, or be one of > those that compare us to windows... but one of my favorite things from > years ago was that I only had to reboot with a new kernel. Now I feel > like I reboot every update. I mean, even the ibus stuff was stating I > needed a reboot. As far as I know that is used for alternative language > input, which I don't use, fair enough it doesn't know that. But what > about it needs a reboot? > > I'm also curious why gdm is still running once I've logged in. I see the > user-switch stuff but I'm just wondering. I mean rebooting isn't the end > of the world but man it sure happens a lot now > +1 - -- Nikola Pajkovsky .~. Base Operating Systems Brno /V\ // \\ Jabber: ni...@isgeek.info /( )\ Mobile: +420 777 895 064 ^`~'^ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLJ8J+AAoJED4+/Vgo+H2XtUsIAIzOIdfL5OVS92bLJvFe9Vny RCGKnlnG2TkEztpNZPu0AyU8nNOxAmH5+w+uAmvEpD6jmh5F7QlrSVTJLSamL76G fjWmeuz+4EreSSKwhemlbr7p6vB/CxPkIcivOVYK4OscI7LwJGAQTK74661QvoWr 9BXAP+Wd3KaNere3Ckg4iamSwBDLjSf2fVmVUJjGL4CYnX/mJVnWm7V7VnHy0Rgr lvM9fBUiJAuhOEH5xYScdTdmHmcefDfia1PmlMPVmG7mHlrIxXRF04KhyIJlwirK nEj6mXQk2m0M+KO6zBoV78ROgY4xYk/RmyYbT8icOeojH12pJgo1KZWQ+89iPkI= =Qe52 -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FUDConF13 videos
On Tue, Dec 15, 2009 at 09:31:39AM -0600, Matt Domsch wrote: > 2) The last 20 minutes of the Fedora Infrastructure: Sysadmins >vs. Developers love-in. I'm grateful to whoever shot this, but >I've complete blanked on who it was now. I'll be glad to give you >attribution, please remind me! > > http://alt.fedoraproject.org/pub/alt/videos/2009/FUDConF13/fudconf13-infrastructure-roundtable.ogg Of course, that was Adam Williamson who made this video. Thanks Adam! -Matt -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages requiring me to reboot...
On 12/15/2009 09:54 AM, Seth Vidal wrote: Does gdm entirely restart when you logout? I don't believe so. I suspect you get the same result by killing X then going back to that runlevel but for many many many users a reboot is going to be less error-prone. Isn't there gdm-restart for that purpose? I don't really know, but I'm just confused as to why a program that lets me login requires a reboot... I *really* don't want to sound whiny or anything like that, or be one of those that compare us to windows... but one of my favorite things from years ago was that I only had to reboot with a new kernel. Now I feel like I reboot every update. I mean, even the ibus stuff was stating I needed a reboot. As far as I know that is used for alternative language input, which I don't use, fair enough it doesn't know that. But what about it needs a reboot? I'm also curious why gdm is still running once I've logged in. I see the user-switch stuff but I'm just wondering. I mean rebooting isn't the end of the world but man it sure happens a lot now -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages requiring me to reboot...
On Tue, 15 Dec 2009, Nathanael D. Noblet wrote: Hello, I feel like there are an increasing number of packages requiring a system reboot. I'm wondering why. The following updates were installed today, and required a full system reboot. I can't seem to find any package in the list that I can conceivably see requiring a reboot, is it that PK doesn't have the concept of X logout vs reboot? Is it a bug in the packaging or PK or is there anything I can do/file to improve the situation? Dec 15 09:07:21 Updated: glib2-2.22.3-1.fc12.x86_64 Dec 15 09:07:23 Updated: mysql-libs-5.1.40-1.fc12.x86_64 Dec 15 09:07:23 Updated: gpm-libs-1.20.6-9.fc12.x86_64 Dec 15 09:07:25 Updated: mysql-5.1.40-1.fc12.x86_64 Dec 15 09:07:28 Updated: PyQt4-4.6.2-5.fc12.x86_64 Dec 15 09:07:32 Updated: mysql-server-5.1.40-1.fc12.x86_64 Dec 15 09:07:34 Updated: gpm-1.20.6-9.fc12.x86_64 Dec 15 09:07:37 Updated: 1:tk-8.5.7-3.fc12.x86_64 Dec 15 09:07:37 Updated: mpfr-2.4.1-5.fc12.x86_64 Dec 15 09:07:39 Updated: foomatic-4.0.3-5.fc12.x86_64 Dec 15 09:07:40 Updated: mysql-embedded-5.1.40-1.fc12.x86_64 Dec 15 09:07:41 Updated: glib2-2.22.3-1.fc12.i686 Dec 15 09:07:45 Updated: gtk2-2.18.4-3.fc12.x86_64 Dec 15 09:07:58 Updated: 1:gdm-2.28.1-25.fc12.x86_64 Dec 15 09:07:58 Updated: ibus-libs-1.2.0.20091204-2.fc12.x86_64 Dec 15 09:07:59 Updated: imsettings-libs-0.107.4-4.fc12.x86_64 Dec 15 09:08:02 Updated: glib2-devel-2.22.3-1.fc12.x86_64 Dec 15 09:08:07 Updated: yelp-2.28.1-1.fc12.x86_64 Dec 15 09:08:10 Updated: f-spot-0.6.1.5-1.fc12.x86_64 Dec 15 09:08:13 Updated: 1:xscreensaver-base-5.10-4.fc12.x86_64 Dec 15 09:08:13 Updated: 1:xscreensaver-gl-base-5.10-4.fc12.x86_64 Dec 15 09:08:16 Updated: gtk2-devel-2.18.4-3.fc12.x86_64 Dec 15 09:08:25 Updated: totem-2.28.4-1.fc12.x86_64 Dec 15 09:08:25 Updated: totem-nautilus-2.28.4-1.fc12.x86_64 Dec 15 09:08:27 Updated: 1:xscreensaver-gl-extras-5.10-4.fc12.x86_64 Dec 15 09:08:29 Updated: 1:xscreensaver-extras-5.10-4.fc12.x86_64 Dec 15 09:08:34 Updated: imsettings-0.107.4-4.fc12.x86_64 Dec 15 09:08:34 Updated: 1:gdm-user-switch-applet-2.28.1-25.fc12.x86_64 Dec 15 09:08:35 Updated: 1:gdm-plugin-fingerprint-2.28.1-25.fc12.x86_64 Dec 15 09:08:35 Updated: totem-mozplugin-2.28.4-1.fc12.x86_64 Dec 15 09:08:37 Updated: python-reportlab-2.3-1.fc12.x86_64 Dec 15 09:08:38 Updated: jna-3.2.4-1.fc12.x86_64 Dec 15 09:08:38 Updated: memcached-1.4.4-1.fc12.x86_64 Dec 15 09:08:38 Updated: less-436-3.fc12.x86_64 Dec 15 09:08:40 Updated: cscope-15.6-6.fc12.x86_64 Dec 15 09:08:40 Updated: xorg-x11-drv-mouse-1.5.0-1.fc12.x86_64 Dec 15 09:08:40 Updated: f-spot-screensaver-0.6.1.5-1.fc12.x86_64 Dec 15 09:08:46 Updated: gtk2-devel-docs-2.18.4-3.fc12.x86_64 Dec 15 09:08:46 Updated: gpm-devel-1.20.6-9.fc12.x86_64 Dec 15 09:08:46 Updated: liveusb-creator-3.9-1.fc12.noarch Dec 15 09:08:48 Updated: mysql-devel-5.1.40-1.fc12.x86_64 Dec 15 09:08:53 Updated: etoys-4.0.2339-1.fc12.noarch Dec 15 09:08:59 Updated: ibus-1.2.0.20091204-2.fc12.x86_64 Dec 15 09:08:59 Updated: ibus-gtk-1.2.0.20091204-2.fc12.x86_64 Wouldn't it be sufficient to logout? Is it a bug? Does gdm entirely restart when you logout? I don't believe so. I suspect you get the same result by killing X then going back to that runlevel but for many many many users a reboot is going to be less error-prone. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, 14 Dec 2009, Chris Adams wrote: Have you actually shown any concrete benefits, or has it all just been hand-waving? Well, the benefits were already known from the introduction of 64bit systems in the mid 90s. E.g. a rule of thumb with AXP systems was that they required at least 30% odd more RAM, compared to other Unix systems (either 32bit, or 32-userspace/64kernel systems - which is what most of the other Unix RISC vendors went with when they went to 64bit CPUs). E.g., a fresh F12 install: 32bit free -m: used +/- buffers/cache at gdm: 71 logged into desktop: 123 +firefox:183 +OO writer: 203 64bit: at gdm: 113 logged in: 159 Unfortunately, I couldn't get the 64bit one past "logged in" and even then I couldn't get it to display a useful desktop (good bit of GNOME stuff was running, but nothing shown), so it's probably under-representative. That shows a 59% increase for "at GDM", and at least a 29% increase for "logged into desktop". However, to be fair, that's probably /over/-representing the difference, as I didn't do much with any applications. Pure data, like the contents of webpages, your email, etc.. doesn't contain arch-dependent variable width data like pointers. That said, attendent meta-data (e.g. mail indices, data structures for the layout of your rendered webpage, etc..) may have arch-dependent variable-width data. So I'd expect that that 60% figure would go down a bit if you really used the system. I would expect a memory increase, due to 64bit, of somewhere between 30 and 60%, depending on system - or a saving of between 23 to 38%. I can't do this test as running F12 x86-64 under Qemu is just too damn slow, even if did finish login successfully. If someone wants to replicate the above with KVM on x86_64: 1. Install F12 2. After the first boot, reboot again, to eliminate the run of 'firstboot' 3a. login via ssh 3b. login via GDM 4. start firefox 5. switch to the 2nd desktop 6. start oowriter Use the SSH session to note the memory usage with 'free -m' after steps 3b, 4 and 6. You may need to run the command a few times to wait for the usage to stabilise (it probably will spike and decrease again). For certain workloads, e.g. servers dealing in large numbers of instances of small amounts of data, 60% extra could be quite normal (or even low). It was in optimising memory usage for a BGP implementation where I personally noticed just how much bloody space those 64bit pointers can take up. ;) If somebody shows real benefits (with real data to back it up), and is willing to put forth the effort to make it work, it might be interesting. All I'm saying is that it would be nice if: a) an x86_64 kernel was made a supported option for a 32bit Fedora (it pretty much works already) - i.e. its an additional kernel. b) yum grokked out of the box how to upgrade such systems (at the moment you have to tweak some file to make it think it's a 32bit system, and then kernel updates have to be done manually) I'm saying there is at least one very reasonable and rational reason for 32-on-64. I personally think the model used by many Unixes from the 90s makes a lot of sense - 32bit userpace by default, 64bit kernel, 64bit for a select few applications that actually need the benefits of x86_64 (memory/bit more performance), but hey.. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: If you can't learn to do it well, learn to enjoy doing it badly. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: trouble with signals and skb_rec_datagram()
It's likely that some people have not noticed this message because you replied to an unrelated thread instead of starting with a new message entirely. This is best avoided. On 12/14/2009 02:45 PM, William Reich wrote: > > Hello List... > > I am working on trying to port a LINUX kernel > driver from RedHat AS 4/5 to Fedora 11 & 12. Is this is a third-party driver that RH doesn't ship in RHEL? I'm going to assume it is, and respond with that in mind. It would probably be better to focus on porting it to the upstream kernel, and getting it submitted there. That helps a great deal to keep you from having to do this again -- when interfaces like skb_rec_datagram() change, the entire upstream kernel tends to get fixed along with the change. [...] > Does anyone know if the behavior of skb_rec_datagram() has changed > in the newer kernels ? Sounds like a question for linux-netdev rather than for fedora-devel. If you actually try to get your driver ready for upstream, the linux-netdev are likely to be quite helpful. -- Peter I was born not knowing and have had only a little time to change that here and there. -- Feynman -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
packages requiring me to reboot...
Hello, I feel like there are an increasing number of packages requiring a system reboot. I'm wondering why. The following updates were installed today, and required a full system reboot. I can't seem to find any package in the list that I can conceivably see requiring a reboot, is it that PK doesn't have the concept of X logout vs reboot? Is it a bug in the packaging or PK or is there anything I can do/file to improve the situation? Dec 15 09:07:21 Updated: glib2-2.22.3-1.fc12.x86_64 Dec 15 09:07:23 Updated: mysql-libs-5.1.40-1.fc12.x86_64 Dec 15 09:07:23 Updated: gpm-libs-1.20.6-9.fc12.x86_64 Dec 15 09:07:25 Updated: mysql-5.1.40-1.fc12.x86_64 Dec 15 09:07:28 Updated: PyQt4-4.6.2-5.fc12.x86_64 Dec 15 09:07:32 Updated: mysql-server-5.1.40-1.fc12.x86_64 Dec 15 09:07:34 Updated: gpm-1.20.6-9.fc12.x86_64 Dec 15 09:07:37 Updated: 1:tk-8.5.7-3.fc12.x86_64 Dec 15 09:07:37 Updated: mpfr-2.4.1-5.fc12.x86_64 Dec 15 09:07:39 Updated: foomatic-4.0.3-5.fc12.x86_64 Dec 15 09:07:40 Updated: mysql-embedded-5.1.40-1.fc12.x86_64 Dec 15 09:07:41 Updated: glib2-2.22.3-1.fc12.i686 Dec 15 09:07:45 Updated: gtk2-2.18.4-3.fc12.x86_64 Dec 15 09:07:58 Updated: 1:gdm-2.28.1-25.fc12.x86_64 Dec 15 09:07:58 Updated: ibus-libs-1.2.0.20091204-2.fc12.x86_64 Dec 15 09:07:59 Updated: imsettings-libs-0.107.4-4.fc12.x86_64 Dec 15 09:08:02 Updated: glib2-devel-2.22.3-1.fc12.x86_64 Dec 15 09:08:07 Updated: yelp-2.28.1-1.fc12.x86_64 Dec 15 09:08:10 Updated: f-spot-0.6.1.5-1.fc12.x86_64 Dec 15 09:08:13 Updated: 1:xscreensaver-base-5.10-4.fc12.x86_64 Dec 15 09:08:13 Updated: 1:xscreensaver-gl-base-5.10-4.fc12.x86_64 Dec 15 09:08:16 Updated: gtk2-devel-2.18.4-3.fc12.x86_64 Dec 15 09:08:25 Updated: totem-2.28.4-1.fc12.x86_64 Dec 15 09:08:25 Updated: totem-nautilus-2.28.4-1.fc12.x86_64 Dec 15 09:08:27 Updated: 1:xscreensaver-gl-extras-5.10-4.fc12.x86_64 Dec 15 09:08:29 Updated: 1:xscreensaver-extras-5.10-4.fc12.x86_64 Dec 15 09:08:34 Updated: imsettings-0.107.4-4.fc12.x86_64 Dec 15 09:08:34 Updated: 1:gdm-user-switch-applet-2.28.1-25.fc12.x86_64 Dec 15 09:08:35 Updated: 1:gdm-plugin-fingerprint-2.28.1-25.fc12.x86_64 Dec 15 09:08:35 Updated: totem-mozplugin-2.28.4-1.fc12.x86_64 Dec 15 09:08:37 Updated: python-reportlab-2.3-1.fc12.x86_64 Dec 15 09:08:38 Updated: jna-3.2.4-1.fc12.x86_64 Dec 15 09:08:38 Updated: memcached-1.4.4-1.fc12.x86_64 Dec 15 09:08:38 Updated: less-436-3.fc12.x86_64 Dec 15 09:08:40 Updated: cscope-15.6-6.fc12.x86_64 Dec 15 09:08:40 Updated: xorg-x11-drv-mouse-1.5.0-1.fc12.x86_64 Dec 15 09:08:40 Updated: f-spot-screensaver-0.6.1.5-1.fc12.x86_64 Dec 15 09:08:46 Updated: gtk2-devel-docs-2.18.4-3.fc12.x86_64 Dec 15 09:08:46 Updated: gpm-devel-1.20.6-9.fc12.x86_64 Dec 15 09:08:46 Updated: liveusb-creator-3.9-1.fc12.noarch Dec 15 09:08:48 Updated: mysql-devel-5.1.40-1.fc12.x86_64 Dec 15 09:08:53 Updated: etoys-4.0.2339-1.fc12.noarch Dec 15 09:08:59 Updated: ibus-1.2.0.20091204-2.fc12.x86_64 Dec 15 09:08:59 Updated: ibus-gtk-1.2.0.20091204-2.fc12.x86_64 Wouldn't it be sufficient to logout? Is it a bug? -- Nathanael -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wiki Feature Dashboard Additional Category
On Mon, Dec 14, 2009 at 20:45:36 -0800, John Poelstra wrote: > > You have an interesting idea about tagging feature pages needing an > owner. In reality that pretty much represents all the pages in > 'Category:FeaturePageIncomplete' If they had an active owner or > developer working on the feature they wouldn't be there. Or they were just created and aren't ready to propose to FESCO just yet. (For example LZMA_for_Live_Images is waiting for proposed patches to 2.6.33 to actually be accepted by Linus before there is any point in asking FESCO to approve the Feature.) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Yum "Cannot retrieve repository metadata" error
On Tue, Dec 15, 2009 at 05:32:43PM +0800, phenix wrote: > I have the same problem. This is what i do to solve it. > > edit /etc/hosts, add the following hosts > > 80.239.156.215 mirrors.fedoraproject.org > 152.46.7.222download.fedoraproject.org > 209.132.183.67 download.fedora.redhat.com > > use baseurl instead of mirrorlist repos. We've had some problems with DNS during the Fedora Infrastructure move, but these should be resolved now, eliminating the need to edit /etc/hosts or the yum .repo files. If you find you still have problems, please file a ticket with Fedora Infrastructure. https://fedorahosted.org/fedora-infrastructure/ Thanks, Matt -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
FUDConF13 videos
I've just posted 2 videos shot at FUDConF13 Toronto last week. I'm afraid I haven't done justice though... 1) Moksha, by Luke Macken. My camera cut out after the first 10 minutes, so that's all we've got. http://alt.fedoraproject.org/pub/alt/videos/2009/FUDConF13/fudconf13-moksha.ogg 2) The last 20 minutes of the Fedora Infrastructure: Sysadmins vs. Developers love-in. I'm grateful to whoever shot this, but I've complete blanked on who it was now. I'll be glad to give you attribution, please remind me! http://alt.fedoraproject.org/pub/alt/videos/2009/FUDConF13/fudconf13-infrastructure-roundtable.ogg If anyone else has video or audio from this or other Fedora events you'd care to share, please contact me and I'll help you get it into proper ogg format, tagged, and posted to Fedora Infrastructure servers for distribution. Thanks, Matt -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -- 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, 14 Dec 2009 19:21:19 -0800 Jesse Keating wrote: > git://publictest5.fedoraproject.org/git/pkgs/ > Give it a spin, see what you think. 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 " variety: "cvsextras" and "gafton". Both CVS authors get the default conversion to "$1 <$1>". Is this on purpose? -- Hans Ulrich Niedermann signature.asc Description: PGP signature -- 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, 15 Dec 2009 11:24:52 +0100
Ralf Ertzinger wrote:
> 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?
>From what I have read, the Makefiles will be killed off, and a
newly (to be) written tool ("fpkg") will take over the job of
the soon to be late Makefiles, and then some.
--
Hans Ulrich Niedermann
--
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, 15 Dec 2009 09:49:21 + "Richard W.M. Jones" wrote: > 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. 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. -- Hans Ulrich Niedermann -- 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, 14 Dec 2009 19:21:19 -0800 Jesse Keating wrote: > pkgs/rpms//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. 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. -- Hans Ulrich Niedermann signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Yum "Cannot retrieve repository metadata" error
On Tue, Dec 15, 2009 at 10:32 AM, phenix wrote: > I have the same problem. This is what i do to solve it. > > edit /etc/hosts, add the following hosts > > 80.239.156.215 mirrors.fedoraproject.org > 152.46.7.222 download.fedoraproject.org > 209.132.183.67 download.fedora.redhat.com > > use baseurl instead of mirrorlist repos. > Thanks, that did the trick for me. Problem solved, I guess. :) -- With kind regards / Met vriendelijke groet, Eelko Berkenpies http://blog.berkenpies.nl/ -- 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
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 ? H. -- 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, Dec 15, 2009 at 10:59:52AM +, Richard W.M. Jones wrote: > On Tue, Dec 15, 2009 at 05:50:05AM -0500, Josh Boyer wrote: > > On Tue, Dec 15, 2009 at 10:34:04AM +, Richard W.M. Jones wrote: > > >On Tue, Dec 15, 2009 at 10:06:42AM +, Tim Waugh wrote: > > >> On Tue, 2009-12-15 at 09:49 +, Richard W.M. Jones wrote: > > >> > Why not put everything in a single git repository? > > >> > > >> That would require every packager to check out the entire package set, > > >> all revisions, all branches. No thanks. > > > > > >Jesse can probably estimate for us how large this will be. > > > > > >I've found that git deals very well with large repositories that have > > >lots of files and lots of history (kernel, qemu). And you only ever > > >have to download it once, since you can use "git fetch" to make local > > >working copies. > > > > A full git repo was 5.7G. I sure as hell don't want to pull that down > > when I'm only interested in a few packages. > > > > (The CVS repo is 16G on the server side if you are wondering.) > > Fair enough - it doesn't make sense since the combined repo would > be so large. 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. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- 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, Dec 15, 2009 at 05:55:19AM -0500, Jon Masters wrote: >On Mon, 2009-12-14 at 20:22 -0800, Jesse Keating wrote: >> 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 > >Can you explain the tags a little Jesse? > >e.g. >F-12-split >F-12-start Those are straight from CVS. I'm guessing they have to do with when we do a mass 'CVS branch' to create the dirs for the next release. josh -- 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, Dec 15, 2009 at 05:50:05AM -0500, Josh Boyer wrote: > On Tue, Dec 15, 2009 at 10:34:04AM +, Richard W.M. Jones wrote: > >On Tue, Dec 15, 2009 at 10:06:42AM +, Tim Waugh wrote: > >> On Tue, 2009-12-15 at 09:49 +, Richard W.M. Jones wrote: > >> > Why not put everything in a single git repository? > >> > >> That would require every packager to check out the entire package set, > >> all revisions, all branches. No thanks. > > > >Jesse can probably estimate for us how large this will be. > > > >I've found that git deals very well with large repositories that have > >lots of files and lots of history (kernel, qemu). And you only ever > >have to download it once, since you can use "git fetch" to make local > >working copies. > > A full git repo was 5.7G. I sure as hell don't want to pull that down > when I'm only interested in a few packages. > > (The CVS repo is 16G on the server side if you are wondering.) Fair enough - it doesn't make sense since the combined repo would be so large. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- 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 20:22 -0800, Jesse Keating wrote: > 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 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? Jon. -- 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, Dec 15, 2009 at 10:34:04AM +, Richard W.M. Jones wrote: >On Tue, Dec 15, 2009 at 10:06:42AM +, Tim Waugh wrote: >> On Tue, 2009-12-15 at 09:49 +, Richard W.M. Jones wrote: >> > Why not put everything in a single git repository? >> >> That would require every packager to check out the entire package set, >> all revisions, all branches. No thanks. > >Jesse can probably estimate for us how large this will be. > >I've found that git deals very well with large repositories that have >lots of files and lots of history (kernel, qemu). And you only ever >have to download it once, since you can use "git fetch" to make local >working copies. A full git repo was 5.7G. I sure as hell don't want to pull that down when I'm only interested in a few packages. (The CVS repo is 16G on the server side if you are wondering.) josh -- 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, Dec 15, 2009 at 10:06:42AM +, Tim Waugh wrote: > On Tue, 2009-12-15 at 09:49 +, Richard W.M. Jones wrote: > > Why not put everything in a single git repository? > > That would require every packager to check out the entire package set, > all revisions, all branches. No thanks. Jesse can probably estimate for us how large this will be. I've found that git deals very well with large repositories that have lots of files and lots of history (kernel, qemu). And you only ever have to download it once, since you can use "git fetch" to make local working copies. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- 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
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? -- 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? That would require every packager to check out the entire package set, all revisions, all branches. No thanks. Tim. */ 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, Dec 14, 2009 at 07:21:19PM -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. > > pkgs/rpms//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. Why not put everything in a single git repository? 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. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- 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 Tue, Dec 15, 2009 at 09:43:33AM +, Richard W.M. Jones wrote: > On Mon, Dec 14, 2009 at 04:57:03PM -0500, Todd Zullinger wrote: > > Mike Chambers wrote: > > > If I understand what is happening now (and over the past weekend), > > > the datacenter machines are moving to a new location, AND the > > > package building is moving from cvs to git (will be, or already in > > > process)? > > > > Only the former is taking place now. A move from cvs to git is being > > tested but is not imminent. I'm sure that it will be hard to miss > > once that change is ready and implemented. > > Is there any documentation about the move to git? In particular I'm > interested in whether the whole of Fedora will be in a single git > repository, or each package will exist in its own git repository. Ignore this -- Jesse answers it lower down. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html -- 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, Dec 14, 2009 at 04:57:03PM -0500, Todd Zullinger wrote: > Mike Chambers wrote: > > If I understand what is happening now (and over the past weekend), > > the datacenter machines are moving to a new location, AND the > > package building is moving from cvs to git (will be, or already in > > process)? > > Only the former is taking place now. A move from cvs to git is being > tested but is not imminent. I'm sure that it will be hard to miss > once that change is ready and implemented. Is there any documentation about the move to git? In particular I'm interested in whether the whole of Fedora will be in a single git repository, or each package will exist in its own git repository. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Yum "Cannot retrieve repository metadata" error
I have the same problem. This is what i do to solve it. edit /etc/hosts, add the following hosts 80.239.156.215 mirrors.fedoraproject.org 152.46.7.222download.fedoraproject.org 209.132.183.67 download.fedora.redhat.com use baseurl instead of mirrorlist repos. BUT, when upgrade complete, i can not reboot or bootup On Tue, 2009-12-15 at 09:00 +0100, Eelko Berkenpies wrote: > Hi all, > > Since my latest rawhide update, performed on Dec 12 (with > --skip-broken enabled because of some broken dependencies and a > certain laziness on my side), my yum is giving me the following error: > > Loaded plugins: presto > Error: Cannot retrieve repository metadata (repomd.xml) for > repository: rawhide. Please verify its path and try again > > Here's a list of packages which got updated: > http://berkenpies.nl/yum.log > > I'd be more than happy to manually downgrade some packages but does > someone have any clue on which package could be causing this? > > On a side note, yum was also complaining about > "/var/cache/yum/i386/13/rpmdb-cache" which didn't exist. To get rid of > this one, I manually created the directory. > > -- > With kind regards / Met vriendelijke groet, > > Eelko Berkenpies > http://blog.berkenpies.nl/ > -- 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 Tue, Dec 15, 2009 at 9:00 AM, Martin Langhoff wrote: > branches AFAIK. (It's not that awkward, but for developers resisting > change... ah, every changed comma is a slight :-) ... ). To be clear, I mean developers with better things to do with their time than dealing with an SCM change. There is never a good time for an SCM change unfortunately, at least not in any large team. m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Yum "Cannot retrieve repository metadata" error
Hi all, Since my latest rawhide update, performed on Dec 12 (with --skip-broken enabled because of some broken dependencies and a certain laziness on my side), my yum is giving me the following error: Loaded plugins: presto Error: Cannot retrieve repository metadata (repomd.xml) for repository: rawhide. Please verify its path and try again Here's a list of packages which got updated: http://berkenpies.nl/yum.log I'd be more than happy to manually downgrade some packages but does someone have any clue on which package could be causing this? On a side note, yum was also complaining about "/var/cache/yum/i386/13/rpmdb-cache" which didn't exist. To get rid of this one, I manually created the directory. -- With kind regards / Met vriendelijke groet, Eelko Berkenpies http://blog.berkenpies.nl/ -- 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, Dec 14, 2009 at 11:31 PM, Todd Zullinger wrote: > Jeff Garzik wrote: >> If done right, the move to git can still service CVS requests in >> some capacity... that may make the transition a little less abrupt >> and painful. > > Perhaps. But git-cvsserver is a rather limited crutch that I can't > imagine anyone wanting to spend much time on, just to let folks > continue to use cvs commands directly. Actually, the biggest issue with it is the somewhat awkward mapping of branches to "cvs modules". But the Fedora CVS repo doesn't use cvs branches AFAIK. (It's not that awkward, but for developers resisting change... ah, every changed comma is a slight :-) ... ). And git-submodules support. And that could be added with a modest effort. > Who knows though, maybe there are more people that actually like cvs > than I think and they'll volunteer to implement and run such a > service. Not so much about liking cvs. In the past, main use cases for git-cvsserver have been (a) users deeply attached to a heavy IDE (Eclipse) that doesn't yet have git support and (b) scripts & misc automation that nobody wants to port. btw, I designed and co-wrote it :-) m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
