Re: Fedora 17’s unified filesystem (/usr-move)
On Tue, 2012-01-31 at 10:52 -0500, Bill Nottingham wrote: Bill Nottingham (nott...@redhat.com) said: Miloslav Trmač (m...@volny.cz) said: On Tue, Jan 31, 2012 at 1:06 AM, Martin Langhoff martin.langh...@gmail.com wrote: But you can add: Provides: /bin/foo Ugh! Will that be needed that across the distro for a release or two? http://pkgs.fedoraproject.org/gitweb/?p=coreutils.git;a=commitdiff;h=09220fef36dcc2fe06bd858578119872f889c7e2 That should not be needed. To be precise: [root@nostromo ~]# mv /bin /cow [root@nostromo ~]# /cow/ln -s /cow /bin [root@nostromo ~]# rpm -qf /cow/bash bash-4.2.20-1.fc16.x86_64 [root@nostromo ~]# rpm -qf /bin/bash bash-4.2.20-1.fc16.x86_64 rpm should already handle this, no need for the provides. Good to see everyone still doesn't read what I write. As I said, rpm _does something_ to make the above work for -qf (the above even works if you inside /cow ... as long as the /bin symlink exists!). However, it _does not_ work, if you put the above in package provides/requires and try to install them. Eg. http://james.fedorapeople.org/yum/sym1.spec http://james.fedorapeople.org/yum/sym2.spec ...you _cannot_ install these packages, even via. local only rpm. Also, even if someone could fix rpm to work this out, making this work at the yum layer is _much_ harder ... because the repodata does not currently specify that /path/to/blah is a regular file or a symlink (and if it's a symlink, what it points to). So the coreutils provides _are needed_ (along with all others), or the coreutils package has to lie and say it is installing the packages into a dir. /bin. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On Tue, 2012-01-31 at 11:03 -0500, Bill Nottingham wrote: Miloslav Trmač (m...@volny.cz) said: To be precise: [root@nostromo ~]# mv /bin /cow [root@nostromo ~]# /cow/ln -s /cow /bin [root@nostromo ~]# rpm -qf /cow/bash bash-4.2.20-1.fc16.x86_64 [root@nostromo ~]# rpm -qf /bin/bash bash-4.2.20-1.fc16.x86_64 rpm should already handle this, no need for the provides. Elsewhere in this thread it was pointed out that yum doesn't handle it the same way. When calculating local on-system provides, it should - in fact, I'd be surprised if it doesn't. Admins sometimes move directories around and replace them with symlinks. I would be _very_ surprised if rpm let you install foo which requires /bin/bash ... if bash _only_ provided /usr/bin/bash and another package (or even the same one) provided /bin = /usr/bin. I'm not 100% sure what -qf is doing, but I'd guess it's just walking the basename list and seeing if anything matches the inode of what is passed in ... which is fine for query, to help the sysadmin. out, but I'd guess would be very expensive at install time. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On Tue, 2012-01-31 at 15:58 -0500, Bill Nottingham wrote: James Antill (ja...@fedoraproject.org) said: [root@nostromo ~]# mv /bin /cow [root@nostromo ~]# /cow/ln -s /cow /bin [root@nostromo ~]# rpm -qf /cow/bash bash-4.2.20-1.fc16.x86_64 [root@nostromo ~]# rpm -qf /bin/bash bash-4.2.20-1.fc16.x86_64 rpm should already handle this, no need for the provides. Good to see everyone still doesn't read what I write. As I said, rpm _does something_ to make the above work for -qf (the above even works if you inside /cow ... as long as the /bin symlink exists!). However, it _does not_ work, if you put the above in package provides/requires and try to install them. Eg. It does, in some cases. Which makes it even more fun. Take a system with /usr/bin/sdiff. ... Name: cow Summary: cow Version: 1.0 Release: 1 URL: http://redhat.com/ License: Moo Requires: /bin/sdiff ... root@nostromo x86_64]# rpm -ivh cow-1.0-1.x86_64.rpm --test error: Failed dependencies: /bin/sdiff is needed by cow-1.0-1.x86_64 [root@nostromo x86_64]# mv /bin /cow [root@nostromo x86_64]# /cow/ln /usr/bin -s /bin [root@nostromo x86_64]# /cow/rpm -ivh cow-1.0-1.x86_64.rpm --test Preparing...### [100%] IMO this is pretty crazy, because by changing the symlink back you've broken the prco constraints in the DB (but everything would verify as correct). It also seems like rpm is doing a _lot_ of work it doesn't need to do here, but who knows ... it looks pretty magic (and I'm scared to go find out why/how it's doing the above :). Cc'ing rpm maintainers for their opinion on what rpm is doing and why. Yum installs the package as well. Yeh, if it asks rpm if something is installed which satisfies that and is told yes, it will. However ... yum currently caches file requires/providers from rpm (among other things). So it's very possible that yum doesn't DTRT when it has cached data saying diffutils owns /usr/bin/sdiff and not /bin/sdiff (but it might, because it's a negative failure). In general I think only a huge amount of pain can come from relying on this (and you can't install into this situation, easily). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On Mon, 2012-01-30 at 15:47 -0500, Bill Nottingham wrote: Martin Langhoff (martin.langh...@gmail.com) said: On Fri, Jan 27, 2012 at 8:10 AM, Harald Hoyer har...@redhat.com wrote: Fedora 17 will locate the entire base operating system in /usr. The directories /bin, /sbin, /lib, /lib64 will only be symlinks: /bin → /usr/bin Interesting! Do we need to teach rpm / yum about the equivalence, when resolving dependencies? For a trivial example -- if package A depends on /bin/foo, will yum rpm be satisfied with /usr/bin/foo? Assuming /bin - /usr/bin link is packaged, yes. No, not in any meaningful way, although I assume all of the problems have been worked out in the testing done already. Yum just uses text matching. Yum doesn't even know if something is a symlink in the repodata, and I'd assume it would be a massive depsolving expense to resolve those even if we had that data. rpm _kind of_ knows about it, Eg.: % rpm -qf /etc/init.d/httpd httpd-0:2.2.21-1.fc15.x86_64 % rpm -qf /etc/rc.d/init.d/httpd httpd-0:2.2.21-1.fc15.x86_64 % repoquery -qf /etc/init.d/httpd % repoquery -qf /etc/rc.d/init.d/httpd httpd-0:2.2.17-10.fc15.1.x86_64 httpd-0:2.2.21-1.fc15.x86_64 ...but I assume rpm uses realpath() to cheat because if you create two packages where one provides /etc/rc.d/init.d/sym2 and the other requires /etc/init.d/sym2 ... rpm _doesn't_ let you install them, like yum. But you can add: Provides: /bin/foo ...to your packages, and you can pretend they are installed into /bin (keeping compat. with everything) ... at which point rpm/yum won't care that the /bin = /usr/bin symlink has actually moved where they are installed from build time (but note that Requires: /usr/bin/foo won't work, in the later case). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package categorization and distribution construction
On Thu, 2012-01-19 at 08:54 -0500, Bill Nottingham wrote: Peter Robinson (pbrobin...@gmail.com) said: Great idea, I would also love to see a clear out of the packages that aren't core/part of particular categories. MTAs in minimal would be one that comes to mind but there's lots of other examples. Yeah, I'd like to clean this up. The sad thing is that even if I define the minimal group as: kernel dracut util-linux systemd systemd-units initscripts yum selinux-policy-targeted policycoreutils it merely drops it from 524MB/186 packages to 503MB/152 packages. I could make it smaller by dropping yum/rpm and dependencies, but I can't in good conscience ship an *installation target* minimal install that doesn't allow you to get updates or add-in packages. A few interesting things: . The above is installed size, download size is only 101MB¹. . There are a lot of small deps. . The only two big packages that I see which _might_ be able to be trimmed (split into smaller ones, maybe) are python-libs and cracklib-dict. . glibc-common contains locale-archive which is 100MB installed (IIRC they mmap it, so code would need to be changed ... but a simple gzip takes that to 23MB which is like ~17% savings). . For all the gory details (on download size), upstream repoquery now support --qf on the tree output. Sample version (with above packages) at: http://james.fedorapeople.org/repoquery-deptree-size.txt . Doing install @core is actually smaller, and less packages than the above² 8. Which makes me assume something is missing from @core. ¹ rawhide: install above 8 packages Install 8 Packages (+134 Dependent packages) Total download size: 101 M Installed size: 445 M ² rawhide: install @core Install 41 Packages (+129 Dependent packages) Total download size: 72 M Installed size: 323 M Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to block grub2 update?
On Mon, 2011-10-24 at 18:56 +0200, Michał Piotrowski wrote: Hi, I would like to know if it is possible to block grub2 update? I tried to use versionlock but unfortunately this does not work. Do anyone knows some other effective way to block this update? versionlock doesn't stop obsoletes _by default_ (it's a speed vs. feature thing). You can turn that on via. follow_obsoletes=true (see man yum-versionlock.conf). -- 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: There's really nothing special about a package manager I assure you. Assuming, for a moment, that You; Seth and I are all equally experienced in package management and that while you would assure that, we would ... not. Given that, I'm curious if you know of any other people who agree with your assurance ... Panu? Florian? Jindrich? ... Adam (ajax)? Jeremy? Tim? ... any major contributor to anaconda? ... any major contributor to apt, dpkg or zypp? Any of the rPath guys? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yum S3 plugin
On Wed, 2011-09-14 at 21:48 -0700, Jorge Gallegos wrote: So, I gather no one can shed some light on this? anyone? bueller? The bug (point #2) doesn't really stop the plugin from working, but it is annoying. Any help would be much appreciated You'd probably have been better off mailing this to the yum devel ML and not fedora-devel. Anyway... - Fix an annoying bug where the plugin creates an empty yum cachedir in the current directory. This is because the way the plugin works, it creates a copy of the original repo with a different grabber based on boto/urllib2 and then copies the rest of the attributes. However when the [3]new repo is created, basecachedir is empty. Can any of you fine people spot a way around that? it's been bugging me for a good week now. This is due to the switch you are doing on the repo. objects ... using itermitems() seems like it's clever, to get all the data from the swapped out repo. ... but that's actually inherited from the config. object, so all you are setting are the config. options. The RHN plugin just manually sets .base_persistdir, IIRC, and that will probably fix it for you too. For your usecase I'd be very tempted to not do the swapout at all (as it requires a lot of testing/etc.) as all you really need is to override the grab object and set a couple of things. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RPM version goes backward in Rawhide
On Wed, 2011-07-27 at 09:19 -0700, Jesse Keating wrote: On 7/27/11 2:03 AM, Michael Schwendt wrote: In this case, the bad rpm-build broke koji builds, and since Rawhide may eat babies, it can happen that Rawhide users need downgrade manually while they have to wait for the fixed rpm-build. distro-sync also helps, and is a bit more generic. We are trying very hard to kill the notion that rawhide may eat babies. It's non-productive. Sisyphean task ... IMO. There are multiple ways to throw baby-eating updates over the wall for testing before they get into rawhide. Stop treating it like a dumping ground. But at some point you have to commit. You have to have a place all the updates go first, currently that's rawhide. It's been rawhide for ~20 years, it seems like a better idea for it to continue to be rawhide and just create a tanned repo. (or multiple ones) that eats less babies. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide openssh-server update kills sshd
On Tue, 2011-07-26 at 23:46 +0200, Lennart Poettering wrote: On Tue, 26.07.11 17:16, James Antill (ja...@fedoraproject.org) wrote: Perhaps it's because in %postun it has systemctl try-restart sshd.service where it used to have service sshd condrestart, and systemd kills all running sshd processes whereas the old one only killed the main one and not the children? It looks more like the first victim of systemd using cgroups as a replacement for setsid() etc. ... pam_systemd being the first return volley in that war. *sigh*. systemd is not using cgroups as replacement for setsid(). And then you go on to explain how pam_systemd is required so that it can do the setsid() like remove me from the session call ... and thus. not get hit with the kill() sent to the previous session. I'm not saying that cgroups doesn't do _other_ things as well ... but using it as a shiner setsid() is just doomed to a war where everyone puts cgroup calls where setsid() calls currently are. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide openssh-server update kills sshd
On Tue, 2011-07-26 at 21:28 +0100, Paul Howarth wrote: On Tue, 26 Jul 2011 16:13:59 -0400 Dave Jones da...@redhat.com wrote: On Tue, Jul 26, 2011 at 06:22:50PM +0200, Jim Meyering wrote: FYI, I've just yum-updated my rawhide VM to the latest (but not from the console) and was surprised to lose the connection while it was happening. Again. It happened to me last week, too. I got back in via the console and tried to reinstall it via yum reinstall openssh-server. That failed (sorry, didn't record the diagnostic). Just dug a little and found this was reported a week ago: http://bugzilla.redhat.com/722625 It bit me again yesterday, this time while in a screen session (I thought I'd learn from the earlier mistake). When I logged back in, somehow the screen session had vanished. This behaviour from sshd is pretty nasty. I don't recall it ever doing this before on updates, so why does it start doing it now ? arguably that bz should be reassigned to sshd, as that's the root cause for yum freaking out. Perhaps it's because in %postun it has systemctl try-restart sshd.service where it used to have service sshd condrestart, and systemd kills all running sshd processes whereas the old one only killed the main one and not the children? It looks more like the first victim of systemd using cgroups as a replacement for setsid() etc. ... pam_systemd being the first return volley in that war. *sigh*. -- 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 Wed, 2011-07-20 at 18:28 +0200, Miloslav Trmač wrote: On Wed, Jul 20, 2011 at 6:24 PM, Ric Wheeler rwhee...@redhat.com wrote: I normally build systems with (at least!) a separate /boot, / and /home. This lets me do a full install, blow away old fedora system partitions and not lose any user data. Since that puts down a pristine F16 image, does that mean we need to chown all of the user files that survive in a separate partition? Either chown the files, or create a kickstart file that puts /etc/login.defs in place in a %pre script. chown is probably much simpler unless you have many systems to manage. 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)? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PackageKit in Fedora 15 (beta)
On Tue, 2011-04-26 at 19:23 +0200, Kevin Kofler wrote: Florian Festi wrote: I think if anybody can come up with a exact description how they should look like and how they should work and can create some evidence that this is want we need and want implementing them is not the problem[*]. Until now no one has come up with a proposal and enough confidence. The proposal is this: Please read Florian's email again, and attempt to answer some/most of the questions (a rationale for your answers might be nice too). It should have been obvious to you that a proposal like this would have been discussed before. We would have 3 levels of dependencies: Requires: = always required Recommends: = required by default Suggests: = not required by default [...] The evidence that this is what we need: This is basically how all the existing implementations (deb, rpm5 etc.) I know of work and they've been found to work quite well for the distros using them. rpm5 isn't used anywhere, so is irrelevant to any discussion on anything. apt+aptitude+deb does use something like the above, with the very significant differences of: 1. Debian with deb+apt packaging is vastly different to Fedora rpm+yum packaging. 2. apt-get doesn't do anything, by default. 3. deb also has the two level reverse soft requires. 4. If you talk to random debian people nobody knows why they have two levels, what use it is over a single level (or, if it's really better, why not three) ... and which level is signified by recommends or suggests (or enhances/extends). Much like rpm/yum developers. 5. Even given #1, it's far from obvious that baking these assumptions into the packages themselves is a win. SuSE with rpm+zypper does have recommends/suggests, and is somewhat close to rpm+yum (kind of). But I don't know how much it is used ... and I don't know what it's behaviour is. I also don't know what problems they solve with it, and how well it solves them. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Yum-devel] [GSoC] Avahi repositories for yum
On Mon, 2011-03-21 at 01:48 +0800, Yin Qiu wrote: Hi, I'm Yin from China. As the subject line says, I'd like to apply for the summer project of adding automatic repo discovery for yum. I've personally contacted Roland McGrath, who is supposed to be the mentor for this project, and he told me to discuss this with the community. I don't have idea which mailing list is best suitable for this discussion, so I'm sorry for my cross-posting. I'll briefly talk about my understanding about the idea. In the spirit of dividing the project into separate pieces, I suggest the final deliverables include: Just as an FYI to everybody, this is the original idea as posted: http://fedoraproject.org/wiki/Summer_coding_ideas_for_2011#Avahi_yum_repositories ...this is notably different from previous POC avahi ideas, the idea of both was more that avahi could be used to share a sub-set of a repo. that had already been downloaded. The main RFEs seem to be: 1. Only required change on client is installing a plugin. 2. Plugin will use avahi to find mirrors for repos, and add those URLs to the mirrorlist. 3. Plugin will include proper NFS support, which means if the URL is nfs:/blah ... the plugin will make sure that NFS location is mounted somewhere, and then pass the file:/ URLs to yum. 4. Tool for servers to advertise that they have a mirror of repo. XYZ. 5. Get plugin installed for anaconda environment. 1) a script to help repositories that reside on nfs or http servers to advertise their presence. Does this mean we shall add a new service type, say _yum._tcp, to zeroconf? I don't think you can be that generic, with this proposal. As it's all about mirroring specific repos. So you need to be able to keep the avahi advertised mirrors for fedora and updates away from each other. The other problem is how you identify the repos. ... the obvious answer would be to use the Repo id's ... except that doesn't work for Anaconda, AIUI ... and isn't 100% for other usecases I bet Roland is thinking about. The way my attempt at avahi worked was to go super generic and have a CAS (http://en.wikipedia.org/wiki/Content-addressable_storage), and then whenever yum would want to download something it'd ask any of the avahi providers if they had it (over simple http/ftp/file/whatever). This solves all the repo. identification problems, because you don't care ... if they have the bits, you get them locally. Roland might even be happy(ier) here with some work on MirrorManager so that you can easily create private mirrors, using a command line tool (although that would remove yum and avahi, so is a very different proposal). 2) a plugin that, once enabled, automatically discovers published yum services and adds it to the pool. Kind of, you'd need to get two pieces of information: 1. What is the repo. 2. What is the mirror URL. ...and then lookup the repo. object given #1 and add the mirror URL #2 to it. 3) modification to anaconda to incorporate automatic yum repo detection. This should be the fairly simple case of getting the anaconda guys to include the plugin (assuming you can can make it work in the anaconda environment). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fail to install gcc on fresh rawhide-from-F15
On Tue, 2011-02-22 at 22:38 +0100, Jim Meyering wrote: Hi, With some effort, and help from the guys on #anaconda@freenode (thanks!), today I finally installed a bare-metal F15 system (part of the complication was my existing partitions). Then I updated it to rawhide. However, the whole point of this was to be able to compile and test some things, yet I cannot install gcc: # yum install gcc [...] Error: Package: glibc-2.8.90-11.i686 (rawhide) Requires: glibc-common = 2.8.90-11 Installed: glibc-common-2.13.90-4.x86_64 (@updates-testing/15) glibc-common = 2.13.90-4 Available: glibc-common-2.8.90-11.x86_64 (rawhide) glibc-common = 2.8.90-11 Newer glibc in F15 than in rawhide, so yum won't go backwards for glibc-devel ... it tries to go with the .i686 instead (do you not have protected_multilib set?), but that doesn't work out either. distro-sync glibc* on rawhide ... or get glibc-devel from F-15. Error: Package: gcc-4.3.1-6.x86_64 (rawhide) Requires: cpp = 4.3.1-6 Installed: cpp-4.6.0-0.7.fc15.x86_64 (@rawhide) cpp = 4.6.0-0.7.fc15 Available: cpp-4.3.1-6.x86_64 (rawhide) cpp = 4.3.1-6 Dito. cpp. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mass rebuild status
On Tue, 2011-02-08 at 20:49 -0700, Kevin Fenzi wrote: On Tue, 8 Feb 2011 20:00:44 -0500 Josh Boyer jwbo...@gmail.com wrote: I believe this wiki page should have been included in the announce mail: https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild For those that don't particularly follow devel day-to-day, the blurb about the XZ change is pretty uninformative. I've tried to dig back a bit and it seems the XZ change is to pick up XZ 5.0. It seems the rebuild was done to fix Delta RPM generation? From a package standpoint, will that mean that F14 is incapable of reading F15 RPMs? Does that impact mock? The only case it hits is deltas. If you have a package that was built in f14, and then a update happens in f15, the delta wouldn't work right. (At least this is my understanding). mock shouldn't be affected, nor should f14/f15 rpm read interop. I'd be happy to flesh out the change a bit more in detail if someone could point me at what is really changing in terms of XZ compression and what it means going forward. Better late than never. Yeah, I wish I could find a good cite... Perhaps the deltarpm and/or xz maintainers could chime in with the exact info. This is the first hit for xz compression deltarpm problem and describes the problem perfectly ... although it is from 2009 ;) http://cedarandthistle.wordpress.com/2009/12/29/deltarpm-problems-part-ii/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: @core in F14 pulls in libX11
On Fri, 2011-01-21 at 22:54 -0800, Garrett Holmstrom wrote: It seems that the core yum group pulls in X11 libraries, at the very least on x86_64, via the following dependency chain: policycoreutils dbus-glib gobject-introspection cairo libX11 It's probably worth noting that the yum command line allows you to do things like: yum --installroot=... -- install @core -cairo ...so if you need a minimal root for --installroot or mock etc. ... then you don't have to go straight to hardcoding everything. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Help to solve a possible circular Requires:
On Fri, 2010-12-03 at 10:24 +0100, Fabio M. Di Nitto wrote: Hi all, I am seeking some help here to solve a possible $subject. I have been trying to find a simple alternate solution, but I just can´t see it or it´s not obvious to me. This is the situation: srpm foo 1.0 ships 2 rpm´s bar and baz. bar has a daemon inside. due to upstream split: srpm foo 1.1 now ships only bar rpm without the daemon. srpm baz 1.1 now ships 2 rpm´s, baz (exactly as in version 1.0) and baz-something that contains the bar´s daemon from 1.0. In order to avoid upgrade issues, we need to make sure that bar 1.1 will pull in baz-something 1.1 (to retain functionality), at the same time baz-something requires bar 1.1 to operate at all. There is no requirement for a strictly versioned Requires: on both sides. baz-something Requires: bar = 1.1, and bar Requires: baz-something (no version need since it´s a new rpm). The above reads more complicated than I think it is. I assume you have two problems: 1. When moving from foo-1.0 = foo-1.1 and baz-1.1, you have a package split ... this implies using versioned Obsoletes (= 1.0) on bar from baz-something. 2. In baz-something-1.1 you have a normal requires on bar-1.1 ... so just add a versioned (= 1.1) require. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
On Tue, 2010-11-23 at 10:19 -0600, Bruno Wolff III wrote: On Tue, Nov 23, 2010 at 17:18:44 +0100, Michał Piotrowski mkkp...@gmail.com wrote: W dniu 21 listopada 2010 12:13 użytkownik Michał Piotrowski mkkp...@gmail.com napisał: We can create a list of all scripts in wiki and maintainers of individual packages would indicate that they want to convert scripts themselves. How can I get information about all packages that provides init scripts? When I do rpm -qf /etc/init.d/* I get only information about already installed packages. Any magic switch to get informations about all packages from rpm database? I believe rpm only knows about packages available locally. You either need to have the packages installed or a local mirror. (You can use urls to refer to remote packages with rpm, but that isn't likely to be workable.) If you have a local mirror you can use the p option and name the rpms. Otherwise yum is probably a better choice for this, since it can use meta data to get information. One of the yum utilities may be better than yum itself, but I am not sure offhand. You can use: repoquery -qf '/etc/init.d/*' '/etc/rc.d/init.d/*' ...note that unlike rpm -qf you need both of the above paths. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On Wed, 2010-11-24 at 13:39 -0800, Toshio Kuratomi wrote: On Wed, Nov 24, 2010 at 03:58:26PM +0100, Lennart Poettering wrote: On Wed, 24.11.10 03:02, Toshio Kuratomi (a.bad...@gmail.com) wrote: A question I'd have when looking over a proposed packaging guideline would be: why %ghost the directories? Why not include the directories as normal but add the tmpfiles.d step in addition? Well, because rpm has introduced %ghost for cases like this, and everybody else uses it for that. %ghost is definitely suitable for files but I'm not so sure it's suitable for directories. It certainly leads to more complex spec files to use %ghost on the directory for really no gain that I'm aware of. %ghost does %two things with a file: It tells rpm that it doesn't need to install the file. It tells rpm to not track the contents of the file while still tracking the permissions and ownerhsip of the file. It's also worth noting that %ghost tells rpm -V that it's ok if the file/dir. is missing (or changes type) ... which we _don't_ want to happen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RPM: signing uncompressed data instead of signed data?
On Thu, 2010-11-11 at 10:41 +, Andre Robatino wrote: I came across the following old post, which I'm not responding to in-thread due to its age. https://www.redhat.com/archives/fedora-devel-list/2009-September/msg00517.html The question was raised why RPMs sign their compressed data, rather than uncompressed. (One advantage would be to avoid deltarpm rebuild failures due to changes in compression such as the recent one in xz.) That's not true, there are four checks for delta rpms: 1. yum-presto runs checksums on the installed rpm, and the downloaded deltarpm. If these pass it then creates a new .rpm from those two sources. 2. Yum then checks that any rpm it has on disk matches the checksum it has from the repodata. 3. Yum then asks rpm to check the gpg signature of the new rpm. 4. Yum then looks at the SHA1HEADER for the rpm (which, again, is over the compressed contents). ...now it's possible that #3 will change within the next year or so, but it is much more likely to end up simpler than more complicated (Eg. detached signature of the entire file). IMO, as has been said before, if you have a delta method that doesn't produce the exact same bits at the end ... you've probably failed. It might seem like a good idea, but even if you go to the extreme lengths needed to make it just for yum ... things like reposync won't be able to use it, Eg. http://james.fedorapeople.org/python/delta-rpm-dir.py -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/whatsnew/3.2.29 http://yum.baseurl.org/wiki/YumBenchmarks http://yum.baseurl.org/wiki/YumHistory -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RPM: signing uncompressed data instead of signed data?
On Thu, 2010-11-11 at 10:17 -0500, Andre Robatino wrote: James Antill wrote: IMO, as has been said before, if you have a delta method that doesn't produce the exact same bits at the end ... you've probably failed. It might seem like a good idea, but even if you go to the extreme lengths needed to make it just for yum ... things like reposync won't be able to use it, Eg. http://james.fedorapeople.org/python/delta-rpm-dir.py I realize there's a lot of stuff sitting on top of RPM that depends on how it works currently Maybe I wasn't clear ... the above code doesn't depend on rpm it depends on the bits being identical, as it's used to speed up mirroring Fedora (so the bits have to be identical for the mirror users). , but in terms of correctness, it still seems to me to make more sense to sign the uncompressed data, since that's what actually gets used used is a loaded word here, as others have said from the point of view of different parts of yum/rpm it's the downloaded bits that are used and the uncompressed bits that are output. , and it would avoid issues like https://fedorahosted.org/rel-eng/ticket/4224 which will have to be dealt with periodically as long as compression continues to improve. So let me rephrase the question: in an alternate universe where RPM was originally designed to sign the uncompressed data, and the higher-level tools were subsequently designed to work with that, is there any fundamental reason why things would be worse (or better) than they are now? So assuming we could magically change everything, what would we need to do stop any differences in compression from causing problems? In theory we could publish everything as uncompressed ... and then use http content-encoding to add xz/etc. compression back. But that'd break everything that's non-http ... and any http clients that don't do content-encoding (and AFAIK no client/server currently supports xz in content-encoding). The other option is for someone to add compat. code into xz, so we can say things like compress how you would have with version x.y.z. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Polyinstantiated /tmp
On Sun, 2010-10-31 at 15:07 -0400, Matt McCutchen wrote: On Wed, 2010-10-20 at 08:13 -0400, Daniel J Walsh wrote: I have been trying to get system processes to stop using /tmp for years. http://danwalsh.livejournal.com/11467.html As some one who lives with polyinstatiated namespace /tmp, The only problem I know of now is handing of kerberos tickets. Whenever a system process (root) needs to communicate with a user via /tmp. namespace /tmp breaks it. sssd can not create kerberos tickets in my /tmp and gssd can not find my kerberos tickets in /tmp. I believe the solution to both is to move the tickets to be managed by sssd and leave /tmp to users. BTW, X has solved this problem a couple of years ago by using virtual namespace for its sockets. In the abstract namespace, don't you have the same problem where if the real X server dies for any reason, other users can create a socket at the same path and mess with your applications? There are multiple problems ... the one that using the abstract socket namespace solves is that you can have a per. user /tmp and still communicate between users. Much like if you have a per. user /tmp but /tmp/global was shared among all users, and kerberos/X/whatever all used that (IMNSHO much better than using the abstract namespace ... but meh). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!
On Fri, 2010-10-29 at 12:18 +0100, Daniel P. Berrange wrote: On Fri, Oct 29, 2010 at 02:32:52PM +0530, Rahul Sundaram wrote: On Fri, Oct 29, 2010 at 2:26 PM, Daniel P. Berrange wrote: You want the libcap-ng-utils RPMs which provides a bunch of useful tools for this, filecap, netcap, pscap, etc. Is there any particular reason, the regular tools that users already use cannot be modified to display the appropriate info, like SELinux and -Z argument. In theory there's nothing preventing this. Deciding on/defining a concise display of capabilities info that doesn't mess up the formatting of ps/ls/etc I don't think you need to display them, just display something that says this is more than it seems ... like ACLs. Something as simple as -rwcr-xr-x. instead of -rwsr-xr-x. for setuid. -- 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: 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? So first off, I personally don't care if /usr is allowed to be separate or not (though breaking the FHS on a whim seems a tad excessive) ... but I don't see how /var is significantly different. udisks (why I'm reading this thread at all) certainly looks like it needs /var to be mounted. 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? Also, are we sure that people don't want to change any options other than ro (the only thing you can tweak with the bind trick, AIUI)? I thought someone mentioned noatime... -- James Antill - ja...@fedoraproject.org ... so the consumable rawhide is likely not to get as many updates as its users would like to have. -- Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On Tue, 2010-10-12 at 16:00 +0100, Bastien Nocera wrote: On Mon, 2010-10-11 at 11:11 -0400, Chris Lumens wrote: - suggests a username and hostname based on the user's real name (Mac OS X's installer also does this -- it's a nice touch) If DNS knows a hostname, we will suggest that. Of course it's not foolproof. That's not it. Your name is entered (Chris Lumens) and from it you should get a hostname (chris-lumens-fedora-desktop.local) as well as a presentation name (Chris Lumens' Fedora Desktop) which could be used for things like services being advertised through avahi, or even the default name for the Bluetooth adapters. The Mac does this too, and I'm sure it's great for avahi stuff ... but it's really annoying for anyone using the hostname anywhere else (mainly due to the expected size). Is there nowhere else that we could store a hostsummary instead of hostname? -- 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 22:45 +0100, 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.) yum install yum-security ...then: yum updateinfo ... ...there is also a changelog plugin/command, if you want that too. But the updateinfo usually is good enough (and IMNSHO, you should log bugs if it isn't :). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo?
On Thu, 2010-09-23 at 01:29 +0200, Björn Persson wrote: Michał Piotrowski wrote: 2010/9/21 Björn Persson bj...@xn--rombobjrn-67a.se: How hard would it be to cherry-pick from this backports repository? To install a newer Firefox from there for example, but keep the PostgreSQL from the ordinary Fedora even if there is a newer one in the backports repository, and with a simple yum update receive bugfixes to PostgreSQL from fedora-updates and new Firefox versions from the backports repository? If the backports repository would be an all or nothing thing, or if cherry-picking would require special tweaking of Yum, then it's a bad idea. yum-plugin-priorities? The first thing I notice is that that plugin comes with exactly zero documentation. A wiki page from CentOS and two posts on some random blogs give some configuration examples and also warn about dangers that only a Yum hacker will fully understand. Neither explains how to install selected packages from a lower-prioritized repository, but my crystal ball indicates that it would be troublesome compared to normal Yum usage. Apparently all repositories have the lowest possible priority by default, so users would have to edit every single .repo file by hand to give them higher priorities than the backports repository. In other words, yes, special tweaking of Yum would be required. There's: http://yum.baseurl.org/gitweb?p=yum-utils.git;a=blob_plain;f=plugins/priorities/README;hb=90ea69cc7589160735fc67f341db210403bc7f6f ...but generally I don't recommend using priorities, as it's a big hammer to solve a problem that shouldn't exist: http://yum.baseurl.org/wiki/ConflictingRepos ...or to put it another way, putting a new firefox and PostgreSQL in the same repo. is a really bad idea. Another solution would be to simply have separate repositories – stored on the same server and maintained by the same people, but with separately packaged .repo files. If I can't wait to have the very latest Openoffice, I install the fedora-backports-openoffice package which contains /etc/yum.repos.d/fedora- backports-openoffice.repo, and then a simple yum update will upgrade all the Openoffice packages. If I don't want sudden changes to PostgreSQL, then I refrain from installing fedora-backports-postgresql. Mission accomplished. That's basically what we have now with repos.fedorapeople.org ... the next thing from there is if we could trust those packages the same as the ones from Fedora itself (and maybe get some mirroring). But that will require a lot more resources. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Fri, 2010-09-17 at 18:37 +0100, Richard Hughes wrote: On 17 September 2010 16:39, FlorianFesti ffe...@redhat.com wrote: open the payload and unpack the content of the desktop files... I got told by infrastructure this would take too much bandwidth and too much time to do on each compose. It takes too much bandwidth and too much time to create the checksums for all the packages in rawhide on each compose, if you do it the simple way and just open+read every package. This is what you may have been told, the person you were speaking to probably assumed they didn't have to tell you that this just meant: You can still do it, just don't do it the simple way. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Thu, 2010-09-16 at 10:57 +0200, drago01 wrote: On Mon, Sep 13, 2010 at 11:39 PM, Richard Hughes hughsi...@gmail.com wrote: On 13 September 2010 21:49, James Antill ja...@fedoraproject.org wrote: So Seth spent half a day implementing a proof of concept: http://skvidal.wordpress.com/2010/08/19/fedora-app-market-proof-of-concept/ Translations? Icons? Offline queries? Co-operating with other distros? Lets say we ever want to implement this https://bugzilla.gnome.org/show_bug.cgi?id=612628 (or any similar feature in another upstream project) without a cross distro way to get the application data (icons, names, etc. ) it would be a maintenance nightmare. Err ... PackageKit is currently the cross distro. way to work with distro. package managers, nothing outside of that layer should ever know (or care) where the data is coming from and how it gets updated etc. For package data now, PackageKit looks in primary-*.sqlite.bz2 in Fedora and Packages.bz2 in debian. gnome-shell/whatever doesn't know or care. This should be no different. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Thu, 2010-09-16 at 16:57 +0100, Richard Hughes wrote: On 16 September 2010 15:01, James Antill ja...@fedoraproject.org wrote: Err ... PackageKit is currently the cross distro. way to work with distro. package managers, nothing outside of that layer should ever know (or care) where the data is coming from and how it gets updated etc. PackageKit is a _package_ abstraction framework. Yum is a _package_ manager. Applications like gnome-shell and kpackagekit want to search for new applications using translated per-application strings and show icons for desktop files. Sure, in the same way they might want to display data from updateinfo and/or the patches thing OpenSuSE uses. Or they might want to access package history, to see what changed. etc. etc. PK is the current interface between the questions gnome-shell/etc. want to ask, and the answers the package managers can give. This kind of abstraction means Fedora doesn't need to run dpkg, or ship Package.bz2, or ship repodata in fail-whale.rpm. I did kind of assume most people on this list knew that, but we can repeat it again (and again, and again) if you want. There has to be a layer above the package manager that deals with applications. We've covered that, it's currently called PK. There has to be a cross-distro way to deal with the package:application mapping. It just so happens that app-install does just that. So put it in repodata, and put the APIs in PK to make sure a package is there on Ubuntu (when/if they actually use it) and make sure the repodata is current in Fedora (and, I'd assume, at least OpenSuSE). This is not difficult, nobody has demanded you rewrite PK in erlang or solve faster than light travel ... just put the repodata in the repodata, like all the other repodata. And please stop doing the equivalent of saying we have to install pacman in Fedora, to be compatible with Ubuntu. It's getting tiring. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Wed, 2010-09-15 at 16:38 +0200, FlorianFesti wrote: So I would suggest an UI that gives a summery (Didn't we already have that in the past?) and offers 3 buttons: [Show/Hide Details] [Do not install updates now] [Install updates now] The first being a toggle button hiding/showing the current or to be list of updates or to be updated applications. FWIW the Mac OS X update dialog looks almost exactly like this, and shows running applications you should close before running the update. Btw. sorting the updates by severity and offer a check box by severity (may be using a tree view instead of a list) may be another improvement. I've asked for this feature before too, it's actually already there but hidden in the right click menu (at least for doing security only updates). Of course it's currently broken due to the fact I have: % sudo yum updateinfo Loaded plugins: aliases, keys, noop, presto, ps, security Updates Information Summary: available 4 Security notice(s) 105 Bugfix notice(s) 23 Enhancement notice(s) ...but PK refuses to do anything but update it's own 6 packages for a minor specfile change. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Mon, 2010-09-13 at 22:39 +0100, Richard Hughes wrote: On 13 September 2010 21:49, James Antill ja...@fedoraproject.org wrote: So Seth spent half a day implementing a proof of concept: http://skvidal.wordpress.com/2010/08/19/fedora-app-market-proof-of-concept/ Translations? They were part of the half day hack PoC, but yes to expand your answer in a nice way: If/when you propose this for inclusion as repodata, will you be adding a bunch of information that wasn't in the half-day PoC ...and the answer is: Yes, there's lots of interesting data that could be added. Offline queries? What about offline queries? I assume you know you can do them just fine with yum on the current repodata, and I assume you haven't worked out a way to magically install your repodata in a package packages when it isn't installed and there is no network/CD. So, again, what are you trying to say? Co-operating with other distros? For the half-day PoC, really? But even then, Seth co-operated with Fedora rel-eng's desire that repo-metadata actually be repo-metadata. Which is the only thing anyone said is a must fix for Fedora. It's hard to see what other distros. have required as must fix with app-install, given that none are using it. Call me biased, but doing things in yum because it's the way it always used to be carries little weight when the user experience just sucks really hard. Ok, you're biased. As you've been told numerous times, putting repodata in packages is a terrible idea due to a bunch of known problems, including: 1. How do you keep it in sync. with the repo? 2. How do you deal with the reality of multiple repos? 3. How do you deal with disabling repos? Temporarily? 4. How does anadonda see it? ...this is why repodata is repodata, and we don't just ship fedora-primary.rpm etc. This is not specific to yum, and would still be the case if you finish Zif and Fedora moves to it (or apt/zypper/whatever) instead. I've been working on app-install now with other distro people for nearly two years. I'm not sure I'd be rushing to tell everyone that a half-day PoC was better than my 2 years of work, but each to his own. And, again, it begs the question ... why is no other distro. using it? But then maybe you didn't mean all those two years were spent doing something which is fundamentally impossible to put in repodata, which is the only required change I've seen from anyone in Fedora ($DEITY help us with any of the other things we just wanted). Sometimes I wonder why I should deal with Fedora and all the politics when Ubuntu and Suse just ship something that works. Ubuntu recently got high praise from LWN for Software Center in 10.10 betas. It doesn't use PackageKit at all AFAICS (no PackageKit packages are installed in my VM). It integrates tightly with apt (you know, like showing package history ... like yumex does). Also their package install/remove tool is not gpk-application, and their update tool is not gpk-update-viewer. So I'm having a hard time working out what you mean. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Mon, 2010-09-13 at 09:36 +0200, Hans de Goede wrote: Hi, On 09/08/2010 02:43 PM, Richard Hughes wrote: On 8 September 2010 13:16, Adam Williamsonawill...@redhat.com wrote: First off, I think this is a great idea and very much needed, thanks for working on it. Cool, thanks. Some positive feedback at last! Too... much... stop... energy... Oh, But Adam is not the only one I love this idea too! And I would like to think there are other silent admirers of this idea too! There are a lot of non-silent admirers of this idea too! I love this idea! All the yum developers and rel-eng love this idea! I've yet to speak to anyone who doesn't love this idea! In fact this thread probably started because yum/rpm/etc. developers had recently talked about app. install again, so Seth spent half a day implementing a proof of concept: http://skvidal.wordpress.com/2010/08/19/fedora-app-market-proof-of-concept/ To repeat _nobody_, that I know of, is arguing that we shouldn't do something. The problem is in rushing from there to XYZ is something. We should do XYZ. -- James Antill - ja...@fedoraproject.org I'd just like to see a realistic approach to updates via packages. -- Les Mikesell -- 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 skvi...@fedoraproject.org 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. This would be a more compelling argument if PK was significantly better than pirut/yumex/etc. But version 2, which is in progress now, features application screenshot previews (that ubuntu wanted) and application ratings (which we all wanted). Having an extensible format allows us to add the features in a cross-distro way without re-inventing schemas and UI. Are you having any discussions about applications like postfix, or is version 2 going to be just GUI stuff? I assume you have a plan for making this repodata, but I couldn't find it, is there a URL? -- 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 15:42 +0100, Richard Hughes wrote: On 7 September 2010 15:23, James Antill ja...@fedoraproject.org wrote: Are you having any discussions about applications like postfix, or is version 2 going to be just GUI stuff? Postfix is not an application. Applications have translated desktop files and icons. This is your definition of application, and IMNSHO not a good one. You are proposing infrastructure changes so that when a user says they want to install spreadsheet then we can go from presenting the user with 13 answers (current yum search result) to presenting them with 4 (maybe 5). This is great, and will be a big help, as I think we can all agree that it's much less likely the user will want perl-Spreadsheet-ParseExcel etc. However this is very much the same problem as a user trying to find sql server and getting results like voms-mysql-plugin etc. If you intentionally ignore this problem, it just means even more work in the long term as we have to change the metadata and any/all tools to cope. You might well argue that gnome-PK's target users shouldn't see postgresql-server in any results (or anything without a desktop file). And that's _fine_, I'm not trying to tell you how to write gnome-PK. I'm just trying to make sure we don't have to do major revisions to any application metadata we produce (or worse, multiple different bits of metadata). I assume you have a plan for making this repodata, but I couldn't find it, is there a URL? This isn't repodata, it's a separate data package. You've already proposed BZ 488968, it's already been commented on. I can't believe you are just saying I don't care what anyone else thinks, I'm going to do what I feel like ... so maybe I'm parsing your response incorrectly. -- 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 16:54 +0100, Richard Hughes wrote: On 7 September 2010 16:39, James Antill ja...@fedoraproject.org wrote: However this is very much the same problem as a user trying to find sql server and getting results like voms-mysql-plugin etc. If you intentionally ignore this problem, it just means even more work in the long term as we have to change the metadata and any/all tools to cope. Users don't install SQL servers[1]. Please read the paragraph I wrote that started: You might well argue that gnome-PK's target users shouldn't see postgresql-server in any results ...if we _both_ read what the other has written, it will make discussion much easier. [1] My definition of users are 3 actual people: http://packagekit.org/pk-profiles.html -- 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 11:48 -0400, Arthur Pemberton wrote: On Tue, Sep 7, 2010 at 11:39 AM, James Antill ja...@fedoraproject.org wrote: On Tue, 2010-09-07 at 15:42 +0100, Richard Hughes wrote: On 7 September 2010 15:23, James Antill ja...@fedoraproject.org wrote: Are you having any discussions about applications like postfix, or is version 2 going to be just GUI stuff? Postfix is not an application. Applications have translated desktop files and icons. This is your definition of application, and IMNSHO not a good one. This is goes along with the only definition of application that I am aware of. Postifx is a system service. http://en.wikipedia.org/wiki/Application_software Application software, also known as an application, is computer software designed to help the user to perform singular or multiple related specific tasks. ...which matches exctly, IMO. But if it's confusing I don't mind referring to this as otherword installing, if you have a less confusing word … I'd just rather not say desktop-application+services +dbus-services+cron-services+etc. installing each time. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Koji crashes Chromium [was Rawhide Koji borked??]
On Tue, 2010-09-07 at 17:41 -0700, J. Randall Owens wrote: On 09/07/2010 05:33 PM, Genes MailLists wrote: Problem with yum - I cannot seem to find the equivalent of the --test rpm option ? Well you can do: yum blah --setopt=tsflags=test ...which is exactly --test, including running the rpm transaction (in test mode). IIRC some versions of yum don't appreciate running test rpm transactions. The best equivalent to --test I've noticed is to just run the yum command normally, then reply 'n' if/when you get the Is this ok [y/N]: prompt. It doesn't lend itself to non-interactive use, of course. This just runs the yum side, including the depsolver, and I often use it non-interactively with: echo | yum install blah -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
On Wed, 2010-07-21 at 11:19 +0200, Hans Ulrich Niedermann wrote: Ugly potential fix for this ugly issue: Patch rpm and yum to compare N-V-R.fc13 exactly like N-V-R.f13, and carry that patch until F-15. That would be ... hard. And ugly doesn't even begin to describe it. Also IMO using only a single letter for the dist seems overly space optimizing ... if you just want to remove all references to Fedora Core, propose it changes to fed14 or even just rename what the c stands for (like the GCC rename). -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/whatsnew/3.2.28 http://yum.baseurl.org/wiki/YumBenchmarks http://yum.baseurl.org/wiki/YumHistory -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
On Wed, 2010-07-21 at 16:39 +0200, Michal Hlavinka wrote: another less ugly (but still ugly) solution would be adding: Obsoletes: N-V-R.fc13 Obsoletes: N-V-R.fc12 in koji automatically for the same NVR as the package has, but I don't know if this would not make yum's depsolver cry Even assuming we could make sure that does the correct thing (it probably would but I know it's not tested :), adding 40,000 obsoletes to the repo. is ... let's say: unlikely to make yum faster. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/whatsnew/3.2.28 http://yum.baseurl.org/wiki/YumBenchmarks http://yum.baseurl.org/wiki/YumHistory -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Wed, 2010-07-21 at 17:16 +0200, drago01 wrote: On Wed, Jul 21, 2010 at 3:14 PM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Jóhann B. Guðmundsson johan...@gmail.com said: And as the general rule goes native configuration breaks legacy configuration so if a native systemd $service file does exist than changing service via chkconfig no longer will work. As an admin, this is crap. Where does this general rule come from? As strong desire to piss off the people that actually use your software? So different == crap ? If it does provide a hard to use interface I'd understand the frustration but only because it is NEW / DIFFERENT does not mean that the world is falling over. In general, yes, it does (just not to you): http://skvidal.wordpress.com/2008/10/29/fedora-culture-clashes/ ...however this case (breaking service/chkconfig) seems like such a huge pointless difference that I can't imagine RHEL-7 not requiring that it's fixed. So the only real question is how long Fedora users have to live with it broken. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Wed, 2010-07-14 at 10:58 -0400, Bill Nottingham wrote: Lennart Poettering (mzerq...@0pointer.de) said: Since the acceptance by FESCO it has been added to Rawhide together with patched or updated versions of a few related packages. However, what has not been done so far is making it the default in Rawhide. So far it does not Obsolete Upstart yet, just Conflicts with it. With this mail I want to notify everybody that I am planning to do this change very soon now (tomorrow?). Then, systemd will be pulled in onto your rawhide system and is used exclusively for booting (so far, you can still choose between it and upstart in grub, with a default on upstart), and problems booting should be reported to systemd in rhbz then. This seems a little backwards. If we want to support both, then we need to just leave it as 'Conflicts', and we'll just flip the default in comps. By marking it as 'Obsoletes', you effectively make it impossible to still boot with upstart, as it will be removed in any yum update. But then nobody will have systemd by default, it'll requiring using yum shell to manually move to it and thus. it'll get very little testing. I'd suggest one of two things: 1. Have systemd Obsolete: upstart = 0.6.5-5.fc14, and then bump the release on upstart. This means people doing yum update will move to systemd, but people will have a choice by upgrading upstart. 2. Have systemd Obsolete: upstart = 0.6.5-5.fc13, this means anyone moving to rawhide _after_ will get systemd and anyone on rawhide can also do downgrade upstart and then install systemd. ...#1 seems better, assuming we want most people to be testing systemd. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Wed, 2010-07-14 at 13:01 -0400, Bill Nottingham wrote: Lennart Poettering (mzerq...@0pointer.de) said: Well, I don't think we want to support both. I believe F14 should be systemd and only systemd, but we want the option to revert to upstart should that not work out. I am very much interested to get upgraded systems to use systemd as well, which is why I'd really like to go the Obsoletes way, and use a versioned Obsoletes, so that we can switch back to upstart if we want to by another versioned Obsoletes, but this time from upstart. (which is exactly what James Antill proposed in his mail) Or in other words: I'd like to make this switch for the whole distro, not leave it to the individual machines. So, unless there is really strong opposition to the Obsoletes approach I'd go on and do the switch? If we're at the... 95% coverage case, I guess. What I don't want is that machines suddenly stop booting with no recourse other than init=/bin/bash and manual recovery. There are some side cases that would be nice to either have working, or documenting that they're not done yet (serial consoles, assorted other things.) I suspect the biggest issue here is confined daemons, as they may not have permissions to create their own directories in /var/run or /var/lock once they've been started. Unfortunately, it's the sort of flag day that we really can't do unless everything in our tree is fixed. Well, a temporary and kind of ugly fix could be to add lines like the following into the systemd service files for these services. ExecStartPre=-/bin/mkdir -p -Z foo_t /var/run/foo Or something like that. And for service which continue to use SysV scripts something similar is easily thinkable in the init scripts. Hardcoding foo_t is bad if they ever switch policy (MLS, etc.). But it is an option. I'm not sure if this is good systemd syntax, but for mkdir you'd want something like: ExecStartPre=-/bin/mkdir -p -Z $(matchpathcon -n /var/run/foo) /var/run/foo ...but I think install does the right thing, so if we know /usr exists it could be: ExecStartPre=-/usr/bin/install /var/run/foo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Wed, 2010-07-14 at 21:08 +0200, Lennart Poettering wrote: On Wed, 14.07.10 14:24, Jeff Garzik (jgar...@pobox.com) wrote: /etc/systemd/system. You could do this: /etc/systemd/system/default.target → /lib/systemd/system/multi-user.target to avoid the graphical UI, and boot into the text console only (i.e. much like the old runlevel 3) Or you could do this: /etc/systemd/system/default.target → /lib/systemd/system/graphical.target to boot into the graphical stuff by default. This is the default as we package it. Or you could just parse inittab and notice when runlevel 3 was listed. Keeps everything nice and compatible, including existing manuals and books, and sysadmin knowledge. Is this really such a biggie? I mean Upstart ignores inittab too, the only option it still takes into account is this default runlevel and that only via some shell hackery. We go one step further and also ignore that one line. That one line is quite important though. I'm also not sure what you gain by not parsing it. Just have: /lib/systemd/system/1.target = single-user.target /lib/systemd/system/3.target = multi-user.target /lib/systemd/system/5.target = graphical.target ...and use the target specified by that one line. At some point much later we can then change the inittag to runlevel default, and it'll work as it does now. Let's keep things simple, do the clean cut, document that in the file itself and point people to the right and modern approach. I think you mean being fully back compat. with all of inittab is not simple, but I doubt Jeff was asking for that (given that, as you say, upstart is in RHEL-6 and doesn't). But adding a few lines of C code to parse the default runlevel out of inittab seems pretty simple and would bring with it a lot of backwards compat. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Wed, 2010-07-14 at 22:38 +0200, Lennart Poettering wrote: On Wed, 14.07.10 16:03, James Antill (ja...@fedoraproject.org) wrote: Or you could just parse inittab and notice when runlevel 3 was listed. Keeps everything nice and compatible, including existing manuals and books, and sysadmin knowledge. Is this really such a biggie? I mean Upstart ignores inittab too, the only option it still takes into account is this default runlevel and that only via some shell hackery. We go one step further and also ignore that one line. That one line is quite important though. I'm also not sure what you gain by not parsing it. Well, the way things are designed is that we read compat configuration only if no native configuration for this particular item exists. Example: we read /etc/init.d/avahi-daemon if /lib/systemd/system/avahi-daemon.service does not exist. This is followed everywhere else too. Sure, and for service configuration that seems fine. Now, if we translate the same logic to inittab we'd have to check /etc/systemd/systemd/default.target first, and if that doesn't exist fallback to /etc/inittab. But your runlevel is not a service configuration, so I see no reason why you couldn't say if there is an 'id:blah:' line in inittab that's authoritative if not, use default. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Wed, 2010-07-14 at 23:19 +0200, Lennart Poettering wrote: On Wed, 14.07.10 17:01, James Antill (ja...@fedoraproject.org) wrote: But your runlevel is not a service configuration, so I see no reason why you couldn't say if there is an 'id:blah:' line in inittab that's authoritative if not, use default. Well, I want people to use the new thing and have the new logic auhtoritative. I don't want to keep the old cruft around forever. Sure, but this is not a case of you having to decide between do the old thing forever or break it now. Do it as: 1. Leave /etc/inittab functionally as it is in Fed-13, with 3 and 5 doing the obvious thing and the big comment saying stuff about systemd instead of upstart. If people want to opt. in to the new way they can just cp /dev/empty /etc/inittab. 2. For F-15 or F-16 change inittab to be: id:default:initdefault: ...and have anaconda write that out and configure using a symlink instead. Users can still change it to 3 or 5, or whatever ... but if they don't it'll work as though inittab doesn't exist (the new way). 3. At some point you remove support for parsing inittab, so people have to configure using symlinks ... some people will still not like you removing free compat. code, but assuming you wait a few years at least everything will support the new way. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dist-git testers wanted!
On Tue, 2010-07-13 at 13:48 +0200, Léon Keijser wrote: On Tue, 2010-07-13 at 13:34 +0200, Laurent Rineau wrote: So grab fedora-packager-0.4.2.3 (may have to enable updates-testing) For the moment, Yum on Fedora 13 says: Error: Package: fedora-packager-0.4.2.3-1.fc13.noarch (updates-testing) Requires: GitPython = 0.2.0 Installed: GitPython-0.1.6-2.fc13.noarch (@anaconda-InstallationRepo-201005130101.x86_64) rpm -Uhv http://kojipkgs.fedoraproject.org/packages/GitPython/0.2.0/0.1.beta1.fc13/noarch/GitPython-0.2.0-0.1.beta1.fc13.noarch.rpm fixes this :) Or: yum install http://kojipkgs.fedoraproject.org/packages/GitPython/0.2.0/0.1.beta1.fc13/noarch/GitPython-0.2.0-0.1.beta1.fc13.noarch.rpm ...if you don't want the rpmdb warnings, and missing yumdb etc. data that is the reason for them. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/whatsnew/3.2.28 http://yum.baseurl.org/wiki/YumBenchmarks http://yum.baseurl.org/wiki/YumHistory -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg-turbo conflicts in rawhide
On Wed, 2010-06-30 at 10:04 -0400, Rich Mattes wrote: So this is a bug with yum not handling package obsoletes correctly when it processes the libjpeg.so.62 dep for graphviz? I suspect the problem is that libjpeg-turbo does not _provide_ libjpeg. So yum does: 1. pkg XYZ requires libjpeg 2. The provider for that is the libjpeg package. 3. The libjpeg package is obsoleted by libjpeg-turbo. 4. But, libjpeg-turbo doesn't provide libjpeg, which is the requirement we are doing all this for ... so ignore the obsolete and install libjpeg. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/whatsnew/3.2.28 http://yum.baseurl.org/wiki/YumBenchmarks http://yum.baseurl.org/wiki/YumHistory -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to lure me to updates-testing
Some of these require yum/yum-utils from rawhide...
On Wed, 2010-06-30 at 14:59 -0600, Nathanael Noblet wrote:
#1) Easy way to know where a package came from.
For example, as far as I am aware, I cannot query anything that tells
me X packages are from Y repo. If I were to become a 100% always
enabled updates-testing, most of my packages would be from that repo,
however if I only do it occasionally I'd just have to remember
If you just want a summary, you can do (depending on what you want to
know):
repoquery --installed -a --qf '%{ui_from_repo}' | sort | uniq -c
repoquery --installed -a --qf '%{yumdb_info.from_repo}' | sort | uniq -c
...or the easier to type/remember but maybe less likely what you want:
yum version -v nogroups
...if you could give us a better idea of what you are trying to do we
might be able to make something more usable.
#2 ) Easy way to downgrade if I were to run into problems
I understand that this isn't foolproof, and that for some issues (some
huge glibc error) my system could conceivably require advanced knowledge to
boot into a rescue mode, download packages and force the downgrade. However
some way to view the updates-testing packages I have installed, and downgrade
to the 'released' version would be awesome.
As Seth said you can use downgrade and/or history undo now. You'll
also be able to use distro-sync soon, which should give you a fix
everything now option.
#5) Easy way to turn on/off my willingness to use updates-testing.
Sometimes I could be busy and only want tested updates, it would be
nice if this imaginary tool I'm describing allowed me to say I'm done testing
for now, and it deals with disabling the repo and any reminders. If there was
some nice tool to deal with updates-testing enabling and the
inclusion/exclusion of packages I wanted to test and all that I laid out I
would be on it in a second, and I'm guessing you'd have even more testers.
The way I do this is have updates-testing disabled _always_. And then
use yum-plugin-aliases and then yum chkT and yum upT blah / yum inT
blah to check, update and install with updates-testing enabled.
Atm. I just enable updates-testing, but hopefully we'll eventually get
to a place where we can enabled based on repodata tags and those aliases
will also enable rpmfusion-*testing etc. if you have the main repos.
enabled.
--
James Antill - ja...@fedoraproject.org
http://yum.baseurl.org/wiki/whatsnew/3.2.28
http://yum.baseurl.org/wiki/YumBenchmarks
http://yum.baseurl.org/wiki/YumHistory
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Thu, 2010-07-01 at 00:20 +0200, Till Maas wrote: On Wed, Jun 30, 2010 at 12:50:53PM -0700, Adam Williamson wrote: You can already view all pending critpath updates in Bodhi's web interface and command line client, as per Luke's initial mail. But a yum enhancement or plugin to restrict e.g. update or check-update on only critpath updates might be interesting for people only interested in critpath testing. I thought the idea was that critpath packages would be in a critpath group in comps? -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/whatsnew/3.2.28 http://yum.baseurl.org/wiki/YumBenchmarks http://yum.baseurl.org/wiki/YumHistory -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc: python2.7 for F14
On Tue, 2010-06-22 at 23:26 +0200, Thomas Spura wrote:
How about this?
import os
p = set()
for pkg in os.popen('repoquery --whatrequires --alldeps python(abi) =
2.6'):
pkg = pkg.strip()
print Checking %s % pkg
p.add(os.popen('repoquery -s %s' % pkg).read().strip())
print p
Wow, python calling python through /bin/sh! I bow before you sir.
You could just do:
#! /bin/sh
repoquery --whatrequires --alldeps -s python(abi) = 2.6 | sort -u
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: llvm case study: yum's handling of newly-converted noarch subpackages
On Wed, 2010-06-09 at 08:38 +0530, Rahul Sundaram wrote: On 06/09/2010 05:00 AM, Kevin Kofler wrote: Michel Alexandre Salim wrote: Any idea how to fix this? We should probably add a section to the packaging guidelines, on how to migrate to noarch subpackages without breaking upgrade paths. Or just not support users who have unneeded multilib packages installed. Installing only those multilib packages that are actually needed has been the default since Fedora 9, if people set up yum to pull in everything as multilib, that's their problem. As long as yum offers it as a option, bugs must be fixed. Three minor points, about the original bug https://bugzilla.redhat.com/show_bug.cgi?id=600969 1. It has nothing to do with multilib. 2. It works fine now for all users updating llvm via. a repo (like updates or updates-testing). 3. It is fixed upstream. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/whatsnew/3.2.28 http://yum.baseurl.org/wiki/YumBenchmarks http://yum.baseurl.org/wiki/YumHistory -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
On Wed, 2010-06-09 at 18:08 +0200, Michael Schwendt wrote: On Wed, 9 Jun 2010 15:38:48 +0100, Stu wrote: I implemented it based on recommendations on the yum wiki that I saw someone else referred to in #fedora-devel : http://yum.baseurl.org/wiki/YumPackageUpdates#Packagesplit Well, that's exactly an example where the two Obsoletes compete with eachother. It works only partially. For an ordinary Yum update. It fails for a Yum install. I'm not sure what you mean by fail here. The above is the only way to do a package split ... which is to say you have: 1. pkgA-1 contains two files: /usr/bin/A and /usr/bin/A-blah 2. You now want to have pkgA-2 and pkgA-blah-2, which each contain a single file. 3. You want anyone who had pkgA-1 to have both pkgA-2 and pkgA-blah-2 (because that's what they had before). ...if at the end of the split you want yum install pkgA to install pkgA-blah (or vice versa), then it's not _just_ a split and you probably want to use a Requires (as you would if pkgA-2/pkgA-blah-2 were the first versions). You can do this instead of the obsoletes, but I don't see the point. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
On Wed, 2010-06-09 at 19:23 +0200, Michael Schwendt wrote: On Wed, 09 Jun 2010 13:10:10 -0400, James wrote: which is to say you have: 1. pkgA-1 contains two files: /usr/bin/A and /usr/bin/A-blah 2. You now want to have pkgA-2 and pkgA-blah-2, which each contain a single file. 3. You want anyone who had pkgA-1 to have both pkgA-2 and pkgA-blah-2 (because that's what they had before). ...if at the end of the split you want yum install pkgA to install pkgA-blah (or vice versa), then it's not _just_ a split and you probably want to use a Requires (as you would if pkgA-2/pkgA-blah-2 were the first versions). You can do this instead of the obsoletes, but I don't see the point. If at the end of the split user does yum install pkgA-blah-2, this erases pkgA-1 ... unless pkgA-blah-2 strictly requires pkgA-2, which is not always desired. And if the user never has pkgA-1 installed, and does install pkgA-blah then that's all they'll get. To put it another way when the user first installed pkgA-1 they could have wanted: 1. What pkgA-2 and pkgA-blah-2 provide. 2. What pkgA-2 provides. 3. What pkgA-blah-2 provides. ...but they got #1 because that was all pkgA-1 provided. Now there is a package split and the user can choose any of #1, #2 or #3. If you only want them to be able to choose between #1 and #2 (or #1 and #3) then you need some kind of requires _as well_. But that's because you have some requirement _as well_ as just a package split. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/whatsnew/3.2.28 http://yum.baseurl.org/wiki/YumBenchmarks http://yum.baseurl.org/wiki/YumHistory -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: about php-qa, phpUnderControl and meta packages
On Wed, 2010-06-02 at 14:52 -0700, Adam Williamson wrote: On Wed, 2010-06-02 at 18:31 +0200, Christof Damian wrote: Second question: I would love to have a meta package which brings all of these packages ( phpunit, phpmd, phpcpd, phpdoc, phpcs, Mockery, ...) together and allows installation with one yum command. But as far as I could detect from the random posts it seems that meta packages are not really wanted on Fedora. An alternative is the comps list, but that doesn't allow for rapid changes and phpqa would be a bit specific. For whatever reason, We Don't Like Metapackages and the 'recommended' way to do it is with a package group. I've never seen a particularly coherent reason given for this, but never mind. Some packagers _have_ done metapackages, and none of them have been shot yet. Just sayin'. Off the top of my head: 1. They are similar to groups and having two things that are similar is bad. 2. There's no way to do the groupremove operation, easily. 3. There's no way to do the groupinfo operation, easily. 4. There's no naming guideline, so grouplist operations are also not easily available. 5. You can't do: @mygroup -blah ...in a kickstart, if mygroup is a metapackage. 6. All the packages as part of the metapackage will be marked as reason = dep, which isn't true. 7. The one advantage they have (you can update the metapackage and have the new members added everywhere) will go away when we get groups as objects. 8. If you want to remove part of a metapackage, you have to remove the metapackage itself ... and thus. lose the only advantage they have. 9. There's no way to make them different for different spins. 10. There's no way to extend them from other repos. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.28 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: about php-qa, phpUnderControl and meta packages
On Fri, 2010-06-04 at 05:04 +0200, Kevin Kofler wrote: James Antill wrote: 2. There's no way to do the groupremove operation, easily. The groupremove operation is completely and utterly broken by design anyway: It doesn't act perfectly, in all cases, no. [...] Try groupremoving gnome-desktop on a system with both GNOME and KDE installed and watch it try to remove half of KDE while leaving half of GNOME sitting there wasting space. Right, gnome-desktop is a typical group. Silly me. And it just CANNOT be fixed. You mean apart from using yum from rawhide and doing: yum remove @gnome-desktop --setopt=groupremove_leaf_only=true ...or groups as objects, or... The only (mostly) reliable way to undo a groupinstall is yum history. And even that will only work as expected if the group was recently installed. So groupremove _has_ to do the same thing as an undo of a groupinstall to not be considered utterly broken by design? I guess that means plain remove is also utterly broken by design? Wait ... don't answer here ... if you want to troll/rant, feel free to send me personal email where I'll happily ignore it. Subjects like yum should be faster than rpm or why don't we just move to apt/smart/pacman/image-packaging-system are probably your best bang for the buck. -- James Antill - ja...@fedoraproject.org ... so the consumable rawhide is likely not to get as many updates as its users would like to have. -- Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wed, 2010-06-02 at 13:25 -0400, Matt McCutchen wrote: On Wed, 2010-06-02 at 14:48 +0200, Ralf Corsepius wrote: Well, then lets begin: # rpmlint yum yum.noarch: W: self-obsoletion yum-allow-downgrade 1.1.20-0 obsoletes yum-allow-downgrade [...] Which of those messages do you consider noise and why? Most of them look valid to me, though they are indeed nits. The self obsolete ones are wrong, being able to do: Name: foo Provide: bar = 2 Obsolete: bar = 2 ...is completely legal and needed for rename/merging which is why yum has them. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.28 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wed, 2010-06-02 at 23:15 +0300, Ville Skyttä wrote: On Wednesday 02 June 2010, James Antill wrote: The self obsolete ones are wrong, being able to do: Name: foo Provide: bar = 2 Obsolete: bar = 2 ...is completely legal and needed for rename/merging Yes (assuming you mean Obsoletes: bar 2, not = 2). No, I didn't. Obsoletes only work on package names, not on provides so it doesn't matter that the provide and obsolete overlap. Self-obsoletion used to cause problems in various tools in the past. I don't know if all of them contain workarounds nowadays, but on the other hand I don't think I've ever seen an actual valid use case for self-obsoletion. Yeh, I looked at the bug but I'm not sure what it is for. If anything it's probably a yum bug but the only one I know about is: http://yum.baseurl.org/gitweb?p=yum.git;a=commitdiff;h=568eaf5b88f376a1822396fd9dc7324d1aed23ea ...which was a while ago, and didn't cause much damage. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.28 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Remove 1507 Package(s) ?
On Thu, 2010-05-27 at 17:27 +0100, Jonathan Underwood wrote: On 27 May 2010 16:43, Jonathan Underwood jonathan.underw...@gmail.com wrote: I've just seen exactly the same thing with a system going from F12 to F13 with preupgrade. BZ filed here: https://bugzilla.redhat.com/show_bug.cgi?id=596840 As Seth suggested, this resolved the issue for me: yum downgrade nss-softokn-freebl nss-softokn I wonder if it should be added to the common problems wiki page. Ugh. Actually I see this problem with a lot of packages where the F-12 nvr is greater than the F-13 version: While it's not good packaging, most of the time these bad versions don't cause any problems. If you want to get rid of them easily though, feel free to install the yum from rawhide and run distro-sync. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: short window between fedora-release update and resuming of updates-testing
On Tue, 2010-05-18 at 23:50 +0100, Adam Williamson wrote: On Wed, 2010-05-19 at 00:24 +0200, Kevin Kofler wrote: Adam Williamson wrote: The window doesn't matter that much anyway, as by no means all packages pushed to updates-testing during the pre-final cycle have been (or will be) approved as updates. So it's perfectly possible people who installed pre-releases will have what you term 'unwanted' packages anyway. This seems to be to be reasonable for those who run pre-releases, but I suppose we could write it up somewhere for clarity... Yes, the broken decision was to enable updates-testing by default for prereleases and we should never do this again. It just can't work, because updates-testing is like the Red Pill: once you're on it, you can't get off anymore. The fedora-release update which disabled updates-testing broke many user setups, suddenly unable to install packages due to dependencies. [...] (and you can get off it, you can just search for packages from updates-testing and yum downgrade 'em. Wouldn't be too hard for someone to hack up a little script to do this and publish it somewhere, if they were terribly worried about this issue). For the rawhide yum (pre 3.2.28) you can just do: yum distro-sync ...this will downgrade everything to the latest available version (or try). This doesn't work over obsoletes, due to their one way nature, but should be good enough for most updates-testing downgrades. In practice it shouldn't be a hugely horrible problem after a few days/weeks, as most of the updates will get pushed or superseded. That too, one advantage of the firehose is it will make you clean pretty quickly ;) -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.28 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 13 continuing the tradition of being an update monster
Thankfully all the giant flamewars and new policies didn't make anyone think twice about the users, as we already have 140 updates with a combined size of _over_ 750MB on x86_64, biggest 5 are: 6.2M wesnoth-1.8.1-1.fc13.x86_64.rpm 12M hanazono-fonts-20100222-2.fc13.noarch.rpm 48M xmoto-0.5.3-1.fc13.x86_64.rpm 260M wesnoth-data-1.8.1-1.fc13.noarch.rpm 318M openarena-0.8.5-1.fc13.noarch.rpm ...the last being particularly nice, in that the package hasn't been updated for almost a year but now we get 2 300MB+ presents at once. Welcome to the new Fedora updates, much like the old Fedora updates. Hey, at least Kevin should be happy. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On Tue, 2010-05-11 at 10:30 +0200, H. Guémar wrote: It is not part of a default package set. Even if it were, blocking bugfixes in order to reduce updates size is nothing but stupid. It wasn't bugfixes, it was a new upstream release, and yes size does matter. All mirrors, public and private, now have 300MB of worthless bits in their 13 release (and it's not even released yet). And this for something that hasn't been updated throughout the life of F-12. It again goes to the point of why bother making releases at all, if they mean so little. And, trying to be less grumpy, maybe moving some packages to rawhide only style of repos. would make everyone happy (we could even call it extras :). We have presto/deltarpm for that (since these packages mostly contain unchanged binary data like images, it should work pretty well). Within Fedora deltarpms have a limit of applying only to rpms less than 100MB, so there are no deltarpms. Anyone who wants to blame rel-eng for that is free to fix the delarpm code, or give money to rel-eng to buy HW. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On Tue, 2010-05-11 at 08:29 -0500, Jon Ciesla wrote: On 05/11/2010 01:14 AM, James Antill wrote: Thankfully all the giant flamewars and new policies didn't make anyone think twice about the users, as we already have 140 updates with a combined size of _over_ 750MB on x86_64, biggest 5 are: 6.2M wesnoth-1.8.1-1.fc13.x86_64.rpm 12M hanazono-fonts-20100222-2.fc13.noarch.rpm 48M xmoto-0.5.3-1.fc13.x86_64.rpm 260M wesnoth-data-1.8.1-1.fc13.noarch.rpm 318M openarena-0.8.5-1.fc13.noarch.rpm ...the last being particularly nice, in that the package hasn't been updated for almost a year but now we get 2 300MB+ presents at once. Welcome to the new Fedora updates, much like the old Fedora updates. Hey, at least Kevin should be happy. Speaking as the wesnoth and xmoto maintainer, I've, in the past, asked for wesnoth releases of this nature to be tagged into final to same mirror space, but, again, it's not in the default spin Wesnoth was annoying, but at least it is consistent as you seem to do an update about once a month. , and we now have deltarpms (and a huge thank to to all responsible there), so I really don't think it's that big of an issue. As I said in another reply, there are currently no deltarpms for wesnoth-data due to it's size. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On Tue, 2010-05-11 at 19:10 +0200, Ralf Corsepius wrote: On 05/11/2010 07:03 PM, Jesse Keating wrote: On Tue, 2010-05-11 at 18:44 +0200, Ralf Corsepius wrote: On 05/11/2010 06:27 PM, James Antill wrote: As I said in another reply, there are currently no deltarpms for wesnoth-data due to it's size. Then fix this deficiency of your process and provide them. Patches welcome. Part of it is lingering in bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=563866 No it isn't, your pet RFE doesn't help Fedora rel-eng at all. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On Fri, 2010-05-07 at 20:05 +0100, Adam Williamson wrote: What worries me is that it was always my understanding, and I think the understanding of others, that the hall monitoring policy does not grant hall monitors the power to shut down threads they judge to be repetitive. My understanding is it should only grant them the power to shut down threads which violate the 'be excellent to each other' motto - i.e., it's about the civility of the discussion, not the subject matter. The thread was repetitive from a thread that had been shut down because it had degenerated way past be excellent to each other, and seemingly was restarted explicitly to incite more flames, misinformation and hatred. The only thing I found objectionable was that it was allowed to last _so_ _long_ before being killed. Hopefully, in the future, if a thread is hall monitored the people who were the main reason it got out of control won't be allowed to wait a few weeks, change the subject and start it back up. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FYI: NVR issues from f12 - f13
On Tue, 2010-05-04 at 23:53 -0400, Seth Vidal wrote: On Tue, 4 May 2010, John Reiser wrote: Here's a list of f12 - f13 with unclean update paths based on srpm. Text search is powerful, but a sorted list is even better. The script I wrote to make this list is here: I should have sorted the pkgs at the end, sorry. Am I going blind, or did you fail to paste the URL?:) I did a current vs. rawhide one, a ages ago: http://james.fedorapeople.org/yum/commands/yum-newer-than-rawhide.py ...which should probably be merged with the inter distro. one, at some point. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.28 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: popularity package context on fedora
On Mon, 2010-05-03 at 19:20 +0100, Athmane Madjoudj wrote: It's been suggested many times before, but no one has really stepped forward to champion it. ;) There is an rpm version being worked on by an OpenSUSE person: http://gitorious.org/opensuse/popcorn Something would need to be packaged, tested, etc. Then the problem becomes what data to store, how to store it. It's going to be a vast amount of data, and we would need some server to store it, policies around when to drop entries, etc. Not that I think it's a bad idea, It just needs a group of determined people to work on and make it happen. ;) i have looked at the source code (C server side / Python client side), it uses libtdb [1] as storage back-end (a plain text format) TDB is not plain text it's a key/value store, like BDB/etc. , i think that sqlite is better, and you can port it to other DBMS such as Postgres or MySQL [1] http://tdb.samba.org My guess is that sqlite would be nicer though, as I'd imagine you wouldn't want to store just key/values. But how it can be integrated in Fedora, by writing yum plug-in ? I can't think why you'd want a plugin, but you'd probably need to use the yum API ... at least so you could get data out of yumdb. The client side should be truly trivial though. Dumping the installed packages, which repos. they came from and the reason for their install ... is probably like 10 lines of yum code. If someone is doing this work, they'd probably do a bit more to get more info. ... but again, it would be trivial in comparison to the work needed on the server side (and to get people to install it etc.) -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.28 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F13/i686: yum update emptied /boot, /bin, /lib, etc.
On Fri, 2010-04-23 at 15:52 -0400, Seth Vidal wrote: On Fri, 23 Apr 2010, Jim Meyering wrote: I've just realized that I had a list of all packages/versions that were installed as of a few weeks ago (April 5). In case it helps: Yah - the history sqlite file you uploaded has all that info in there (in a round about way) but the problem still is we don't know what precipitated all the erasures. b/c those erasures are JUST erasures, they aren't the cleanup step of an update. which points me at weird plugin behavior. Jim, is it possible you were running with LANG=C? If so I'm 99% sure I've found the bug: https://bugzilla.redhat.com/show_bug.cgi?id=585424 Langpacks goes on crack in LANG=C, for removals _and_ updated, removing everything -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.28 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PolicyKit-authentication-agents in Fedora
On Thu, 2010-04-08 at 18:05 +0200, Christoph Wickert wrote: I just imported lxpolkit into CVS, but it's not yet build because I don't want to break anything. We now have 3 PolicyKit-authentication-agents in Fedora: * polkit-gnome * polkit-kde * lxpolkit As you can see lxpolkit has the shortest name and will therefore be chosen by yum if anything requires PolicyKit-authentication-agent (ATM system-config-samba and system-config-services). Note that another change to how we pick a provider just went in upstream, and will likely hit rawhide tomorrow sometime: http://yum.baseurl.org/gitweb?p=yum.git;a=commitdiff;h=00633bee2f6b3987351dd2fef5678f4a481f0057 ...as the commit says this is simple so we might still not get what people want¹ but if you do: yum --installroot=/tmp/dep-test --releasever=12 --enablerepo=rawhide \ install @base @core icewm² system-config-samba ...you now get polkit-gnome, due to the fact it only has 8 unfilled requirements and polkit-kde has 10. Dito. notification-daemon vs. xfce4-notifyd if you install @base @core gdm. ¹ There are ways to game it, if needed ... but that will likely involve pain for someone. ² Note that in rawhide gnome-session now requires polkit-gnome explicitly, so this is mostly irrelevant for the default desktop. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.28 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20100413 changes
On Tue, 2010-04-13 at 22:03 +0200, Michael Schwendt wrote: On Tue, 13 Apr 2010 12:35:09 -0700, Jesse wrote: I wonder if there's something about the commit message which caused the report to chop it off? No, it's a [fixed] bug in repodiff, which ignores %changelog entries added on the same day as the latest entries found in the previous release of the package. The sys-admins would need to upgrade repodiff, createrepo, and dependencies, to those versions that fix this. It's related to Yum upstream tickets #6 and #7. This report is generated in a chroot of rawhide, so if those fixed builds are in rawhide than they will be used. -- Jes Well, then somebody should reopen http://yum.baseurl.org/ticket/7 and ask for applying the fix to repodiff. It's included in the patch I added to the ticket more than a year ago (the timestamp comparison fix to cover changes added on the same day). Sorry for that, I thought I'd fixed it when I closed it! Anyway, just built a new yum-utils HEAD (which includes the repodiff fix) in rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=2115503 -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up! Erlang package becomes modularized in Fedora.
On Sun, 2010-04-11 at 10:33 -0700, Chris Weyl wrote: On Sun, Apr 11, 2010 at 2:27 AM, Nicolas Mailhot nicolas.mail...@laposte.net wrote: Le dimanche 11 avril 2010 à 10:06 +0400, Peter Lemenkov a écrit : Hello! 2010/4/10 Nicolas Mailhot nicolas.mail...@laposte.net: So you are proposing a metapackage. Fedora has historically frowned at metapackages, we prefer to create comps groups to bundle multiple packages together. [...] Not to rehash anything, but a little more info on what other package islands are doing :) We've been doing this in the on the Perl side for a while now -- since we split perl out into multiple subpackages, we've had a perl-core metapackage that ties it all together, for those wishing to ensure that all parts of Perl traditionally thought of as core are installed. To my knowledge, there's never been any _technical_ problem with this approach, and it transparently Just Works with the typical yum upgrade process. It does just work with yum install and update, however there are at least two significant annoyances: 1. yum remove is kinda broken, because it just removes the metapackage. This is very confusing for new users, and can often lead them down the wrong path. For a recent example I saw: http://lists.baseurl.org/pipermail/yum/2010-April/023241.html ...even though this would be fixed the new groups, I could be convinced that the advantages of install/update override the disadvantages of remove. 2. There doesn't seem to be any policy on naming, I've seen at least: core | metapackage ---|- git| git-all nagios-plugins | nagios-plugins-all perl | perl-core tor-core | tor wine-core | wine ...personally I think the scheme used by tor and wine is the most prevalent, and most obvious to users ... but I'd be happy with anything being the std. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unsigned Packages - Yum/Pk
On Sat, 2010-04-03 at 12:52 +0100, Frank Murphy wrote: PackageKit allows a forced install of unsigned pkg. yu does the following: Package krb5-libs-1.7.1-7.fc13.i686.rpm is not signed I know about --nogpgcheck. But can I edit something to the effect of: If unsigned don't include. Yum can only tell if something is signed (and by what key it is signed) after it has downloaded the package. Currently we have no easy way to exclude packages after the download phase (the basic problem being we'd need to go back and redo the transaction, which was a couple of steps earlier). Which is to say, no. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide repo giving me an odd error
On Mon, 2010-03-29 at 00:03 +0100, Paul wrote: Hi, I've been away from my pc for the last couple of days and have come back to find a problem. When I try to do an update from yum, I'm getting the following error Error: Cannot retrieve metalink for repository: rawhide. Please verify its path and try again To get more info use: URLGRABBER_DEBUG=1 yum check-update Looking at the fedora-rawhide.repo file, nothing looks untoward. If I change from using the mirrors to the baseurl, the error goes, but then it also reports that there are no updates available. Have I missed another change? The system was happily doing auto updates until (I think) Thursday. You can use: yum repolist -v rawhide ...to see when the last time you got data was, if it's over a couple of days for rawhide something bad is probably happening. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Conflicts in latest update
On Tue, 2010-03-16 at 20:09 +0100, Thorsten Leemhuis wrote: On 16.03.2010 17:42, Till Maas wrote: On Tue, Mar 16, 2010 at 01:45:33PM +0100, Thorsten Leemhuis wrote: There are so many developers around on this list that know: reporting bugs is the right way to get problems fixed and fixing things is way better than posting workarounds to public places for various reasons -- nevertheless nobody filed a bug yet afaics :-/ Imho it was not that obvious that there is a bug present, because these kind of delays are usual with RPMFusion, because the repos are not directly synced. That IMHO something that needs fixing on the Fedora side (e.g. in yum) http://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html But I lost energy driving a solution forward. I'm not sure what you want us to do, the main problem is that splitting a DB of packages and then stitching it back together doesn't work 100% of the time ... this isn't us being stupid: http://en.wikipedia.org/wiki/CAP_Theorem ...yum repo DBs are AP and not C. Skip-broken helps in all cases apart from file conflicts, which is a packaging bug. Your idea of timed skip-broken by default doesn't work because we don't have a date package was released ... although PK currently does skip-broken by default, all the time. E.g. I just expected it to work within some days and if it did not, then I would have thought there might be something wrong. Well, there were a few cases in the past where problems like this one persisted for a few days because everybody thought like you outline :-/ But I have no solution for that apart from if in a doubt file a bug :-( Rpmfusion can run auto QA like tests on rpmfusion and Fedora (I don't think we can legally do the same ... but I'm not sure). Finding the file conflicts automatically is harder (you need to download all the rpms), and it's not fast, but it's possible (Seth has a script, IIRC). -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes for 2010-03-09 FESCo meeting
On Wed, 2010-03-10 at 00:05 +, Jonathan Underwood wrote: On 9 March 2010 21:54, Bill Nottingham nott...@redhat.com wrote: === #fedora-meeting: FESCO (2010-03-09) === Meeting started by nirik at 20:00:01 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-03-09/fesco.2010-03-09-20.00.log.html [snip] Wow. That has to be the most depressing and apalling read ever - seeing FESCo, the steering committee of a project which has done so much good and made so much progress, tear strips off each other like that. If FESCo is this dysfunctional, I really think there's a problem larger than the number of regressions in our updates. FESCo, you really need to start working together, you're presently not doing the job you were elected to do. Well as someone watching it in realtime, that wasn't the impression I got. In fact I'd say the meeting suffered a lot due to most of FESCO being way too polite, a single take voice around 20:44:10 would have made the next 45 minutes much more useful. IMO, anyway. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How does one deal with obsoleted updates from updates-testing
On Mon, 2010-03-08 at 18:54 +, Quentin Armitage wrote: On Mon, 2010-03-08 at 10:26 -0500, Seth Vidal wrote: On Mon, 8 Mar 2010, Quentin Armitage wrote: The glibc packages (including nscd) were in updates-testing, but have been obsoleted, and so 2.11.90-12 is now the current version again. What is the mechanism for becoming aware that a package that has been installed through updates-testing has been obsoleted (especially since the standard install of F-13 rc has updates-testing enabled)? They've not been obsoleted, they've just been updated. Obsoleted has a different special meaning in rpm-parlance. Sorry, I should have been clearer. glibc-2.11.90.14 is showing in Bodhi as being Status: obsolete. Bodhi shows that version was pushed to testing, and it was installed on my system when I installed F-13 on 1st March. That version appears is now no longer in updates-testing, and the current version is the earlier version, glibc-2.11.90-12. So far as I can see, there is no automatic mechanism to become aware of when a package has been in updates-testing and has subsequently been removed (?due to obsoleting in Bodhi), and the package needs reverting to an earlier version. I assume you know about yum downgrade, and yum list extras (and/or using the color indications in yum list) with updates-testing enabled. So I assume you want something else, I guess a push kind of notification? If you've commented to the update doesn't bodhi email you if the update is removed? If not I'd say create a bodhi RFE ... but apart from that I'm not sure how a push notification could occur. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to install software without root password (PolicyKit?)
On Mon, 2010-03-08 at 20:51 +0100, Valent Turkovic wrote: Hi, Fedora 12 was planned to have installation of packages without users needing to enter root password. How do I enable this feature via PolicyKit? I read this article: http://skvidal.wordpress.com/2009/11/18/polkit-and-package-kit-and-changing-settings/ but even after doing that it is still the same and yum install package asks for root password. The feature was added to PackageKit not yum ... so you need to use pkcon, not yum. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Move a configuration file
On Sun, 2010-03-07 at 17:55 +0100, Johan Cwiklinski wrote: Hello, I have a small question regarding a configuration file for BackupPC. BackupPC requires a file for apache users. This file is referenced in /etc/httpd/conf.d/BackupPC.conf and points to /usr/share/BackupPC/apache.users. I think that is a mistake, and such a file should better be placed in /etc/BackupPC/apache.users. If I change the path in conf.d/BackupPC.conf ; users who have modified the .conf file will get a conf.rpmnew file ; that's fine. The ones who did not change the .conf file will have it replaced by RPM, breaking the apache authentication. Any thoughts about that? To give a slightly different opinion, I'd move the users file but put a symlink in the old place pointing to the new place ... then both old and new config. files will work. As other said, watch out for relabeling etc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Fri, 2010-03-05 at 00:14 +0100, Michael Schwendt wrote: On Tue, 02 Mar 2010 20:19:48 -0800, Jesse wrote: Extras had significantly fewer packages, Well, Fedora Extras 6 (x86_64) contained 5129 packages, which is only 300 less than F11 stable updates. http://archive.fedoraproject.org/pub/archive/fedora/linux/extras/6/x86_64/repoview/index.html *sigh*, I almost managed to not respond to any of these threads today. Anyway (trying to say just the facts): % yum repolist --releasever=11 updates repo id repo name status updates Fedora 11 - x86_64 - Updates9,390 repolist: 9,390 ...and it's only ~65% done. That also doesn't take into account the fact that we've released ~17k F11 updates, which I'm pretty sure didn't happen for F6 extras. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Thu, 2010-03-04 at 18:30 -0800, Jesse Keating wrote: On Thu, 2010-03-04 at 20:11 -0500, James Antill wrote: On Fri, 2010-03-05 at 00:14 +0100, Michael Schwendt wrote: Well, Fedora Extras 6 (x86_64) contained 5129 packages, which is only 300 less than F11 stable updates. http://archive.fedoraproject.org/pub/archive/fedora/linux/extras/6/x86_64/repoview/index.html % yum repolist --releasever=11 updates repo id repo name status updates Fedora 11 - x86_64 - Updates9,390 ... This probably won't go well unless you two are talking about the right terms. I believe that Michael was talking srpm numbers, where you appear to be talking binary numbers. The Michael gave was for binary packages in FC 6 x86_64 extras: % GET http://archive.fedoraproject.org/pub/archive/fedora/linux/extras/6/x86_64/ | \ fgrep '.rpm' | \ wc -l 5129 ...maybe he thought that was srpms though. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Wed, 2010-03-03 at 07:52 +0100, Kevin Kofler wrote: James Antill wrote: This isn't a hard problem, 3.0 should then be marked as a security update. But the case we're discussing is that 3.0 was pushed long before it was known that it happens to fix a security vulnerability. We're not going to arbitrarily push another update and call it security when it doesn't fix any security issue that's not already fixed. I would assume you could just change the updateinfo for the the current update to mark it as security, this is a tiny amount of extra work on the packager side ... but without it all the work to create the security types on updates is worthless. This is just another failure point of yum-security. This would be the _only_ failure point, if in fact it is policy (and isn't going to be fixed). Of course it's such a huge issue I'll have to make the --security option a noop in Fedora if true, no arguments there the option would be worthless. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Tue, 2010-03-02 at 23:57 -0800, Adam Williamson wrote: I wasn't suggesting that's what happens in Fedora at present, just that - given a single update stream in which it's perfectly fine for 'security' updates to build on 'feature' updates - it's impossible to cherry pick only security updates. This is Fedora. Security updates can come with new features, that's life. You can have zero updates for a package, and then do a rebase to fix a security problem and also Require: the latest versions of everything else in updates for all I care. The security problem is _fixed_ though, so your system is secure, and that's all that --security guarantees (and it has made minimal updates, it's just that minimal is bigger than with say RHEL/CentOS). -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Wed, 2010-03-03 at 17:09 +0100, Till Maas wrote: On Wed, Mar 03, 2010 at 11:02:51AM -0500, James Antill wrote: If we had less updates, that changed less things and required more testing before pushing them to users ... this would be entirely possible. Less updates mean more changes per update or you have more buggy packages, because updates usually fix bugs. As I would assume any programmer knows: Not all bugs are created equal. Trading no regressions for some minor bugs still remain is a trade lots of users are happy to make (see: every customer of every piece of commercial software, ever). -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Worthless updates
On Wed, 2010-03-03 at 19:43 +0100, Thomas Janssen wrote: On Wed, Mar 3, 2010 at 7:01 PM, Bill Nottingham nott...@redhat.com wrote: Thomas Janssen (thom...@fedoraproject.org) said: As i said before. Nobody holds a gun on my head and tells me you have to update that packages. If you dont want it, read the man yum and exclude what you dont want. That's what i did in F-10. When there's no policy, and the user has to guess whether or not they need to do this for every package on their system, however, you have a mess. Well, except there's nothing to guess. The regular user should by all means know what a security fix is. As well as a bugfix. And i think the regular user knows as well what an enhancement is. So he can decide very well what he want. Welcome to the wonderful world of the KDE packager: -- But the user doesn't have to install everything I ship, -- /they already have choice! \ || \-- But I ignore old security bugs, so --security doesn't --/ work anyway, everyone should just yum update -y, that's what I do! ...I'm dizzy, my head is spinning, like a whirlpool... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Worthless updates
On Wed, 2010-03-03 at 20:33 +0100, Kevin Kofler wrote: Peter Jones wrote: On 03/03/2010 01:17 PM, Kevin Kofler wrote: Mathieu Bridon wrote: In the end, I think the question is not about giving users what users want (be it frequent updates or stalled releases), but giving users what we see as a better deal for them. I think wanting to decide for your users is a really arrogant attitude. But that's exactly what you do with rebases during a stable release. It's the user's choice to use a progressive distribution such as Fedora rather than a semi-conservative one like Ubuntu or a conservative one like RHEL/CentOS or Debian stable. choosing a sane update policy for users == bad! Users should be allowed to choose! choosing to dump almost anything you want into stable == good! Users can always go use another distro. if they don't agree with me! /me wondering why I'm even reading this thread anymore -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Tue, 2010-03-02 at 11:22 +0100, Kevin Kofler wrote: James Antill wrote: It's still not really usable by normal users, but people on this list can install yum-plugin-local ... which will make sure you can do downgrades like this. Isn't keepcache=yes sufficient? IMHO that should really be the default, I really don't understand why we default to throwing away the cache. Again, diskspace is the primary concern. However the yum-plugin-local package needs to do a bit more than that, because the metadata goes away from the remote repo. as well as the packages ... so we need to create our own local repo. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Tue, 2010-03-02 at 09:45 +0100, Kevin Kofler wrote: I didn't bring up the fun argument. My point is that banning direct stable pushes prevents us from fixing things for our users ASAP when needed. This is all part of duty, not fun. And it prevents us from breaking things, with no warning (around and around we go). In addition, in practice, it's quite likely that bugs will often be answered with it's too hard to backport that particular fix, upgrade to the current version from backports (or even Cooker/Rawhide/whatever) if you need it. There's no way you can really force maintainers to provide an update stream which is stable under that definition (no upgrades, only backported fixes). I know you aren't talking specifically of my proposal here: https://fedoraproject.org/wiki/Release_Lifecycle_Proposals#Choice_.28james.29 ...but it has the same problem. But IMNSHO this isn't a problem, you are arguing that people specifically hit by problem X can goto the updates-testing (or whatever it's called) repo. and get a fix for it. Anyone not affected doesn't have to risk that update breaking anything else they do care about (and for the people affected, if the cure is worse than the disease they can easily backout). And that's only until the new version has been tested enough that it's a lot more safe to give it to everyone. How is this not the best of all solutions? (for the users) Many instances have shown that it does not give us the bugfixes 'for free'. It comes with the cost of causing regressions. That may be a cost which we decide we want to bear, but portraying things in a Panglossian manner doesn't help your cause, as it just makes you look like you're denying there could ever possibly be any problems with your method. But that's not a cost for the maintainer (unless the regression breaks his/her own system). :-) Indeed, this comment does seem to epitomize your argument. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Tue, 2010-03-02 at 10:59 +0100, Kevin Kofler wrote: James Antill wrote: So I did my proposal, which I think will motivate packagers to do the right thing (giving lots of choice to the users and a reasonable number of packages to test) and not removing the ability of packagers to do what they want (and have the stable firehose): https://fedoraproject.org/wiki/Release_Lifecycle(draft)#Choice_.28james.29 This is now at: https://fedoraproject.org/wiki/Release_Lifecycle_Proposals#Choice_.28james.29 I don't really see how this is adding any kind of choice. In particular, it doesn't address the but they have almost no options if they are happy to stay with the software that they have problem you're presenting in your introduction at all. Users don't get a constant firehose of updates they are basically forced to install, a lot more packages should spend a lot more time in testing (thus. the user can choose to get the updates or updates-testing versions). How is that not more choice than here's rawhide-12, you are now forced to test it for me? The other proposals are for the what kind of updates do we allow subthread, yours is for the when do we allow the push to hit stable as opposed to testing thread. So I think both the naming (Choice) and the location (Release Lifecycle) of your proposal are misleading. I read them all as trying to solve the what do we do in the lifecycle of a release, to make it suck less for users problem and general stop users saying Well I use Fedora in spite of the number/size of updates. One way is to just outright ban a lot of updates, but this then becomes subjective and I'm not sure rel-eng is setup to do that. So I proposed something that could be objectively implemented, and would give the packagers the freedom to do the updates the think are best. I think your proposal makes sense as a purely informative guideline, at most as SHOULD, but NOT as something to be enforced. It is very hard to enforce something like this (who would classify the updates into those categories?) The packagers would classify their bugs, in make update mostly as the do now (although there are more categories). I don't think anyone is arguing that packagers are actively trying to harm anybody, so I'd assume they would classify them correctly in the vast majority of cases. The problem with leaving it as a SHOULD is the tendency for packagers to be significant users of their packages, so they tend to be affected more by bugs and tend to want features ASAP. The desire to say well this isn't _that_ big a change, and it's been in testing a couple of days so it's probably fine is very big. I think may have also missed the fact that DSUT _increases_ (to stop the practice of having 1 update a month for a package, so the user is forced to get them all or none) with each push from updates-testing to updates. I find it less believable that packagers will follow that (esp. considering the above). In fact, we already do have such an indicative list internally in KDE SIG, the approximate numbers we use: * regression fixes, security updates, trivial bugfixes, new packages (*): may be queued directly to stable, 0 DSUT otherwise * other small bugfixes: 0 DSUT (but should be allowed to hit testing before being queued to stable, and it depends on feedback how long to wait in testing, up to about a week) While I admit that I made the numbers up, and so am happy to discuss changing them slightly ... your opinion that there should be a large class of updates which go directly to stable, with no testing, is IMNSHO insane. * upstream bugfix releases or other large bugfixes: 7 DSUT * upstream feature releases of individual applications (where suitable for an update): 7 DSUT You have 21 days of testing for the first update, and over a month for the second ... really? * upstream grouped feature releases, e.g. all of KDE (where suitable for an update): 14 DSUT Again, that's over a month for the first update and about 3 months for the second ... I find it hard to believe you are willingly that conservative. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Tue, 2010-03-02 at 11:06 +0100, Kevin Kofler wrote: Peter Jones wrote: This is the plan that already isn't working. Is it really not working? Or are we overblowing a minor incident which didn't even cause all that much trouble and trying to swallow a cure which is worse than the disease? I think it's really the latter. The one minor incident being where the project leader had to post to the world that we'd screwed it up, and got covered in LWN etc. I don't think I'd like to wait for something you'd class as a non-minor incident. I probably spend at least an hour a week updating, and current have over 220 packages available to update (a significant part of which are shared libraries linked against most of the distro.). Download size for everything is just over 330MB. History summary since GA shows over 1,100 Erases, Installs, Obsoletes and Updates. Probably when I next reboot, I'll just do a giant yum update -y and hope for the best ... which is what I assume most of our users do. If you think there's nothing wrong with that, and even more so if you think updates-testing should be bypassed in a significant number of cases, well then rawhide is that = way. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Tue, 2010-03-02 at 10:57 -0500, Frank Ch. Eigler wrote: James Antill ja...@fedoraproject.org writes: https://fedoraproject.org/wiki/Release_Lifecycle_Proposals#Choice_.28james.29 Regarding this, I don't understand this part: The idea behind this proposal is that a Fedora user installing a release N has a lot of choice if they wish to get newer packages: * They can move to rawhide. * [...] * If they are on an older Fedora release, they can update to the latest Fedora release. ...but they have almost no options if they are happy to stay with the software that they have. Doesn't just not running random/unrestricted yum update exactly encode that option? No, for two reasons: 1. The user is often informed, from various sources, that they should apply updates. We even want users to do that. Of course the assumption with that advise is that there aren't that many updates, and they will mainly be severe bug fixes and security fixes ... and they will have gone through a lot of testing. 2. If you have 10 updates available, you can realistically look at what the updates do and even pick and choose what to install. Maybe with fixes to the PK GUI that might be close to reasonable for 100 updates. But if you have 1,000 updates, the choice is roughly run yum update -y or do nothing. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Tue, 2010-03-02 at 12:08 -0500, Frank Ch. Eigler wrote: James Antill ja...@fedoraproject.org writes: [...] ...but they have almost no options if they are happy to stay with the software that they have. Doesn't just not running random/unrestricted yum update exactly encode that option? No, for two reasons: 1. The user is often informed, from various sources, that they should apply updates. We even want users to do that. OK, but then we're not talking about the person who's happy to stay with the software they have, but about a more typical person who is not too risk-averse and is willing to consider unsolicited updates. Those are different dudes. Right, I figured that was implied. If I'm happy with, say, named as it came in F12 ... that implies I don't want any updates for new features which might break my nameserver, but I'd still want any high exposure security fixes _quickly_ ... and I'd be happy to see significant bugfixes for existing problems (but, again, I don't want to see 1 update a month to fix small problems). Could you suggest better wording (that's smaller than the above paragraph :). Of course the assumption with that advise is that there aren't that many updates, and they will mainly be severe bug fixes and security fixes ... Fedora updates may be classified, but perhaps not granularly enough. An update can include a mixture of security fixes, serious bug fixes, minor bug fixes, new features, and of course risks such as changed configuration files, new known bugs. Perhaps a new update could be scored by the maintainer on all these scales, so that the client update interface can easily filter/sort to the preferred top few. I think it's understood that you can just take one and classify the bundle as that. Obviously there is still some leeway here, and we might need more policies but starting by asking the packagers to DTRT doesn't seem like a terrible idea. and they will have gone through a lot of testing. Well, this being Fedora, a lot of testing is always a matter of faith. Sure, we don't guarantee it and we still won't be able to ... but there's a big difference between this has been in updates-testing for 3 days (or less!), has 10 bug fixes and 10 new features compared with this has been in updates-testing for a month, been updated twice to fix minor problems found in testing and has 10 bug fixes and 2 new features. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tor dependency insanity.
On Tue, 2010-03-02 at 20:31 +0100, Enrico Scholz wrote: Adam Williamson awill...@redhat.com writes: I'm not quite sure why it needs separate lsb/upstart init scripts anyway. All the initscripts have huge and broken dependency chains. E.g. assuming I would use the vanilla fedora 'initscripts' package, then tor would still require[1] syslog, cpio, e2fsprogs, ethtool, mount, ... You are joking, right? I mean apart from the fact that there is a _huge_ difference between requiring mount and libX* ... the _kernel_ requires the package initscripts is installed. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Wed, 2010-03-03 at 01:34 +0100, Björn Persson wrote: Adam Williamson wrote: you can try and cherry-pick security updates, but then you get the problem where initial release has Foobar 1.0, then Foobar 3.5 gets shipped in updates, then a security problem emerges and Foobar 3.5-2 with the security fix gets shipped in updates. You now have a choice of unsecure Foobar 1.0, or completely new version Foobar 3.6. There's also the other variant where a security problem is found in Foobar 1.0 but the problem isn't present in Foobar 3.0 and later. Upstream still supports the 1.0 branch and releases Foobar 1.0.4 to fix the problem, but no security update is released for Fedora since there is no problem in the latest Fedora package. The Fedora user who chose not to upgrade Foobar won't even know that there is a security problem. This isn't a hard problem, 3.0 should then be marked as a security update. Sure it sucks that you have to go from 1.0.4 to 3.0, and presumably a lot will change, but that's Fedora. On the other hand if yum --security update does not fix the known security problems on your system, that's a huge exploit waiting to happen ... and one I doubt any users know about. I've sent a query to security@ to clarify. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Mon, 2010-03-01 at 13:01 -0500, Tom spot Callaway wrote: On 03/01/2010 12:48 PM, Peter Jones wrote: I'd also like a policy in place to help us avoid situations like the recent dnssec unpleasantness. Sure. I'm just not at all convinced that if those packages had sit in testing for $ARBITRARY_PERIOD_OF_TIME that they would have been tested and fixed. But that's mostly self-fullfilling, at the moment I doubt anyone keep up with the numbers of packages hitting updates ... so expecting people to keep up with that _and_ test a significant portion of updates-testing is just asking too much. It would also help if we cut down on the number of updates for each package, and had better update descriptions for each package. So I did my proposal, which I think will motivate packagers to do the right thing (giving lots of choice to the users and a reasonable number of packages to test) and not removing the ability of packagers to do what they want (and have the stable firehose): https://fedoraproject.org/wiki/Release_Lifecycle(draft)#Choice_.28james.29 -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Mon, 2010-03-01 at 12:06 -0800, Josh Stone wrote: But for rolling back an update, yum requires that the old package is still available. We only keep the very latest version in the updates, so unless your previous version was from the initial release, you're out of luck. My last yum-update hit 19 packages, and only 7 can be downgraded by yum-history-undo. It's still not really usable by normal users, but people on this list can install yum-plugin-local ... which will make sure you can do downgrades like this. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants a more sane updates policy (feedback requested)
On Sat, 2010-02-27 at 15:21 +, Richard Hughes wrote: On 26 February 2010 22:54, Kevin Fenzi ke...@scrye.com wrote: - If stable pushes were more restricted, perhaps that would get us more testing? If someone required a newer version and could easier install/test from updates-testing and provide feedback, don't we all win? Perhaps we could have PackageKit/yum say you have the latest stable version of foo, but foo-2.0 is in updates-testing, would you like to test it and provide feedback? I had PK code to do that, but the check for updates took way too long, as the updates-testing repo had to be enabled, the primaries downloaded (and maybe the file lists too), updates resolved and then disabled again, in ADDITION to the normal updates check. The package manager is just too slow to get PackageKit data to make such a thing work without making the user wait an extra 30 seconds. I can't think of any reason why you'd need, or want, to have updates-testing checks block any other GUI operation. If we could speed up the dep checking and downloading, I agree it would be better for usability, and the exposure of updates-testing generally. Dep. checking is pretty fast, upT¹ is roughly 10 seconds for 300 packages here and lsuT is like 2.5 seconds. I guess maybe that's worth caring about if you block everything else behind it, but... As to the downloads, if you know of a way to speed up a users internet connection ... feel free to spread your wisdom. ¹ We also have an optimisation for large updates, that we can probably turn on for F13. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Mon, 2010-03-01 at 00:58 +0100, Kevin Kofler wrote: Mike McGrath wrote: So when Fedora 12 came out, we allowed users 7 months to upgrade because the latest version of stuff is too unstable for them. At the same time we're also forcing them to upgrade to the latest versions of those packages in F-11 anyway? I hope you can at least acknowledge why I'm not following the logic here? Those packages we're upgrading in F11 are not the ones which are causing their problems with F12. E.g. KDE 4.4 can't possibly be what prevented them from upgrading to F12 because F12 originally shipped with 4.3. Mike didn't say that, Mike said that if a user was intentionally not updating to Fedora 12 due to the newer KDE ... you've just removed that choice from them. And for no real gain, as anyone who wanted to the KDE update could easily move to Fedora 12 to get it. But after changing the question to one you think you do better at, you are still wrong. The current state of play is (taking a random kde example): kdeutils F11 GA 4.2.2-4.fc11 kdeutils F11 Updates 4.4.0-1.fc11 kdeutils F12 GA 4.3.2-1.fc12 kdeutils F12 Updates 4.4.0-1.fc12 ...so if someone tries to update from F11 (with updates) using an F12 GA release DVD, it'll be an older version and I very much doubt you've tested how well that works. Now sure, Fedora is forced to do this sometimes because we don't have the manpower to backport all fixes ... but there's a _big_ difference between being forced to do it some of the time and guaranteeing that the firehose breaks it _every_ release for _every_ user. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Fri, 2010-02-26 at 21:43 +0100, Till Maas wrote: On Fri, Feb 26, 2010 at 01:16:43PM +0100, Kevin Kofler wrote: I would like to collect feedback on this issue. If you want to disable direct stable pushes, why? Could there be a less radical solution to that problem (e.g. a policy discouraging direct stable pushes for some specific types of changes rather than a blanket ban)? On the other hand, if (like me) you DON'T want that feature to go away, please provide valid use cases. I just have another idea: Add the karma value to the repository metadata and write a yum plugin to only install packages with a certain amount of karma. This sucks for a few reasons: 1. Any kind of large and complex excluding done client side performs horribly. 2. Not enough people use +karma, as against opening BZs. 3. Even if we could deal with both of the above, you'd now have the problem that good updates will be replaced by bad updates as soon as they are pushed. 4. Also having the process be you must do X if you want only good updates as against you must do X if you want more, less tested, updates is backwards for a stable release. ...and as in all threads about this that I can remember, the obvious fix to the above is having two repos. and let everyone who wants a giant firehose of mostly working stuff can enable this second repo. if only we could create this testing of the updates repo. surely everyone would be happy. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Fri, 2010-02-26 at 22:51 +0100, Kevin Kofler wrote: Jesse Keating wrote: On Fri, 2010-02-26 at 16:17 +0100, Kevin Kofler wrote: Most often what works on Fedora n also works on Fedora m. It's not like the reviewer tested on Slackware or OS X. ;-) Most often. Sure, that seems good enough to throw potential crap at users. Our os most often works. Don't worry about those times it doesn't. I only know of a single instance where it didn't in an update I pushed Are you really arguing that you never make mistakes? You are some God like super being who we should all bow down to? Of course if you were such a genius, I can't see why you'd need to do updates at all. Or at the very least getting some of your followers to praise your releases enough to speed them to stable. Or to put it another way, I assume you've read Paul Wouters's excellent post in this thread ... so are you arguing that he's just stupid? Or maybe that he didn't care? Because it sure looked like he cared, and that he knew what he was doing, and that he wasn't planning to intentionally break users systems, and that he hadn't made a lot of mistakes before ... but still pushing to stable with only the developers testing it wasn't such a good idea. Probably the saddest thing about this giant flamewar you've started is that you feel so persecuted by such tiny proposed changes ... certainly if I was god I'd _happily_ ban any non-high-security updates for over a month without even thinking about it (rawhide is = that way, have fun IMNSHO). And that's just from my users perspective, I'm sure I'd bring the smackdown much harder if I had to wade through the $...@! that rel-eng does. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
