berlios.de compromised since 2005
Hi folks, This lwn article reports that berlios.de has been compromised for a long, long time. http://lwn.net/Articles/369633/ So I compiled a little list of pkgs that need a look: http://skvidal.fedorapeople.org/misc/berlios-pkg-owners-list.txt Here is the list as well: arbiter:slim:http://slim.berlios.de/ athimm:freenx-client:http://freenx.berlios.de/ athimm:freenx-server:http://freenx.berlios.de/ ausil:oooqs2:http://segfaultskde.berlios.de/index.php?content=oooqs2 awjb:gimmix:http://gimmix.berlios.de/ bjohnson:unpaper:http://unpaper.berlios.de bouska:wifi-radar:http://wifi-radar.berlios.de/ caolanm:mythes-es:http://openthes-es.berlios.de dmaphy:graphem:http://graphem.berlios.de/ dnglaze:openocd:http://openocd.berlios.de/web/ drago01:hardinfo:http://hardinfo.berlios.de/ drago01:pinot:http://pinot.berlios.de/ dwmw2:bcm43xx-fwcutter:http://bcm43xx.berlios.de/ fab:python-wifi:https://developer.berlios.de/projects/pythonwifi/ hguemar:sonata:http://sonata.berlios.de/ hubbitus:sim:http://sim-im.berlios.de/ isimluk:ruby-ncurses:http://ncurses-ruby.berlios.de/ ixs:bitbake:http://developer.berlios.de/projects/bitbake/ jamatos:python-cpio:http://developer.berlios.de/projects/python-cpio/ jcollie:radiusclient-ng:http://developer.berlios.de/projects/radiusclient-ng/ jreznik:kio-ftps:http://kasablanca.berlios.de/kio-ftps/ jspaleta:gpodder:http://gpodder.berlios.de/ kkofler:kio_gopher:http://kgopher.berlios.de/ kwizart:atmel-firmware:http://at76c503a.berlios.de/ kwizart:tslib:http://tslib.berlios.de/ laxathom:soundconverter:http://soundconverter.berlios.de/ limb:netpanzer:http://netpanzer.berlios.de limb:wavextract:http://developer.berlios.de/projects/wavextract mgarski:smb4k:http://smb4k.berlios.de/ michaelc:scsi-target-utils:http://stgt.berlios.de mtasaka:mirage:http://mirageiv.berlios.de/ musuruan:hatari:http://hatari.berlios.de/ oget:canorus:http://canorus.berlios.de/ oget:jjack:http://jjack.berlios.de/ oron:libhocr:http://hocr.berlios.de ovasik:star:http://cdrecord.berlios.de/old/private/star.html rdieter:kasablanca:http://kasablanca.berlios.de/ rdieter:lensfun:http://lensfun.berlios.de/ rishi:libgringotts:http://gringotts.berlios.de/ rjones:ocaml-pgocaml:http://developer.berlios.de/projects/pgocaml/ rvokal:net-tools:http://net-tools.berlios.de/ silfreed:gpsd:http://developer.berlios.de/projects/gpsd/ spot:lincity-ng:http://lincity-ng.berlios.de/ stingray:cuetools:http://developer.berlios.de/projects/cuetools/ sundaram:gimmage:http://gimmage.berlios.de/ terjeros:cpipe:http://developer.berlios.de/projects/cpipe/ terjeros:python-tidy:http://utidylib.berlios.de/ till:fatsort:http://fatsort.berlios.de/ twaugh:pyusb:http://pyusb.berlios.de/ vcrhonek:fetchmail:http://fetchmail.berlios.de/ if you're on this list then you need to talk to upstream and find out if they have done an audit yet. You might consider doing an audit yourself, if you have the background to know what sort of things to look for. thanks, -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Sat, 16 Jan 2010, Matt Domsch wrote: > We could easily create a new class of bugzilla ticket, say > "MAINTAINED". An automated process would generate such tickets, > blocking F13MAINTAINED. The ticket would ask the maintainer to close > the ticket to remain the owner of the package. Tickets still open > after $SOMEDELAY would be candidates for orphan or non-responsive > maintainer process. Repeat at $SOMEINTERVAL, perhaps once per release > cycle (more would be too onerous I think). > > With a slight modification, my ftbfs bugzilla script could generate > the tickets. > > Thoughts? I like the idea. I like it even more if we could make a make-target for saying "I'm here, shut the hell up" so it can be done easily. So, for Hans' situation - if he has 150 pkgs - we file a 'MAINTAINED' bug on any of the pkgs which has not had any change in a full release. that should narrow the number of bugs he has to deal with, I'd think. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to speed up mock?
On Mon, 18 Jan 2010, Farkas Levente wrote: > the real bottleneck is not the rpmbuild itself (with ccache it cab be > very fast), but the mock surroundings. suppose there is build which > takes about 2 minutes and in mock it takes about 5 minutes:-( > most of the time is in yum, python tar, gzip etc which all use only one > cpu/core and it's very slow! > the tar and gzip are mostly BUILDING the cache. Mock currently makes a cached copy of the buildroot it just created so it doesn't have to redepsolve and download/install the rpms each time. So the first time you run it makes a cache. You aren't clearing out the cache each time, are you? That would definitely eat up a lot of time. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to speed up mock?
On Mon, 18 Jan 2010, Farkas Levente wrote: >> >> the tar and gzip are mostly BUILDING the cache. > > no tar and gzip used unpacking root cache. > How slow are your disks? You're not doing any of this to nfs are you? > but have to run yum each time for the package specific depsolve and yum > installs (ps axufww:) > --- > \_ /usr/bin/python -tt /usr/sbin/mock -r testing-i386 --define rhel 5 > --define el5 1 --define dist .el5 --rebuild > /home/robot/rpm/SRPMS/xyz-4.2.2-5280.el5.src.rpm > root 28319 49.5 0.8 255000 34292 pts/1D16:15 0:00 | > \_ /usr/bin/python /usr/bin/yum --installroot > /var/lib/mock/testing-i386/root/ install ccache rsync zip > --- > and it much slower then the compile itself. it's very annoying when i try to > rebuild only a dozen of packages most of the time. > eg in this output: How much of this is network access and how much is disk? B/c I doubt very much that you're cpu bound at all. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to speed up mock?
Farkas, Don't email just to me offlist. Keep this onlist. >> >> How much of this is network access and how much is disk? B/c I doubt >> very much that you're cpu bound at all. > > everything is on the local mirror server which is on a gigabit lan. is there > any way to banchmark mock and different part of it? > in the mock config you're using (/etc/mock/.) look for: config_opts['yum.conf'] = """ [main] cachedir=/var/cache/yum debuglevel=1 reposdir=/dev/null logfile=/var/log/yum.log retries=20 obsoletes=1 gpgcheck=0 assumeyes=1 and change debuglevel=1 to debuglevel=3 and then look at the root.log and look for lines that contain: "time:" that will tell you how long is being spent in each section post those times. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: apt-fast
On Mon, 18 Jan 2010, Josephine Tannhäuser wrote: should be possible, we have an (old but we have one) apt unless I'm reading that forum thread wrong - it sure seems like apt-fast requires axel's repo? If that's true then I think it nixes any chance of the pkg getting into fedora. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Mon, 18 Jan 2010, Bill Nottingham wrote: > Ugh, this seems like it would just create a lot of make-work for the > common case where packages *are* maintained. Perhaps only do this > for packages that appear via some criteria (have not been built, have > not been committed to, have lots of bugs with no response, etc.), but > doing it for *every* package seems like overkill. > Right - so maybe last check into devel branch since the last release of the distro. If we do that check before the alpha release that should let us track down awol maintainers and unmaintained pkgs pretty easily, I think. thoughts? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Mon, 18 Jan 2010, Till Maas wrote: > On Mon, Jan 18, 2010 at 12:25:44PM -0500, Seth Vidal wrote: >> >> >> On Mon, 18 Jan 2010, Bill Nottingham wrote: >> >>> Ugh, this seems like it would just create a lot of make-work for the >>> common case where packages *are* maintained. Perhaps only do this >>> for packages that appear via some criteria (have not been built, have >>> not been committed to, have lots of bugs with no response, etc.), but >>> doing it for *every* package seems like overkill. >>> >> >> Right - so maybe last check into devel branch since the last release of >> the distro. >> >> If we do that check before the alpha release that should let us track down >> awol maintainers and unmaintained pkgs pretty easily, I think. > > The majority of my packages does not get updated that often (15 from 21) > and there are also no bug reports unhandled for them. > > I am not sure how the ratio is for others, but it does not seem to be > such a got criterion. so 15/21 your packages don't get rebuilt, atall, from release to release? Really? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Mon, 18 Jan 2010, Tomas Mraz wrote: > I think there should be at least two conditions which would have to be > fulfilled for the nagging bug to be created - the package was not > touched by the maintainer during recent x months and at least one bug is > opened not closed in the bugzilla on the package. > I disagree about the bug being open. A lack of filed bugs could mean that no one CARES about the pkg at all. And if we have pkgs which are not being maintained AND no one cares enough to file a bug about then either they are: 1. extraordinarily stable 2. dead upstreams 3. unmaintained 4. unusued in ANY of those cases I'd want to start thinking about nuking the pkg from fedora. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Mon, 18 Jan 2010, Tomas Mraz wrote: > On Mon, 2010-01-18 at 14:04 -0500, Seth Vidal wrote: >> >> On Mon, 18 Jan 2010, Tomas Mraz wrote: >> >>> I think there should be at least two conditions which would have to be >>> fulfilled for the nagging bug to be created - the package was not >>> touched by the maintainer during recent x months and at least one bug is >>> opened not closed in the bugzilla on the package. >>> >> >> I disagree about the bug being open. A lack of filed bugs could mean that >> no one CARES about the pkg at all. And if we have pkgs which are not being >> maintained AND no one cares enough to file a bug about then either they >> are: >> >> 1. extraordinarily stable >> 2. dead upstreams >> 3. unmaintained >> 4. unusued >> >> in ANY of those cases I'd want to start thinking about nuking the pkg from >> fedora. > > So that means that for example for the openoffice.org-dict-cs_CZ package > I'll get the nag bug report before each and every Fedora release? > > It is definitely not 4. however 1. and 2. apply to it. As this is just a > czech spelling and hyphenation dictionary which is pretty good one and > we do not have any alternative anyway I do not think that 2. matters > much. > > OK, I think my next changelog entry in the .spec will be something > like: > - rebuilding just for the sake of not getting a nonsense bug report > opened against the package Really? We need all this drama? I have another radical idea - we could whitelist all sorts of things which are unchanging and yet used. We could act like reasonable folks and realize that one extra bug report A YEAR that you have to close as 'fixed' is really not that big of a deal. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Mon, 18 Jan 2010, Till Maas wrote: > First of all, that would be two bug reports per year, as we have a 6 > month development cycle. But it also will not be that useful, as we > already have three things that have to be done by every maintainer once > or twice a year, so they can be easily used to track, whether or not a > maintainer is still around at all: FAS password, Koji certificate > Bugzilla password. > Then if you intend to catch unused packages, this will also fail unless > you also plan to implement some captcha for this for every package, > because there will be a script that a maintainer can run to close all > bugs for all of his packages at once, even for the packages he does not > maintain properly. So you will still only track down, whether or not a > packager is still around and not whether he cares about a certain > package. Yes, I believe the expression you're looking for is: "Perfect is the enemy of the good" What is being suggested is not perfect. It is, however, good. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Mon, 18 Jan 2010, Till Maas wrote: >> Often maintainers don't realize they have some of these packages, or the >> maintainers have left the project. > > Do maintainer really "often" forget, that they own a certain package? > Ok, maybe if they are forced to do this from Red Hat, I do not know. But > I am happy for every package that I do not have to maintain. > > But I think packages with no bug reports because they are not > used are also not that big of a problem if they exist, unless they are > really big or take very long to be rebuilt. It's imho at least not a > problem that needs to be checked for every year. Or can you point to any > known issues because of such packages since Fedora started? Sure - we're expanding with no end in sight. Every pkg increases the load of metadata and crap that EVERYONE has to download and has to deal with. If we have pkgs which are NOT being used then we can save everyone the bandwidth. Let's call it a cleanliness thing. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Mon, 18 Jan 2010, Till Maas wrote: > On Mon, Jan 18, 2010 at 02:55:36PM -0500, Seth Vidal wrote: > >> Yes, I believe the expression you're looking for is: >> >> "Perfect is the enemy of the good" >> >> What is being suggested is not perfect. It is, however, good. > > Here we disagree. As I explained I see little use in it, since there are > other methods that work at least as good as this on, but are less > annoying. And they might even perform better, wrt to the challenge to > find unmaintained packages. Or in other words, I do not trust in the > mass bugfiling method, so the other methods still need to be implemented > to get the information I am interested in. > > Also I cannot remember any argument from you that explains why your > solution is superior to the other solutions. > I've not heard any other solutions which aren't "oh just let it be." -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Mon, 18 Jan 2010, Adam Williamson wrote: > On Mon, 2010-01-18 at 12:25 -0500, Seth Vidal wrote: > >> If we do that check before the alpha release that should let us track >> down >> awol maintainers and unmaintained pkgs pretty easily, I think. >> >> thoughts? > > There's trivial packages which simply don't really need touching. I just > updated congruity for the first time in a couple of months. it got a > (very trivial) upstream release; upstream could easily have held off and > I'd have had absolutely no reason to touch it. it's a simple package > that just does what it's supposed to do, it doesn't need much TLC. I > wouldn't want to be considered 'unresponsive' just because it hadn't > needed touching for an arbitrary period. which is why All we're suggesting is filing a bug and/or some other kind of notification that says "are you alive". -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Tue, 19 Jan 2010, Toshio Kuratomi wrote: > After some talk on IRC yesterday, skvidal is the person doing work on this > at them moment. His plan is to implement tests that try to tell if > individual packages are maintained and get people to orphan those that are > not. Here's his general plan for what to test: > > """ > 1. all the pkgs which have no devel checkins in > 365 days >1a, if the only checkins they have correspond to a massrebuild date >- then they still get counted as potentially abandoned > 2. all the pkgs which have no builds, other than mass rebuilds in > 365 >days then take that set of pkgs and if it is a LARGE number of pkgs >- then intersect that with pkgs which have bugs open to reduce the set >a bit b/c open bugs AND not looked at == problems for fedora > """ > > We discussed whether to do reporting from this via bugzilla or another tool > and I'm leaning towards another tool so it's easy for a maintainer to look > through and a list of packages and check which ones they still care about. > skvidal would like to get the tests working first to see if we're talking > about a huge number of packages or only a few. I'm going to try and generate a couple of lists today if I can get all my koji-foo working properly. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Tue, 19 Jan 2010, Thomas Moschny wrote: > 2010/1/18 Seth Vidal : >> 1. extraordinarily stable >> [...] >> in ANY of those cases I'd want to start thinking about nuking the pkg from >> fedora. > > Are you serious? > As a heart attack. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: berlios.de compromised since 2005
On Tue, 19 Jan 2010, Dominic Hopf wrote: > Am Mittwoch, den 13.01.2010, 12:23 -0500 schrieb Seth Vidal: >> dmaphy:graphem:http://graphem.berlios.de/ > > I contacted upstream concerning this Package as soon as I read your mail > last week. Upstream made the security audit at the weekend and we can > verify now that everything is okay with graphem, except some small > well-known issues which will be fixed in next versions. The author of > graphem also considers to move the project to sourceforge. > The author can also look at fedorahosted if they are looking for hosting, too. :) thank you for doing the legwork. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Tue, 19 Jan 2010, Jens Petersen wrote: > - "Seth Vidal" wrote: >> which is why All we're suggesting is filing a bug and/or some other >> kind of notification that says "are you alive". > > To clarify, only for FTBFS, right? > There's a lot more details involved. When I have the full specs on what will get flagged I'll let everyone know. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [RFC PATCH] use sulogin in single-user mode
> On Thu, 2010-01-21 at 12:21 -0500, Bill Nottingham wrote: > >> However, this changes behavior that has existed since the dawn >> of time in Red Hat/Fedora systems; with this change, single-user >> mode would now require the root password. >> Comments? I'm totally in favor of it. It is something I always do anyway in my init config. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mumble's package owner is non-responsive, I wish to take over the package
On Fri, 22 Jan 2010, Christoph Wickert wrote: > Am Freitag, den 22.01.2010, 14:52 +0100 schrieb Andreas Osowski: >> Hello, >> I do herewith request to take over the package "mumble", currently owned by >> igjurisk. >> The maintainer seems to be unresponsive and all previous attempts of contact >> have failed. >> >> According to the policy for non-responsive package maintainers, this request >> has to be approved >> by at least one FESco member. >> >> Cheers, >> Andreas >> >> Bug 552351 - Non-responsive package maintainer of Mumble >> https://bugzilla.redhat.com/show_bug.cgi?id=552351 > > Your bug was opened on January 1st, so the 3 weeks required by the > policy for non-responsive maintainers[1] have not yet passed. > Isn't today the 22nd? 3 weeks is 21 days, right? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Two FAS accounts for the same person - permitted?
On Tue, 2 Feb 2010, Mike McGrath wrote: > On Tue, 2 Feb 2010, Juha Tuomala wrote: > >> >> >> >> On Tue, 2 Feb 2010, Mike McGrath wrote: >>> but we catch you doing it (and we have) and we'll do something about it. >> >> Just for curiosity, what? Prevent doing it again? How? >> >> Like said, it's a joke. >> > > We'd keep banning you and if you kept abusing the system I'd go the board > explaining what was going on and eventually we'd ban you. If some jerk > wanted to keep finding ways around the system and get re-sponsored in the > packager group (a tricky thing to do) then they can spend their time doing > that but we're not going to make it easy for people to route round our > systems and procedures. I assure you, it's not a joke just because it's > not automatically detectable. > And I'd suspect that intentionally entering into an agreement with knowingly false information is a kind of Fraud in just about every country. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Two FAS accounts for the same person - permitted?
On Tue, 2 Feb 2010, Juha Tuomala wrote: > > > On Tue, 2 Feb 2010, Seth Vidal wrote: >> And I'd suspect that intentionally entering into an agreement with knowingly >> false information is a kind of Fraud in just about every country. > > Feel free to sue that 0 euros email-address, which provider doesn't > know who uses it. > Out of curiosity is your point to be antagonistic or are you actually trying to improve things? If it is just the former then you are welcome to NOT be involved. If it is the latter then suggestions are welcome. Security is a balance. We want more involvement so we tip the scales toward more openness. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Two FAS accounts for the same person - permitted?
On Tue, 2 Feb 2010, Juha Tuomala wrote: >> Out of curiosity is your point to be antagonistic or are you actually trying >> to improve things? > > If cleaning false assumptions and admitting that some areas are real > problems - is improving, that's what I'm doing. You don't appear to be doing that. You seem to just be attempting the 'gadfly' method of helping matters. I'd like you to remember what result that achieved for Socrates. >> If it is just the former then you are welcome to NOT be involved. > > And pulling out the welcomness from this particular identity is > actually the only thing that can be done - considering the context ;) Just having an account doesn't mean you have access to anything or are trusted. It only means you have an account. You have to maliciously want to lie and do harm. > What I see is only possible way to do that is some kind of > sertificate thing that would require global network of trusted > fedora people (like already met in meetings) able to sign those > fedora contributor certificates after checking the id documents > first (against ban lists). Those work only to limit access. And even then it just turns into a clique or a cabal-driven exercise. > There are around 200 countries and some have quite long distances, > requiring to meet people face to face doesn't really sound very > feasible. Not being feasible doesn't remove the problem however. No - but it makes you question your goals and priorities. Our goals are openness and productivity. We do our due dilligence on security and I think we > Easier would be to write red warning into wiki that "We actually > don't know who took part of building fedora, so consider yourself > warned." You mean like all open source/free software? Great. I'd like to invite you again to not be involved if this is your belief about the whole system. Or if you'd like to point out a linux distribution that doesn't have the above problem, I'm all ears. > Didn't someone just crack berlios site to inject something into > projects? In fedora you don't even need to crack anything, you get > invited to commit. And they didn't crack berlios by being involved and tricking their way in. The cracked berlios b/c of poor system maintenance. If the only way to make something safe is to shut it down entirely then there's not much point in having it at all. You should not cut off your nose to spite your face. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python 2.7 status: python2.7 is in dist-f14
On Wed, 2010-08-04 at 11:46 -0400, Toshio Kuratomi wrote: > On Wed, Aug 04, 2010 at 10:17:27AM +0100, pbrobin...@gmail.com wrote: > > On Wed, Aug 4, 2010 at 9:55 AM, Tomasz Torcz wrote: > > > On Tue, Jul 27, 2010 at 08:32:07PM -0400, David Malcolm wrote: > > >> Rawhide (dist-f14) now has python 2.7 > > > > > > I have a machine which run rawhide since F11 times. Recently upgrade to > > > python2.7 failed because of "rhpl" package. rhpl was removed from Fedora > > > some time ago, so it wasn't rebuild lately. > > > Now the question: what package should cause rhpl to be removed during > > > update? > > > Is there any obsoletes or conflicts that should cause rhpl to be removed > > > during upgrades (F11→F15 time frame)? > > > > I noticed this the other day as well. It should have been obsoleted by > > something so that it was removed on upgrade. > > > We've talked about adding Obsoletes for packages that are no longer in the > repository with no replacement (as is the case for rhpl) to something like > fedora-release before but AFAIK we've never pulled the trigger on actually > doing it. > I think I had suggested it, multiple times, and each time fesco had a problem with it. maybe even the package was named package-swift http://skvidal.fedorapeople.org/misc/package-swift.spec -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python 2.7 status: python2.7 is in dist-f14
On Wed, 2010-08-04 at 12:40 -0400, Matthew Miller wrote: > On Wed, Aug 04, 2010 at 11:53:55AM -0400, seth vidal wrote: > > I think I had suggested it, multiple times, and each time fesco had a > > problem with it. > > maybe even the package was named package-swift > > http://skvidal.fedorapeople.org/misc/package-swift.spec > > Would it make sense for the obsolete list to be specified with versions? yes, of course - it was just a sample. google for package-swift and/or look at the fesco discussions from dec or january and you'll see that discussed, ad nauseum. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python 2.7 status: python2.7 is in dist-f14
On Wed, 2010-08-04 at 13:01 -0400, Matthew Miller wrote: > On Wed, Aug 04, 2010 at 12:44:23PM -0400, seth vidal wrote: > > > Would it make sense for the obsolete list to be specified with versions? > > yes, of course - it was just a sample. > > google for package-swift and/or look at the fesco discussions from dec > > or january and you'll see that discussed, ad nauseum. > > Ok, cool. I'll stay out of it then. :) > you're welcome to pick up the torch. I'm more than happy for that to happen. I just didn't have the bandwidth to keep it going. -sv (sorry for the mixed metaphor) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: root-doc subpackage slightly obese
On Thu, 2010-08-05 at 19:56 +0300, Jonathan Dieter wrote: > So I'm syncing up our school's local mirror over our rather slow > internet connection and I notice that the root-doc subpackage (which is > part of the root package) has just hit the slightly obese size of 687MB > [1]. For reference, the root source rpm is 27MB [2]. > > Now, I don't know if we have a policy for autogenerated documentation, > but this seems a bit over the top to me, especially since the 20153 > files in this package seem to have increased the size of > filelists.xml.gz by 200KB (this is a guess based on the fact that that's > how much filelists.xml.gz has increased in the last push). > > So now I've added root-docs to my manual rsync excludes (which only had > kdelibs-apidocs in it before now). > > Can we have a guideline added to the packaging guidelines that basically > says, "Make sure autogenerated documentation isn't ridiculously large". > grumble. Thank you for noting this. Jonathan, - dish this to fesco and/or the Packaging Committee - it's a good point. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning all my packages
On Wed, 2010-08-11 at 09:32 -0700, Christopher Stone wrote: > Im no longer maintaining all my packages > > Do whatever you need to do to orphan them or open them up. > All your packages are now orphaned. Thanks for letting us know. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Fri, 2010-08-13 at 18:07 +0200, Kevin Kofler wrote: > Al Dunsmuir wrote: > > You are assuming that it is somehow a good idea to push release Fn, in > > spite of no (or negative) testing. > > Yes I am! If I build the EXACT SAME specfile for all F*, then I don't see > why testing on ANY F* isn't sufficient. Please don't bring the same old > argument that "sometimes" breakage happens only on some releases even with > the same specfile: in practice this is so rare that it doesn't matter at > all, it's much more likely that regressions slip through despite the > testing. Last week I pushed a yum update to f12, f13 and f14 - same pkg, same patches, same config. On f12, however, the version of sqlite that f12 had handles an error condition differently than on f13 and f14. It meant that instead of raise an exception and letting us move along that it raised an exception and then exited. So - the pkg checked out on f13 and f14 just fine but not on f12. I had to issue a new update for all of them to keep them in sync. That's a real world case that happens all the time. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Fri, 2010-08-13 at 13:30 -0400, Al Dunsmuir wrote: > On Friday, August 13, 2010, 1:11:49 PM, Kevin wrote: > > Jesse Keating wrote: > >> This is where Kevin blames the scenario on not having the same sqlite on > >> all of the Fedora releases, which is another evil plot hatched by the > >> devils of FESCo > > > Right. If F12 has a buggy SQLite, then that SQLite should be fixed! > > Kevin Kofler > > If the SQLite bug can be fixed, then it should be done and the package > that found the bug should be updated to list that version as a minimum > requirement. That dependency change requires at least an install > test. > > If the bug can not be fixed in F12 in a compatible way, then the > package that found the bug may need to take a different approach and > find a new way of doing things that works in all supported SQLite > releases. > > In either case, releasing things to stable before the regression is > eliminated should not be an option. > Al and that's what the testing helped with. The bug was noticed. It was patched upstream to accomodate the versions of sqlite that act differently and we moved along. So, in fact, testing worked exactly as we wanted it to. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Fri, 2010-08-13 at 20:14 +0200, Kevin Kofler wrote: > Martin Sourada wrote: > > I wonder why I get the impression that the only ones who strongly oppose > > this change are you folks from KDE SIG... Are you doing things > > differently from anyone else in fedora - the rest of us are either more > > or less neutral or positive towards this new change? > > If we really are the only ones true to Fedora's original principles, who > don't want us to become yet another redundant conservative distribution > (like all those bazillion others out there), that's really sad. :-( > > Kevin Kofler > (who wants the Fedora he learned to love back!) It is not the fedora you think it is. You can go form your own distro. Please leave us to work on ours in peace and relative quiet. I hear Bero could use some help with arklinux. kthxbai -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Get rid of file requires outside of the primary paths
On Wed, 2010-08-18 at 12:24 +0100, Richard W.M. Jones wrote: > On Wed, Aug 18, 2010 at 01:10:29PM +0200, Adam Tkac wrote: > > Fedora Engineering Services > > (http://fedoraproject.org/wiki/Fedora_Engineering_Services) received > > request to get rid of file requires outside of the primary paths > > (https://fedorahosted.org/fedora-engineering-services/ticket/31). > > > > Your package directly requires file outside of the primary paths so > > every time when your package is going to be installed/updated complete > > filelists for the distribution have to be downloaded. > > > > If you prefer to fix your package yourself, please send me a mail till > > end of this week. Otherwise I will fix your package. > > > > List of affected packages is attached. > > > > Regards, Adam > > > > -- > > Adam Tkac, Red Hat, Inc. > > > rjones libguestfs > > I have no intention of changing this. It's done for a perfectly > good reason described here: > > http://lists.fedoraproject.org/pipermail/devel/2010-April/134663.html > > [Unless someone is actually willing to do the large amount of work > required to change this (see above) and ensure that performance isn't > affected by the change.] > > In addition, I think the reason for doing this is specious. This > doesn't affect anyone except libguestfs users, and no one has yet > complained to me about the overhead of having to download filelists > while installing libguestfs. I am a libguestfs user and I'm complaining. It means I have to schlep down a bunch of extra info on every update of libguestfs and that sucks on my bandwidth. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
yum appmarket
I mentioned this on: http://skvidal.wordpress.com/2010/08/19/fedora-app-market-proof-of-concept/ last night but I thought I'd bring it up here: Yesterday someone was talking about installing apps in fedora and how it was hard to figure out what to install/try b/c there were too much STUFF in fedora. They suggested an ‘app store’ like functionality. I explained that all the resources to do something like that exist in the infrastructure yum and friends offer now. I decided to prove that concept a bit. The concept of an ‘app’ is pretty amorphous but I decided to just use what Colin Walters said was his definition of an ‘app’ – which is any pkg containing a .desktop file. So I just whipped up a simple tool to dump out an xml-file of a format yum is already familiar with based on that criteria: http://skvidal.fedorapeople.org/misc/appfinder.py Running that generates an xml file with only the ‘apps’ defined. Great. Then I wrote a yum plugin to access and use this data. and I stuck it in this repo 1. copy this file into /etc/yum.repos.d/ 2. run: yum install yum-plugin-appmarket Now yum will have a few new commands available to it: app-installInstall an App app-list List Apps app-remove Remove an App app-search Search for an App Some examples: yum app-search yum won’t turn up ‘yum’ but it will turn up ‘yumex’. Fancy, huh? Now, the concept of an app can be refined in many ways but this is just to prove that the infrastructure has been available. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum appmarket
On Thu, 2010-08-19 at 18:30 +0200, Dennis J. wrote: > On 08/19/2010 05:46 PM, seth vidal wrote: > ... > > Now, the concept of an app can be refined in many ways but this is just > > to prove that the infrastructure has been available. > > What's missing is the ability to rate an app and comment on it because > that's really what deals with the "there is too much STUFF > in fedora" bit. Agreed. > Parsing of the metadata isn't strictly necessary as you could simply let > the packagers declare their packages as apps. Beeing able to do this > automatically is a nice bonus though. Even less so after a patch to rpmbuild gets in. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum appmarket
On Thu, 2010-08-19 at 18:59 +0200, Till Maas wrote: > On Thu, Aug 19, 2010 at 12:42:18PM -0400, seth vidal wrote: > > On Thu, 2010-08-19 at 18:30 +0200, Dennis J. wrote: > > > On 08/19/2010 05:46 PM, seth vidal wrote: > > > ... > > > > Now, the concept of an app can be refined in many ways but this is just > > > > to prove that the infrastructure has been available. > > > > > > What's missing is the ability to rate an app and comment on it because > > > that's really what deals with the "there is too much STUFF > > > in fedora" bit. > > > > Agreed. > > There is a "web app store" in PackageDB, which seems to have all of this: > https://admin.fedoraproject.org/pkgdb/ > yes, I know. And you'll notice that the pkgdb can generate a sqlite db of tags and ranking info that yum can use if the info is in the repodata. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora PkgTags Repo
Visible here: http://skvidal.wordpress.com/2010/08/19/searching-package-tags-from-the-pkgdb/ In the last round of roll outs the fedora packagedb added tags and ratings to the site. A great bit of work by mbacovsk, maploin and toshio made this happen. I added support for yum to use the db that the pkgdb can spit out, searching on the tags for pkgs, provided that the info is in the repodata. It’s not quite percolated to the top of anyone’s list to get it into the repodata in bodhi. However with the advent of repos.fp.o I now have a good place to store this and make it accessible to users. So make sure you have yum updated on your system – at least yum 3.2.26. 1. Grab this file: http://repos.fedorapeople.org/repos/skvidal/PkgTags/fedora-PkgTags.repo and stuff it in /etc/yum.repos.d/ on your system 2. run: yum search sometag someothertag someothertag That’s it! I’ll update the repo ever-so-often until we get the round-tuits compiled for it to be added into the updates repodata automagically. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum appmarket
On Thu, 2010-08-19 at 22:55 +0200, drago01 wrote: > Thanks for working on this, the concept of "packages" should be an > implementation detail that much (desktop) users shouldn't have to care > about. > > This is definitely a step in the right direction. PK should follow > that and only display apps by default in the GUI. I was just noodling around in the pkgtags db that I just posted about and noticed that the a lot of pkgs have the 'Application' tag applied to them. I could modify the appmarket plugin to use this information if it is available. Coupling that data with tags like 'XFCE' it would be trivial to list just xfce applications, for example. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum appmarket
On Thu, 2010-08-19 at 23:46 +0200, Nicolas Mailhot wrote: > Le jeudi 19 août 2010 à 22:55 +0200, drago01 a écrit : > > > This is definitely a step in the right direction. PK should follow > > that and only display apps by default in the GUI. > > This is a very naïve position. For example, even in a pure gui system, > people want to select fonts (with previews), and fonts are not apps by > any definition. 1. I don't see any reason why we cannot mark fonts and provide a search specifically for them. 2. he said it was 'a step' in the right direction which it is. 3. you want a preview of the fonts - then we need that data somewhere - is it in each font pkg? > ”It has a .desktop file” barely scratches user needs. agreed - which is why we're going further. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Mon, 2010-08-23 at 16:47 -0400, Orcan Ogetbil wrote: > On Mon, Aug 23, 2010 at 4:23 PM, Matthew Miller wrote: > > On Mon, Aug 23, 2010 at 04:15:12PM -0400, Orcan Ogetbil wrote: > >> It would be good to define such a nonstandard abbreviation as "MTA" > >> when posting a new thread so that more people would know what is being > >> discussed. > > > > It's actually a long-standing and well-recognized term. > > > > I think it's one of those cases where if you don't know what it means, you > > probably don't care. > > > > I mean, if you're outside of Massachusetts, why are you interested in the > > Teachers' Association? > > > > Okay, Google didn't help much but our wiki did! I found this page: > https://fedoraproject.org/wiki/Features/NoMTA > > which tells me that MTA is mail transport agent. I have been using > postfix and sendmail for many many years, and until today I didn't > know that they were called MTA. > > It shouldn't be too hard to give a little definition (3 words) or just > copy and paste a link. We have new contributors every day and they > didn't participate in previous discussions. There is no need to > isolate them. Plus, people like me are bad with memorizing letters, or > giving them meanings unless they form proper words. Gosh, ask me what > MTA is in 2 months, and you will be surprised. :) > > References are good. Always. > repoquery --whatprovides MTA -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, 2010-08-24 at 10:00 -0400, Adam Jackson wrote: > On Tue, 2010-08-24 at 08:45 -0400, Matthias Clasen wrote: > > On Mon, 2010-08-23 at 23:06 -0400, Bill Nottingham wrote: > > > BOOTUP > > > - System boots successfully to GUI, when configured. > > > - System boots successfully to text mode, when configured. > > > - System properly handles being passed [1-5], 'single', 'S', 's', '-s', > > > booting to the appropriate 'runlevel' (0 and 6 can still work, > > > but they're sort of pointless anyway) When booted in this manner, > > > '5' will bring up a GUI, and '3' will not. > > > > You mean 'being passed on the kernel cmdline', I assume ? > > Do we consider interactive boot essential (I think not) ? > > Should mention something about forced fsck, maybe. > > What about selinux relabeling ? > > I can't remember interactive boot ever working. It always worked for me - and it saved my arse a number of times when a service starting up would go haywire and hang the system. I know it worked in rhel4 and rhel5 - so circa: fedora 3 and fedora 6 at the very least. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Tue, 2010-08-24 at 10:10 -0500, Michael Cronenworth wrote: > Andrew Haley wrote: > > I think there's a much more fundamental question here, which is > > whether a default Fedora installation is intended to be a real > > UNIX-like system or just the dependencies for GNOME. > > I was going to reply to Chris, but I'll reply here. > > What benefit do I, or anyone else, receive by shipping a 100% Unix-clone > environment >by default Unix-like be necessary for much longer? Are we making a Fedora for > people to use or for researchers to study? I think it really depends on what you mean by 'people'. If you mean people == someone using a laptop/desktop. OR do you mean people == someone who admins a lot of servers and desktops for others. And that is the crux of the issue and has always been the crux of the issue. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, 2010-08-24 at 14:28 -0400, Bill Nottingham wrote: > seth vidal (skvi...@fedoraproject.org) said: > > > > You mean 'being passed on the kernel cmdline', I assume ? > > > > Do we consider interactive boot essential (I think not) ? > > > > Should mention something about forced fsck, maybe. > > > > What about selinux relabeling ? > > > > > > I can't remember interactive boot ever working. > > > > It always worked for me - and it saved my arse a number of times when a > > service starting up would go haywire and hang the system. > > The keyboard shortcut has not worked reliably in quite a while (and > is already removed in F-14 - the command line option is there.) Works in rhel5. I'll test it in rhel6 in just a sec. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, 2010-08-24 at 15:46 -0400, seth vidal wrote: > On Tue, 2010-08-24 at 14:28 -0400, Bill Nottingham wrote: > > seth vidal (skvi...@fedoraproject.org) said: > > > > > You mean 'being passed on the kernel cmdline', I assume ? > > > > > Do we consider interactive boot essential (I think not) ? > > > > > Should mention something about forced fsck, maybe. > > > > > What about selinux relabeling ? > > > > > > > > I can't remember interactive boot ever working. > > > > > > It always worked for me - and it saved my arse a number of times when a > > > service starting up would go haywire and hang the system. > > > > The keyboard shortcut has not worked reliably in quite a while (and > > is already removed in F-14 - the command line option is there.) > > > Works in rhel5. > > I'll test it in rhel6 in just a sec. Doesn't work in rhel6 :( -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Tue, 2010-08-24 at 22:41 +0100, Matthew Garrett wrote: > On Tue, Aug 24, 2010 at 11:52:45AM -0700, Adam Williamson wrote: > > > FWIW, I'm with Jon and Adam on this one. I just don't see how not having > > an MTA by default is a win, except in disk space terms, and it takes up > > a tiny amount of disk space (especially if we pick a lighter-weight one > > than sendmail to be the default). I think it makes sense to keep one, > > for all the good reasons they cited. > > Shipping an MTA by default just gives developers the expectation that if > they pass something to sendmail then it'll be read by a human. Since > that's plainly untrue we should stop doing it and replace it with > something that's actually useful. > I'm not really in the giving-a-crap camp for the MTA or not but: that seems like a bit of odd logic. The logs are emitted to syslog with the same thought in mind - that someone will read them - but that is also not necessarily true. But I would not want to see us discarding syslog, either. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Tue, 2010-08-24 at 22:52 +0100, Matthew Garrett wrote: > On Tue, Aug 24, 2010 at 05:43:49PM -0400, seth vidal wrote: > > > that seems like a bit of odd logic. The logs are emitted to syslog with > > the same thought in mind - that someone will read them - but that is > > also not necessarily true. But I would not want to see us discarding > > syslog, either. > > We have a range of utilities that perform useful syslog parsing. The > fact that most of them then seem to pass that output to sendmail leaves > me a little less convinced that anyone pays the slightest bit of > attention to them. > > More realistically, we install syslog because it gives us debug > information that we (as developers) wouldn't otherwise be able to get. Maybe that's why you do it - but I don't. And we have a lot of utilities that parse and handle logs and send proper notifications on events we need to worry about. And the first person who mentions snmptrap events gets slapped. :) -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How many lost users is an acceptable loss in exchange for systemd?
On Wed, 2010-08-25 at 13:12 -0400, Gregory Maxwell wrote: > And, yes, the harm won't be equally distributed— it seems to me that > Fedora has ignored quite a bit of harm because it didn't primarily > fall on what the developer's considered a "typical desktop" (which, > as far as I can tell, really means a particularly narrow set of laptop > hardware with a particularly narrow set of users and use cases). Why > Fedora keeps chasing a market which Ubuntu has undeniably won is > beyond me— but nevertheless it's not acceptable to pretend that harms > don't exist simply because they don't hit the one use case you care > about most, not unless Fedora is willing to say that people running > servers, developers, and other power users ought to use some other > distribution and that Fedora doesn't care if it loses all of these > users. > Well - to be fair - fedora is going to take a big ding in terms of users whenever rhel6 (and centos6, I assume) is released. It'll be relatively new and stable-focused. Just like we did with rhel5.. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Wed, 2010-08-25 at 20:41 -0500, Mike McGrath wrote: > On Tue, 24 Aug 2010, Jeff Spaleta wrote: > > > On Tue, Aug 24, 2010 at 2:06 PM, Paul W. Frields > > wrote: > > > I don't think anyone can generalize that the usage of Fedora is > > > declining. What we can prove, and certainly is troublesome, is that > > > yum check-ins of successive releases have been dropping by a couple > > > percent each release (although downloads are actually up), compared on > > > a per-week basis. It's no less likely that this decrease is due to > > > people just staying on a stable release, even past EOL. I've heard > > > anecdotal evidence to support that, which is no more or less valuable > > > than any other anecdotal evidence being presented, I suppose (IOW, > > > probably not worth a thing). If someone can present a hard analysis > > > that points to only one possible scenario, fantastic -- we can start > > > looking at causes. > > > > One additional metric which I'd like to see is the raw number of yum > > check-ins per week regardless of ip-addresses as an historic trend. > > As a stand alone metric its prone to both over and under counting like > > the other metrics but in a different way. It would be interesting to > > see if the raw yum check-in counts as an historic trend followed the > > download trending or the unique-ip trending. > > > > Ask and ye' shall receive. > > http://mmcgrath.fedorapeople.org/yum_hits.html > > I'm not quite sure what to make of it all yet except that this trend does > conflict with the "current release" numbers we have on the statistics page > (indicating people are using Fedora even after EOL) and that security > incidents requiring a rebuild of everything is bad for business, at least > temporarily :) > HAHAHAH August 2008. sigh. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Fri, 2010-08-27 at 20:07 +0200, Björn Sund wrote: > repoquery --whatprovides MDA > repoquery --whatprovides MUA Honestly, I think things like that would be better off as pkgtags on the pkgs in the pkgdb! -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum appmarket
On Sun, 2010-08-29 at 14:06 +0100, Richard Hughes wrote: > On 19 August 2010 16:46, seth vidal wrote: > > Yesterday someone was talking about installing apps in fedora and how it > > was hard to figure out what to install/try b/c there were too much STUFF > > in fedora. They suggested an ‘app store’ like functionality. I explained > > that all the resources to do something like that exist in the > > infrastructure yum and friends offer now. I decided to prove that > > concept a bit. > > http://skvidal.fedorapeople.org/misc/appfinder.py > > Running that generates an xml file with only the ‘apps’ defined. > > Great. Then I wrote a yum plugin to access and use this data. > > I'm kinda disappointing you didn't use (or extend) > http://github.com/hughsie/app-install as it's what suse and ubuntu > already use, and I had planned to use in Fedora. > > I've looked at the xml metadata in your repo, and it seems to provide > very little in the way of the data we actually need in GUI tools, e.g. > translations, and icons names. The app-install metadata is a gzipped > sqlite and icons file, which is super quick to query compared to > parsing and building the xml tree. The xml that appfinder generated was just a comps format file and it was just for a proof of concept. I realized after this that I don't even need it the pkgTags db that we already generate has the information needed b/c all the apps are tagged with 'Application'. So no separate program is needed to generate the app metadata at all. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum appmarket
On Sun, 2010-08-29 at 15:26 +0100, Richard Hughes wrote: > On 29 August 2010 15:07, seth vidal wrote: > > I realized after this that I don't even need it the pkgTags db that we > > already generate has the information needed b/c all the apps are tagged > > with 'Application'. So no separate program is needed to generate the app > > metadata at all. > > What about application icons? > Florian has already been working that out. He's got a pure-python script that grabs up the icons and we'll work on implementing them at the pkgdb layer. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gnupg2 & evolution
On Mon, 2010-08-30 at 16:04 +0200, Christoph Höger wrote: > Hi, > > I cannot use gnupg2 from evolution anymore. Apparently somewhere in > evolution the command "gpg" is hardwired, while whe only have gpg2 > nowadays. > > Any suggestions? Testing updates or something? > yum install gnupg it's not being pulled in automatically b/c evolution doesn't actually DEPEND onf /usr/bin/gpg -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Mon, 2010-08-30 at 12:22 -0600, Stephen John Smoogen wrote: > The avalanche has already started, it is too late for the pebbles to vote. > > The changes towards a distribution that attracts people who live in > the moment happened a while back, and has been building momentum for > quite some time. Trying to erect barriers now is not going to help but > make it so nothing exists afterwords. The things that can be done are: > A) get out of the way, B) go with the flow, or C) figure out what you > can build on top of it. [I am looking at option C] > > > We've found our niche, but chasing away our previous niche (and having > > less users show up in our tracking mechanism for it) It's getting to > > the point where me, as a long time Fedora developer and sometimes > > leader, is not enjoying using Fedora any more. Every update run can > > What was our previous niche? That is what people seemed so hard to > ever quantify beyond knowing "what it isn't". The people I know who > are running Ubuntu now instead of RHL or Fedora are doing it because > that distribution 'fills in the blanks' for them that RHL/Fedora never > seemed to answer. It has a vision, it has a single voice where they > feel it is needed. Fedora has never been that. (heck even RHL was > never that as you couldn't get any of the RH developers to agree on > much :)). > I think the RHL niche was: 1. reasonably current 2. updated to a new release every 6months 3. supported for security/errata for 3yrs 4. free -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Mon, 2010-08-30 at 16:01 -0500, Chris Adams wrote: > I like the release schedule of Fedora, but I don't like the idea of each > release continuing to be a rolling update target. I don't really > understand why about six months (or less if you didn't install on > release day) is such a horrible wait to make big changes to the system. Agreed. > > Why do we need to be concerned about being similar to or different from > Ubuntu? Agreed. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gnupg2 & evolution
On Tue, 2010-08-31 at 20:04 +0200, Christoph Höger wrote: > Am Montag, den 30.08.2010, 10:08 -0400 schrieb seth vidal: > > On Mon, 2010-08-30 at 16:04 +0200, Christoph Höger wrote: > > > Hi, > > > > > > I cannot use gnupg2 from evolution anymore. Apparently somewhere in > > > evolution the command "gpg" is hardwired, while whe only have gpg2 > > > nowadays. > > > > > > Any suggestions? Testing updates or something? > > > > > > > > > yum install gnupg > > > > it's not being pulled in automatically b/c evolution doesn't actually > > DEPEND onf /usr/bin/gpg > > Yeah, that would work, if I wanted to use gnupg version 1, but I guess, > I'm better off staying at version 2. gnupg2 used to ship /usr/bin/gpg - > nowadays it does not. > > Seems like I should open up a bug report or something. I believe it does not anymore on purpose - but definitely file it to get an explanation. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum appmarket
On Wed, 2010-09-01 at 16:47 -0400, Colin Walters wrote: > On Sun, Aug 29, 2010 at 2:15 PM, seth vidal wrote: > > > > Florian has already been working that out. He's got a pure-python script > > that grabs up the icons and we'll work on implementing them at the pkgdb > > layer. > > Hmm, you're saying the client code would talk to pkgdb? not likely - we get the data into the pkgdb and out via the metadata. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mock-scm - a simple utility to integrate Mock with SCMs
On Thu, 2010-09-02 at 13:19 +0300, Marko Myllynen wrote: > Hi all, > > some people build their local RPMs with Mock because a Koji instance > might be a bit overkill in smaller environments. Keeping spec files and > possible patches under version control is always a good idea but > unfortunately Mock can't just be pointed to SCM repositories. > > Well, until now: mock-scm fetches spec and other files from SCM and > source packages either from SCM or a local directory, then it constructs > the source RPM on the fly and feeds it to Mock and finally collects the > results. So nothing extraordinary but might come in handy for those who > prefer keeping things under version control but don't want to set up a > Koji instance for building occasionally a handful of RPMs. > > mock-scm currently supports CVS and Git but adding, e.g., SVN should be > just few lines. It might need some tweaking to match different SCM/spec > conventions but that is left as an exercise for the reader. mock-scm can > be download from > > http://myllynen.fedorapeople.org/ > That looks cool - any thoughts on trying to merge it into mock itself? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Inspecting/debugging a mock build
On Sun, 2010-09-05 at 21:33 -0400, Braden McDaniel wrote: > I'm pretty much a novice at both mock and chroot. Where can I find out > how to change to the mock build chroot (using fedpkg or otherwise) so > that I can debug a failed mock build? > mock -r name-of-root-config --shell that'll get you into the chroot -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Tue, 2010-09-07 at 17:27 +0530, Rahul Sundaram wrote: > On 09/07/2010 05:16 PM, Richard Hughes wrote: > > Linux has traditionally shown the user packages to update and install, > > which is great for administrators, but sucks hard for end users. How > > many times have you been prompted with an update list that asks you to > > decide whether to update something you have no idea about[1]? > > > > Mo illustrated[2] a few days ago about how confusing the updater is > > and I agree with her; and it's mostly my fault. Lists of unlocalized > > generic packages are so 1990's, and compared with the Ubuntu Software > > Center or the Android App-store we look like amateurs. > > Thoughts on making the software center less distro specific? Couldn't > the UI be grafted on top of the PK api? okay - I'll bite - why do we want to make it less distro-specific? What does it get us? It means we have to deal with a bunch of Lowest-common-denominator issues and it means a looser coupling of the tools we have. It is legit to write tools for fedora that are FOR fedora. Why not do that? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Tue, 2010-09-07 at 09:19 -0400, Matthias Clasen wrote: > On Tue, 2010-09-07 at 09:11 -0400, seth vidal wrote: > > On Tue, 2010-09-07 at 17:27 +0530, Rahul Sundaram wrote: > > > On 09/07/2010 05:16 PM, Richard Hughes wrote: > > > > Linux has traditionally shown the user packages to update and install, > > > > which is great for administrators, but sucks hard for end users. How > > > > many times have you been prompted with an update list that asks you to > > > > decide whether to update something you have no idea about[1]? > > > > > > > > Mo illustrated[2] a few days ago about how confusing the updater is > > > > and I agree with her; and it's mostly my fault. Lists of unlocalized > > > > generic packages are so 1990's, and compared with the Ubuntu Software > > > > Center or the Android App-store we look like amateurs. > > > > > > Thoughts on making the software center less distro specific? Couldn't > > > the UI be grafted on top of the PK api? > > > > okay - I'll bite - why do we want to make it less distro-specific? What > > does it get us? It means we have to deal with a bunch of > > Lowest-common-denominator issues and it means a looser coupling of the > > tools we have. > > > > It is legit to write tools for fedora that are FOR fedora. Why not do > > that? > > Because sharing infrastructure and tools is raising the lowest common > denominator and benefits everybody ? Common good, etc... > > That being said, yes, doing things in less distro-specific ways does > involve compromise, and I'm not very optimistic about getting any of > that for the software center... yah - I have firsthand experience the pains of doing things in less distro-specific ways. The repodata was done that way and all changes require an enormous amount of discussion and frequently never happen b/c of the discussion. It is sometimes excruciating. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Tue, 2010-09-07 at 14:17 +0100, Richard Hughes wrote: > On 7 September 2010 14:11, seth vidal wrote: > > okay - I'll bite - why do we want to make it less distro-specific? > > For the same reason as pirut and pup were replaced. Fedora is *not* a > big enough ecosystem to drive fully localized and feature rich user > experiences. Working with other distros mean we can work as one big > team and share the burden of translation, bug-fixes and writing new > common code. I certainly don't want to write software for Fedora, but > rather write software for Linux, and then write the small amount of > Fedora interface code. Except we don't seem to do that. Over half of all commits to PK are from you. The next closest committer has 6% of commits. If I exclude the backends and translations then PK is written almost exclusively by you. So all the time you spent writing a compat layer of code for OTHER distros gets fedora what? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum's algorithm for resolving dependencies
On Tue, 2010-09-07 at 18:24 +, Andre Robatino wrote: > When installing packages with yum, if there is more than one enabled > repository > that can be used to resolve a dependency, how does yum choose which one to > use? > > I ask because I modified the instructions for installing the 32-bit wrapped > Flash plugin in 64-bit Fedora: > > https://fedoraproject.org/wiki/Flash#32_bit_wrapped_version > > and want to make sure that a libstdc++ dependency is satisfied by installing > the > 32-bit libstdc++ from Fedora's repos, and not Adobe Reader from Adobe's repo, > as > described here: > > http://lists.fedoraproject.org/pipermail/users/2010-May/373309.html > > Do the current instructions guarantee that this can't happen, or is it > necessary > to make sure the Adobe repo is disabled when running the first yum install > command (the one installing the nspluginwrapper and alsa-plugins-pulseaudio > packages)? > http://yum.baseurl.org/wiki/CompareProviders that's how it does it. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum's algorithm for resolving dependencies
On Tue, 2010-09-07 at 19:21 +, Andre Robatino wrote: > seth vidal fedoraproject.org> writes: > > > http://yum.baseurl.org/wiki/CompareProviders > > > > that's how it does it. > > Thanks. I didn't understand all of that, but since it only describes the > current > algorithm in detail, and the instructions refer to all versions of Fedora back > to F10, and I still don't know how to reproduce the Adobe Reader problem, I > just > modified the instructions to disable the Adobe repo in the first command, to > be > sure. run yum -d 7 install whatever with the adobe repo enabled and you'll see some lines like 'compare providers' - when you see those mentioning adobe reader those are the related entries. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora "backports" repo? (Was Re: PostgreSQL 9 for F14?)
On Wed, 2010-09-22 at 03:07 +0800, Liang Suilong wrote: > If someone has enough interest in backporting something from a newer > release, we can set up a personal repo on the repos.fedorapeople.org. > Just like firefox4 and yum-rawhide repo. > > > Maybe we wait for Copr. Seth Vidal is working on it. We can easily set > up and manage a backport or testing repo on Copr. I'm not alone. Toshio, mapleoin are doing the heavy lifting http://mapleoin.bluepink.ro/tag/copr.html for lots of info. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On Mon, 2010-09-27 at 13:48 -0400, Gregory Maxwell wrote: > The Fedora web resources (e.g. http://fedoraproject.org/get-fedora ) > continue to promote i686 installs over x86_64, the result being that > only a third of fedora users are on x86_64. > > When will the Fedora project begin recommending x86_64 as the > preferred option on the relevant hardware? i686 will run on x86_64 and i686 machines and on the overwhelming majority of hw someone will happen to have. x86_64 will not. until i686 is uncommon (which is still not yet) I think we should keep the default i686. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Getting more info about updates on headless server
On Thu, 2010-09-30 at 18:04 -0400, Przemek Klosowski wrote: > On 09/30/2010 05:45 PM, Richard Fearn wrote: > > Hi, > > > > I have yum-updatesd installed on a headless Fedora server, so every so > > often I get the email saying there are updates available. > > > > The email itself doesn't tell me much about the updates (e.g. for > > iproute tonight it said it was a "bugfix"). Running yum update on the > > server doesn't tell me much either. > > > > In the past I modified yum-updatesd-helper to look in the > > package-announce list archives > > (http://lists.fedoraproject.org/pipermail/package-announce/) to find > > each update, and to build a bodhi search URL, using the package > > name/version. Then there were at least 1 or 2 links in the > > yum-updatesd email that I could click on to get some more information. > > > > Is there a more standard way of getting this info? (Not the links, but > > the information about the updates.) > > You could download the RPMs (yumdownloader?) and look at changelogs: > > rpm -q --changelog -p > > I seem to rememeber people talking about a way to do it directly from > yum without downloading the package, but I don't remember the details. repoquery -q --changelog pkgname -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
On Mon, 2010-10-04 at 09:23 -0400, Brandon Lozza wrote: > On Mon, Oct 4, 2010 at 9:13 AM, Rahul Sundaram wrote: > > So according to you any free software with a trademark is non-free > > software? Good luck getting anyone including FSF to agree with that > > interpretation. > > > > Rahul > > I'm sure they will. Trademark restrictions violate one of the four > freedoms and if you want I can ask Richard Stallman directly if this > trademark rule makes software non-free. Actually I'll just go ahead > and do it just to prove a point. > > If I wanted to Fork Fedora, and I called it Fedora, i'd soon see a > letter from Redhat legal. I'm not free to use the name. Thus, if I > fork Fedora I am required by trademark law to rename it or be in > violation. You might consider taking this discussion to the legal alias and talking it over there. It seems to be beyond 'devel' at the moment. thanks -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
On Mon, 2010-10-04 at 11:35 -0400, Brandon Lozza wrote: > On Mon, Oct 4, 2010 at 11:34 AM, Michal Schmidt wrote: > > On Mon, 4 Oct 2010 11:24:30 -0400 Brandon Lozza wrote: > >> Firefox doesn't just include source code. It includes intellectual > >> property with specific restrictions on what you're allowed to do with > >> it. > > > > Did you use the term "intellectual property" in your query to Richard > > too? :-) > > http://www.gnu.org/philosophy/not-ipr.html > > http://www.gnu.org/philosophy/words-to-avoid.html#IntellectualProperty > > > > Michal > > -- > > devel mailing list > > devel@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/devel > > > > Just to those with thick skulls You're out of line. please stop. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On Mon, 2010-10-11 at 13:18 -0400, Bill Nottingham wrote: > Chris Lumens (clum...@redhat.com) said: > > > - downloads updates in parallel too > > > > Package updates? > > 1) Given that it's using yum, downloading multiple things in parallel > would need to be fixed there. We have an open rfe for related things - we're hoping to combine two rfe's into one: 1. have the pkg/metadata downloads run in a different process in a different context - for selinux 2. have each repo have its own downloader process which can handle however many pkgs/metadata at a time that downloader process can cope with. If someone wants to work on that come by #yum -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tue, 2010-10-19 at 14:56 +0100, Matthew Garrett wrote: > On Tue, Oct 19, 2010 at 02:43:33PM +0100, Paul Howarth wrote: > > > This despite the FHS says (right at the top of Chapter 3, the Root > > Filesystem): > > > >/usr, /opt, and /var are designed such that they may be located on other > >partitions or filesystems. > > > > Do we *really* want to head this way, ignoring bugs resulting from > > having /usr on a different partition such as > > http://bugzilla.redhat.com/#626007, which is what led to this? > > What's the benefit in having /usr or /opt as separate filesystems? > /opt is a location filled with vendor detritus on a lot of systems - sometimes managed by rpms, sometimes not. It's not uncommon to have /opt automounted via nfs. Additionally, on some workstastion systems /opt is a separate drive managed by the 'local admin' of the machine and filled with whatever 3rd party software they need for their instance. /usr is frequently given different mount options (like noatime, for example) or mounted readonly to prevent unnecessary writes to the system. Additionally, since our software in fedora has a trickle down impact on users in rhel-land I think you'll find that this will have to be done, eventually for them. Finally, I'm more than a little concerned by the tone of comments in that bug report. It's troubling. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tue, 2010-10-19 at 15:56 +0100, Matthew Garrett wrote: > > /usr is frequently given different mount options (like noatime, for > > example) or mounted readonly to prevent unnecessary writes to the > > system. > > That doesn't require it to be a separate partition. Mounting the location meaningfully as a readonly does. If you're doing it for security reasons. > > Additionally, since our software in fedora has a trickle down impact on > > users in rhel-land I think you'll find that this will have to be done, > > eventually for them. > > "We have to support it because users want it" is a poor argument. We > have to understand why people want it to be a separate partition and > then decide whether the simplest way (in terms of overall engineering > effort) to support those desires is by supporting it as a separate > partition. So far nobody's come up with a terribly plausible reason for > why /usr should be separate. I'm confused here - why is it we have to come up with a plausible reason? Why is the burden of proof on KEEPING /usr as a separatable partition? If I said tomorrow "yum will not support feature foo or bar" that have been in rpm and yum since the dawn of time I'd have to defend my rationale for that change. So it seems like you need to explain why you think /usr should NOT be on a separate partition. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tue, 2010-10-19 at 16:05 +0100, Matthew Garrett wrote: > On Tue, Oct 19, 2010 at 04:59:29PM +0200, Michal Hlavinka wrote: > > > another benefit (not yet mentioned) is for filesystem encryption. I have / > > and > > /home encrypted and /usr not encrypted (for better performance of my laptop) > > I'm kind of curious about this. What's on / that benefits from being > encrypted? Logfiles, some stuff in /etc? Yes to both of those. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tue, 2010-10-19 at 16:11 +0100, Matthew Garrett wrote: > On Tue, Oct 19, 2010 at 11:07:24AM -0400, seth vidal wrote: > > On Tue, 2010-10-19 at 16:05 +0100, Matthew Garrett wrote: > > > On Tue, Oct 19, 2010 at 04:59:29PM +0200, Michal Hlavinka wrote: > > > > > > > another benefit (not yet mentioned) is for filesystem encryption. I > > > > have / and > > > > /home encrypted and /usr not encrypted (for better performance of my > > > > laptop) > > > > > > I'm kind of curious about this. What's on / that benefits from being > > > encrypted? Logfiles, some stuff in /etc? > > > > Yes to both of those. > > Well, I don't think people have suggested removing /var as a separate > mountpoint. The stuff in /etc is a much more interesting case. Do you > have some examples? Password/Shadow files? SSL Certs/SSL Keys for various kinds of daemons or clients. RHN ssl certificates and auth keys? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tue, 2010-10-19 at 16:08 +0100, Matthew Garrett wrote: > On Tue, Oct 19, 2010 at 11:03:50AM -0400, seth vidal wrote: > > On Tue, 2010-10-19 at 15:56 +0100, Matthew Garrett wrote: > > > > > > /usr is frequently given different mount options (like noatime, for > > > > example) or mounted readonly to prevent unnecessary writes to the > > > > system. > > > > > > That doesn't require it to be a separate partition. > > > > Mounting the location meaningfully as a readonly does. If you're doing > > it for security reasons. > > It doesn't. You can make it a read-only bind mount. If the files are still read-write at another location then something iterating over disks/locations can still find it. That's what I meant by meaningfully. > > I'm confused here - why is it we have to come up with a plausible > > reason? Why is the burden of proof on KEEPING /usr as a separatable > > partition? > > Because it takes more engineering effort to keep it as a separate > partition, as evidenced by the number of bugs that keep appearing that > are only triggered by this niche usecase. Hmm, So when this was broken a lot of bugs were triggered? Sure seems like if a lot of bugs are being triggered then it is NOT a niche usecase. You can't have it both ways. > > If I said tomorrow "yum will not support feature foo or bar" that have > > been in rpm and yum since the dawn of time I'd have to defend my > > rationale for that change. > > If yum removed features that provided functionality that could be > achieved via other means, and in return various other features worked > better, I'd be fine with that. It's not clear to me that other features work better in the case you're describing and it will mean retooling for what sounds like a good number of users. > > So it seems like you need to explain why you think /usr should NOT be on > > a separate partition. > > Because it adds additional complexity for no obvious gain. that's not plausible enough, imo. There is clear gain to enough users to file a 'number of bugs'. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tue, 2010-10-19 at 11:18 -0400, Peter Jones wrote: > >>> So it seems like you need to explain why you think /usr should NOT be on > >>> a separate partition. > >> > >> Because it adds additional complexity for no obvious gain. > > > > that's not plausible enough, imo. There is clear gain to enough users to > > file a 'number of bugs'. > > Presumably because they don't know about the other ways to accomplish the > same goal that aren't as painful to support? Failure to document and explain to our users the virtues of the changes and the different ways of accomplishing those goals then squarely falls on our shoulders, Peter. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tue, 2010-10-19 at 16:22 +0100, Matthew Garrett wrote: > > > > Hmm, So when this was broken a lot of bugs were triggered? > > > > Sure seems like if a lot of bugs are being triggered then it is NOT a > > niche usecase. > > > > You can't have it both ways. > > Very few people do it. When they do, lots of things break. It's kind of > like trying to run Fedora under the NetBSD Linux emulation. Nobody does > it, but if they did they'd find that a surprising quantity of code > wouldn't work. you keep asserting this claim - and yet all the evidence in terms of concerned users comes to the contrary. Can you document or backup your assertion? > Every Fedora update requires significant retooling. The fact that these > bugs exist indicates that there would be advantages to not supporting > this, providing that in return we can satisfy all the existing user > requirements. "/usr is a separate partition" is *not* a meaningful user > requirement, any more than "Fedora release names must start with a > consonant". If we can provide better and more generalisable solutions > for their requirements then that's a win for everyone. Again - I'm going to ask you to stop making that assertion. You're stating it as an established fact when it is CLEARLY the point in contention. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tue, 2010-10-19 at 15:40 -0500, Chris Adams wrote: > Once upon a time, James Antill said: > > Putting my really old sysadmin hat on, one other reason for > > having /tmp, /var and /usr as separate mount points was so that you > > could allocate different disk space to each (and they couldn't break > > each other) ... do we have other solutions for that? > > On a multi-user server (and that includes web access like PHP or CGI), > you really don't want user-writable directories on a filesystem with > anything important, especially security-sensitive things like setuid > binaries. Hard-link tricks are evil. I run with a separate /tmp > (usually tmpfs now) and bind mount it to /var/tmp as well. Not to get too far off into the weeds but Polyinstantianed tmpdir (pam_namespace) are a good idea here. Everyone gets their on /tmp and /var/tmp and no one else can see them. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: retire bittorrent
On Sat, 2011-06-25 at 22:23 -0500, Jeffrey Ollie wrote: > On Wed, Jun 15, 2011 at 9:55 PM, seth vidal wrote: > > > > Heck, I'd be willing to accept ANY bittorrent server that can be both > > tracker and primary seed and doesn't require a special apache module to > > do it. > > > > The biggest virtue of the old bittorrent client is that it is simple, > > stand alone and while not fancy, it is straightforward to understand. > > Why not look into using Web/HTTP seeding rather than running a client > for the initial seed? The only downsides that I know of so far: > > 1) Not supported in rtorrent > 2) Transmission doesn't apply any bandwidth limits to Web/HTTP seeds > Following up late on this, sorry. The seed is less of an issue than the tracker. Is there a solution to that? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: retire bittorrent
On Sun, 2011-06-26 at 00:22 -0500, Michael Cronenworth wrote: > On 06/15/2011 09:55 PM, seth vidal wrote: > > Heck, I'd be willing to accept ANY bittorrent server that can be both > > tracker and primary seed and doesn't require a special apache module to > > do it. > > Late to the party with this response but here it is anyway. > > I'd suggest switching to magnet links. They would negate the need for a > tracker and the need for serving a .torrent file. googling around gets me info on how magnet links work. Now, what tools do we have in fedora to generate them and the Distributed Hash Tables. I'd be pleased to dump out all of the special needs for the torrent server. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd vice SysV/LSB init systems - what next ?
On Tue, 2011-07-19 at 13:34 +, "Jóhann B. Guðmundsson" wrote: > Now if you just happen to be a sysadmin then I suggest you either get > with the program or expect to be out of job tomorrow since there is > plethora of competent sysadmins out there that are able and willing and > after your job... That remark is neither necessary nor in keeping with fedora's community standards. Please stop. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd vice SysV/LSB init systems - what next ?
On Tue, 2011-07-19 at 09:57 -0400, Adam Jackson wrote: > On Tue, 2011-07-19 at 11:11 +, JB wrote: > > > My suggestion is that you keep both init systems, SysV/LSB and systemd, > > as separate offerings out of many, and forever so. > > We'll take that under advisement. Ajax, That remark is also unnecessary and just comes across as snarky. The only thing this will achieve is to keep other people from being willing to comment on issues in the future. Please stop this. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd vice SysV/LSB init systems - what next ?
On Tue, 2011-07-19 at 12:16 -0400, Bill Nottingham wrote: > seth vidal (skvi...@fedoraproject.org) said: > > > > My suggestion is that you keep both init systems, SysV/LSB and systemd, > > > > as separate offerings out of many, and forever so. > > > > > > We'll take that under advisement. > > > > Ajax, > > That remark is also unnecessary and just comes across as snarky. The > > only thing this will achieve is to keep other people from being willing > > to comment on issues in the future. > > So, the preference is to say nothing at all? > In lieu of a snarky/derisive comment, yes, that's correct. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd vice SysV/LSB init systems - what next ?
On Tue, 2011-07-19 at 08:45 -0800, Jeff Spaleta wrote: > Just because shell scripts are familiar doesn't make then easier. > Shell scripts can be quite quite fragile. Collectively as admins > we've grown very attuned to dealing with shell semantics good and bad. > None of us who are deeply familiar with shell can You easily assess > the relative merits of systemd because we aren't familiar with systemd > yet. > > > I've heard the same arguments from other people in other contexts for > years, especially in scientific computing. Why on earth should anyone > ever need to learn anything except IDL scripting for scentific data > analysis. It was good enough 20 years ago..its good enough now. We > have all this complex fragile IDL scripting codebase built up. Why on > earth would be through it a way for html5 based data plotting? > > I'm utterly unmoved by any arguments which boil down to "I'm familiar > with this 20+ year old tech, and I don't want to learn something new" > > > Familiar is not automatically easier or better, harder or worse. It is > simply familiar and the longer we hold on to the familiar the harder > it will every be for us to take the time to invest in better > technologies so we can realize the full potential of those > technologies I agree with one section of your argument: arguments which are just "I'm not used to this" are bad arguments. Many of the arguments presented in this and other threads do not boil down to that. If you believe them to do so, Jeff, then you're presenting a straw man as I'm sure you're aware. Many of the arguments are this: All change has a cost. That cost is offset by the benefit of the new feature functionality. If you introduce change with relatively low introduction cost then you don't need much benefit to justify it. If you introduce change with a relatively high introduction cost then the benefits better be significant to justify it. This isn't about familiarity, it is simple economics. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Starting user UIDs at 1000 - please check your packages
On Thu, 2011-07-21 at 12:57 -0400, James Antill wrote: > On Wed, 2011-07-20 at 22:59 +0200, Miloslav Trmač wrote: > > On Wed, Jul 20, 2011 at 10:55 PM, James Antill > > wrote: > > > Is it really necessary to change this in %pre ... can't you just copy > > > your old login.defs file over the installed one during kickstart %post > > > (or even do it by hand, post install)? > > > > Unfortunately it is necessary to do it in %pre because users and > > groups created in package scriptlets without specifiying an UID/GID > > explicitly get assigned 999, 998, ... . > > Doing it this way means it is guaranteed 100% incompatible between > versions, NFS etc. will be a giant pain for a lot of users. Would it not > be possible to change the behaviour to be more compatible (Eg. assign > the first 99 from 499-400, and then move to 999)? > It seems like a big price to pay to go from "you may be affected" to > "we guarantee we've it". I agree. We KNOW that this will impact a number of users - many of them in a position to have to support older machines and newer machines and will be wedged with some awful solutions for a while. If we can't go to 999 how about we go way up to the 2million+ range? either way: +1 to what James wrote. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Starting user UIDs at 1000 - please check your packages
On Thu, 2011-07-21 at 17:02 -0400, Simo Sorce wrote: > On Thu, 2011-07-21 at 13:59 -0400, seth vidal wrote: > > On Thu, 2011-07-21 at 12:57 -0400, James Antill wrote: > > > On Wed, 2011-07-20 at 22:59 +0200, Miloslav Trmač wrote: > > > > On Wed, Jul 20, 2011 at 10:55 PM, James Antill > > > > wrote: > > > > > Is it really necessary to change this in %pre ... can't you just copy > > > > > your old login.defs file over the installed one during kickstart %post > > > > > (or even do it by hand, post install)? > > > > > > > > Unfortunately it is necessary to do it in %pre because users and > > > > groups created in package scriptlets without specifiying an UID/GID > > > > explicitly get assigned 999, 998, ... . > > > > > > Doing it this way means it is guaranteed 100% incompatible between > > > versions, NFS etc. will be a giant pain for a lot of users. Would it not > > > be possible to change the behaviour to be more compatible (Eg. assign > > > the first 99 from 499-400, and then move to 999)? > > > It seems like a big price to pay to go from "you may be affected" to > > > "we guarantee we've it". > > Sometimes you have to break some eggs, that said I would favor changing > the behavior to grow from 400 up to 999 instead of grown down from 999 > to 400, sounds more sensible. > > > I agree. We KNOW that this will impact a number of users - many of them > > in a position to have to support older machines and newer machines and > > will be wedged with some awful solutions for a while. > > > > If we can't go to 999 how about we go way up to the 2million+ range? > > That would be *much* worse. > Why? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding ~/.local/bin to default PATH
On Wed, 2011-07-27 at 15:54 +0200, Lennart Poettering wrote: > I think the discussion where to place this is moot anyway, as the spec > has been written years ago and widely (though not universally) > implemented, and we should just stick to it, since where it to place it > is nothing more than bike shedding anyway. But we shouldn't have to stick to the FHS? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Intent to package GNOME Shell frippery
On Sat, 2011-07-30 at 02:23 -0400, Jon Masters wrote: > So, just so I understand, the requirement/assumption is that all > machines will be online and pulling bits down directly from GNOME? That > won't map at all to enterprise or non-fully connected environments. It > needs to be possible to install/provision a system with this kind of > functionality because users are going to want to get these extensions. > > David: on the subject of your followup...my advice, by the way, is that > life is too short to continue to try to explain why GNOME Shell is > unusable for folks like you and I. I'd just switch to XFCE and be done > with it. My machines are a lot happier for having made the switch :) +1. There are also some very nice dock-programs available which make xfce even more easy to use. definitely recommended rather than tilting at windmills with gnome3. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To Require or not to Require?
On Sat, 2011-08-13 at 09:19 +0200, Michael Schwendt wrote: > On Fri, 12 Aug 2011 12:08:50 -0400, SS (Simo) wrote: > > > If rpmbuild does not add an implicit requires with libraryX >= > we built against> then it is certainly broken. > > One could also argue that an activity like "yum install ..." ought to > search for and apply the latest available updates of needed packages. Such > behaviour has been rejected some years ago, if memory serves correctly. It was rejected with good reason, I think. I do not think we should be adding functionality into yum which: 1. violates the principle of least surprise for the admin 2. covers up for not-specific-enough requirements in the packaging. It just feels like it would be fixing a "problem" at the wrong layer. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Fri, 2011-08-19 at 17:47 +0200, Lennart Poettering wrote: > Well, I think Fedora is more interested in real-life users than > synthetic certifications. I think you are not the arbiter of what fedora is interested in. If this is a point of conflict it should be discussed with the board and fesco. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: "Baseurl" download source for now?
On Wed, 2011-09-07 at 17:53 +0400, Dmitry Butskoy wrote: > I've discovered data inconsistencies in a (nearest) mirror of Fedora. > > For me, > "https://mirrors.fedoraproject.org/metalink?repo=updates-released-f$releasever&arch=$basearch"; > > return a mirror at "mirror.yandex.ru". > > Assuming it is some temporary issues, I prefer to switch (for a while) > to the "baseurl" in the repo config file, ie. to > http://download.fedoraproject.org/pub/fedora/linux/updates/$releasever/$basearch/ > > . > But any attempt to address this link returns me the same mirror at > yandex.ru. > > IOW, it seems that "baseurl" is the same behavior as "mirrorlist". > > How can I download something from the "primary", "baseurl" Fedora repos > (not from mirrors)? > download.fedoraproject.org hits a redirector which sends you to the nearest mirror from mirrormanager. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: "Baseurl" download source for now?
On Wed, 2011-09-07 at 18:04 +0400, Dmitry Butskoy wrote: > seth vidal wrote: > > download.fedoraproject.org hits a redirector which sends you to the > > nearest mirror from mirrormanager. > > > > Well, but what should I do if that mirror seems broken? Broken how? If the mirror is not functional yum should switch to the next mirror in your mirrorlist from mirrormanager. > Try to obtain > the full mirror list and try each mirror step by step? Why we no more > provide just a true "baseurl"? Go to the url from the mirrorlist= line in a webbrowser and it will give you all the baseurls you could possibly desire. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: "Baseurl" download source for now?
On Wed, 2011-09-07 at 19:16 +0400, Dmitry Butskoy wrote: > Dmitry Butskoy wrote: > > seth vidal wrote: > > > >> On Wed, 2011-09-07 at 18:04 +0400, Dmitry Butskoy wrote: > >> > >> > >>> Well, but what should I do if that mirror seems broken? > >>> > >>> > >> Broken how? > >> > > Some SRPMS in fedora/linux/updates/14/SRPMS are missed. > > > > Now the files have appeared, but the repomd.xml files are still differ. > > Compare: > http://download.fedora.redhat.com/pub/fedora/linux/updates/14/SRPMS/repodata/repomd.xml > and > http://mirror.yandex.ru/fedora/linux/updates/14/SRPMS/repodata/repomd.xml > > It seems something is not reliable in the mirroring process... > it is a mirror - it happens gradually. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: "Baseurl" download source for now?
On Wed, 2011-09-07 at 11:30 -0400, Josh Boyer wrote: > On Wed, Sep 7, 2011 at 11:18 AM, seth vidal wrote: > > On Wed, 2011-09-07 at 19:16 +0400, Dmitry Butskoy wrote: > >> Dmitry Butskoy wrote: > >> > seth vidal wrote: > >> > > >> >> On Wed, 2011-09-07 at 18:04 +0400, Dmitry Butskoy wrote: > >> >> > >> >> > >> >>> Well, but what should I do if that mirror seems broken? > >> >>> > >> >>> > >> >> Broken how? > >> >> > >> > Some SRPMS in fedora/linux/updates/14/SRPMS are missed. > >> > > >> > >> Now the files have appeared, but the repomd.xml files are still differ. > >> > >> Compare: > >> http://download.fedora.redhat.com/pub/fedora/linux/updates/14/SRPMS/repodata/repomd.xml > >> and > >> http://mirror.yandex.ru/fedora/linux/updates/14/SRPMS/repodata/repomd.xml > >> > >> It seems something is not reliable in the mirroring process... > >> > > > > it is a mirror - it happens gradually. > > It might be worth pointing out that mirrors.kernel.org has been down > for a couple of days, so any of the other mirrors that sync from that > will be stale. A good point. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: createrepo --update litters CWD with "garbageid" directory
On Tue, 2011-09-13 at 10:08 -0500, Richard Shaw wrote: > I noticed this started in F15, but when I run "createrepo --update > ..." it litters the current directory with a "garbageid" directory. > I'm not sure if anything ever exists in it but after createrepo exits > the directory is always empty for me. > > Is there a reason for this or is this a bug? It _was_ a bug and it has been fixed upstream. https://bugzilla.redhat.com/show_bug.cgi?id=728584 I'm planning on pushing out a new createrepo this week which closes a number of these items. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On Fri, 2011-09-16 at 11:33 -0500, Matyas Selmeci wrote: > Hi all, > > Hope it's okay to ask for general RPM/Yum advice here. > > We have several packages that require grid CA certificates to be > installed. There are multiple sets of grid certificates, and we want to > leave up to individual sites which set to install. We also want to give > the sites the option to install none of them if they know what they are > doing and want to manage certificates by themselves. > > So what we do is we add to each package that requires grid certificates > a 'Requires: grid-certificates' line, and to each package that provides > grid certificates a 'Provides: grid-certificates' line. We also create a > dummy package, called 'no-ca-certs' that does nothing but provide the > grid-certificates dependency. > > We want to set it up so that one of these certs packages is preferred > over the others, so that if the user doesn't explicitly choose which one > to install, then that package is installed by default. How can we do > that? We tried having the packages provide different versions of the > grid-certificates virtual dependency (i.e. no-ca-certs would have > 'Provides: grid-certificates = 1', osg-ca-certs (which we prefer) would > have 'Provides: grid-certificates = 2') in hopes that yum would pick the > one with the highest version, but it didn't help. Any ideas? Here is how yum does comparison between multiple package providing the same thing: http://yum.baseurl.org/wiki/CompareProviders if you follow that as your guide you can probably make one of them be the default choice. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On Fri, 2011-09-16 at 18:26 +0100, Richard Hughes wrote: > On 16 September 2011 17:36, seth vidal wrote: > > Here is how yum does comparison between multiple package providing the > > same thing: > > http://yum.baseurl.org/wiki/CompareProviders > > I don't think that works for all cases; surely "grid-certificates = 2" > wins over "grid-certificates = 1" in all cases? It's certainly better > than relying on the length of the package name or alphabetical > ordering... Which, if you read, yum doesn't do exclusively. Here's what yum does. 0. each pkg starts out with a score of 0. 1. if any of the providers is a newer version of something we have installed then increase their score by 5 2. if any of the providers are not the newest version of themselves then decrease their score by 1024. 3. if any of the providers are obsoleted by another provider, decrease that provider by 1024. 4. check the arch distance between the requiring pkg and each of the providers. The pkg with the smallest arch distance gets a 5 added to their score. Do the same check but comparing the pkg arch distance to the system arch, not the requiring pkg arch 5. compare the sourcerpm on each provider to the requiring pkg's source rpm. If they share a sourcerpm add 20 to the score 6. check the base pkg for each subpkg. If the base pkg is installed on the system add 5 to the provider's score. 7. check the prefix of the pkg to the requiring pkg prefix (perl-foo and perl-lib) for each common character in the prefix add 2 points to the provider's score. 8. if, at this point, we have pkgs with an equal score - look at the deplist (one layer deep) and see what they would pull in that is NOT already installed. Add 1 to the score of the pkg with the least new deps to be pulled in. 9. if all else fails and we STILL have two pkgs with the same score - take the leaders from the list and compare their name length. We add 1,000 and then subtract the length of the number of character's in the pkgs name from its score (the addition of 1000 is to ensure that one of the leaders will be picked). 10. return the list of providers, sorted best to worst. 11. if the packages are the same length, then the packages are compared as shown in "yum list". The one lower in the list will win. > > In Zif, I'm doing something like: > > * Filter by best arch > * Filter by depend version > * Filter by native arch > * Filter by smallest name > * Filter by newest So you fail to take shortest number of deps and you're going to generally fail for a any number of pkgs which really need a closely-related sibling package but something else outside of their srpm also provides what they need. That happens a lot in the kde/gnome world and with many of the languages with a large number of modules. (python, perl, etc) Yum's depsolving and provider comparison is significantly more mature and works in actual uses not just theoretically. That you've implemented a depsolver for use with PK that does not match yum nor anaconda is pretty bad. You've chosen intentional incompatibility. That's neither helpful nor really embodying the goals I like to think of in fedora. > non-native architecture packages onto their system for an update and > want to follow the latest provide version (even if that means > installing additional deps). The current logic where yum wants to > install a hundred i686 packages on my x86_64 box when the repos get a > bit screwy doesn't seem to work very well in my opinion. There are still a largish number of packages out there that have things like: Requires: foo where they really want: Requires: foo(64bit) Which causes the other path you're describing. It's sad that you've chosen to implement something else entirely on your own rather than working with the growing number of people working on yum. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On Fri, 2011-09-16 at 19:31 +0200, Miloslav Trmač wrote: > On Fri, Sep 16, 2011 at 7:26 PM, Richard Hughes wrote: > > On 16 September 2011 17:36, seth vidal wrote: > >> Here is how yum does comparison between multiple package providing the > >> same thing: > >> http://yum.baseurl.org/wiki/CompareProviders > > > In Zif, I'm doing something like: > ... > > I don't particularly care how the best provider is selected, but > having different tools use different rules is not acceptable. having different tools is not acceptable. Especially when one of them is not even remotely covering the use cases of our actual users. I think I'm going to suggest to fesco that all non-yum depsolvers be removed from the distribution. It just creates more work than it does value. If someone wants to ship a depsolver in their own repo on fedorapeople, that's fine but providing it in the distro is just a mistake. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On Fri, 2011-09-16 at 19:42 +0100, Richard Hughes wrote: > On 16 September 2011 18:43, seth vidal wrote: > > having different tools is not acceptable. Especially when one of them is > > not even remotely covering the use cases of our actual users. > > Installing 205 new i686 packages when updating the system is not acceptable. I agree with that. The cases where that occurs are all tied up in insufficiently specified requirements. > > I think I'm going to suggest to fesco that all non-yum depsolvers be > > removed from the distribution. It just creates more work than it does > > value. > > Ha! That's really funny, and it's just made my evening. While you're > asking fesco, can you also ask them to remove KDE and XFCE as well > please. I've made the proposal for non-yum-based package managers to be removed from fedora. Your attitude is quite unfortunate. I'd hope you'd want to work with others to make fedora better but you don't. There's a packaging team you should work with and for if you intend to continue working on package managers. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On Fri, 2011-09-16 at 19:48 +0100, Richard Hughes wrote: > 2011/9/16 Miloslav Trmač : > > How about the 1126 members of the "packager" group - i.e. most of us - > > that would have to create and maintain packages compatible with two > > different systems? > > That's nonsense, sorry. Zif is quite capable of using the same > metadata as yum and performing the same function with the same set of > packages. Not if Zif is coming up with different results for providers. Since you've developed entirely in your own silo I suspect you've failed to discover the bevy of edge and corner cases which plague package management. You should consider working with the packaging team. They have a combined experience and history of rpm and yum with millions and millions of installs and users of each to draw from. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On Fri, 2011-09-16 at 20:02 +0100, Richard W.M. Jones wrote: > Is Zif a SAT solver? > > We could really use a SAT solver to replace the current yum depsolver. no, it is not a satsolver. 1. a satsolver is not the panacea that is purported to be - you end up with some funny resolutions that do satisfy the requirements but not sensibly. 2. a satsolver is going to require changing around how we truck the repodata around a good bit. 3. if a satsolver is implemented it needs to be done so that anaconda can use it too. Not to mention mock, the compose tools, masher, etc. All of our tools go through yum - if we want to change things - doing it in yum makes for a lot fewer code changes to everything else - not to mention the code we don't control which uses it. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On Fri, 2011-09-16 at 11:07 -0800, Jef Spaleta wrote: > > > > And since we seem to only be talking about optimization of policy > rules (which could and probably should equally apply to all depsolvers > in Fedora) shouldn't it be possible to encode your possibly more > optimal policy rules as a yum plugin specifically so we can do some > testing without conflating the depsolving policy optimization with > other tehcnical changes? If your approach to depsolving really is > better, we should be able to test that systematically with existing > repo data transactions and build a case for a depsolving rule change > as part of yum's evolution. > As a point of fact we added a depsolving plugin hook for compare_providers over a year ago into the yum codebase. Specifically so anyone could do fun and exciting additions to compare_providers and/or request user input on the decisions. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
