Re: Adventurous yet Safety-Minded
On Wed, Mar 10, 2010 at 1:54 PM, Alexander Kahl e-u...@fsfe.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/10/2010 01:06 PM, Steven I Usdansky wrote: There is no real recovery for traditional package systems as each change on a package (install, update, remove etc.) changes the state of the system as a whole, i.e. the system relies on side effects (mostly writing files into shared/global locations) and provides no referential transparency for such actions, same output for same input is never guaranteed. My (silly perhaps) personal opinion that the rollback part of a package management system depends very much on QA which are made the same packages in first place. The way you write seems that the problem is insoluble for a package manager: if so it did seem strange that several rpm developers have lost so time to implement it in the first place and to extend it over time. But I think this has already been discussed in the past, many time. For example http://lists.rpm.org/pipermail/rpm-maint/2008-February/001912.html and http://lists.rpm.org/pipermail/rpm-list/2009-April/000227.html http://lists.rpm.org/pipermail/rpm-list/2009-April/000231.html But the problem is always relevant http://www.mancoosi.org/work/#wp3 Regards -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expect more positive bodhi karma / check karma automatism
On Wed, Mar 10, 2010 at 04:51:34PM -0700, Stephen John Smoogen wrote: The biggest query command I would like at the moment is something like: fedora-easy-karma --list # lists packages to be voted on. fedora-easy-karma --list-new # list pacakges I haven't voted on already. fedora-easy-karma by default already skips updates, that you already commented on, this can be disabled with --include-commented. So would it be enough, if there is an option --list-only, that skips the questions whether or not to comment, but only displays the update descriptions? Regards Till pgp1csMCs0eSv.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Java package maintainers, please, add missing requires to your packages.
Hello All!
Recently I (re)started to package some big java application, and as
one of side effect of this work, I take a closer look on current state
of java packages in Fedora and I was disappointed with what I saw
here.
Quick summary - many java packages does not obey Fedora Packaging
Guidelines in case of owning a directories, already owned by other
packages.
As a result - some packages owns %{_javadir}, some - %{_javadocdir},
some - own directories with maven-related stuff. This mess must be
fixed!
Please, take a closer look at your spec-files and
a) Add Requires jpackage-utils to main package's header if your
package stores something in %{_javadir}
b) Add Requires jpackage-utils to *-javadoc subpackage's header if you
store something in %{_javadocdir}
c) Do NOT own %{_javadir} - e.g. do NOT list bare directory
%{_javadir} in %files section. Instead use something like
%{_javadir}/*
d) The same rule applies for /usr/share/maven2, /etc/maven/fragments (
%{_mavendepmapfragdir} ) and /usr/share/maven2/poms ( %{_mavenpomdir}
) and other - these two already owned by jpackage-utils.
e) Check for other directories, already owned by other packages. Foe
example, take a look at the rpm -ql jpackage-utils and you'll see
the list of directories, owned by this package - these directories can
NOT be owned by other packages. Add proper Requires instead.
I already fixed some packages, byt there are lots of them remaining.
For example, very often people forgot to add Requires:
jpackage-utils to *-javadoc.
Please, do NOT fix packages ONLY in Rawhide (as some of us do usually)
- proposed fixes doesn't ruin ABI or API compatibility, and should be
applied in every active branch.
Please, keep in mind that adding Requires(post) and Requires(postun)
is not the same as adding Requires. One could easily remove packages,
listed in Requires(post|postun), and your package should work and
whole filesystem tree should remain consistent (I mean every directory
should have their respective owner). Thus, enlisting jpackage-utils in
Requires(post) only is not enough if you store something in
%{_javadir}.
Thank you for your attention!
--
With best regards, Peter Lemenkov.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
On Wed, 2010-03-10 at 19:11 -0800, John Reiser wrote: MultiGHz, Multicore CPUs consume magnitudes more power than HDs. Not always. A typical 3.5 harddrive consumes about (max): 0.65A * 5V = 3.25W 0.50A * 12V = 6.00W which totals 9.25 Watts, and less when not transferring data. I am composing this message on a system with a 2.5GHz, two-core processor that consumes 45 Watts maximum, and less when idle. So in this case the ratio is closer to 5:1, not 10:1. That doesn't compare to figures that I have seen - a lot of 7200rpm hard disks will draw up to a couple of amps on the 12v line (at least, during startup) giving you peak power consumption in the 20-30W range. The lastest data sheets I can find for Seagate's Baracuda 7200 drives for e.g. quote a maximum draw of 2.8A (33.6W). Admittedly that's a peak value and not an average but so is the 45W processor figure; I think claiming that modern CPUs consume magnitues more power than modern hard disks is not justifiable. Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
On Wed, Mar 10, 2010 at 08:33:16PM -0500, Felix Miata wrote: On 2010/03/10 20:19 (GMT-0500) Ric Wheeler composed: And power consumption will go down as you won't need as many platters :-) Not materially for those whose needs are already down to less than one platter. MultiGHz, Multicore CPUs consume magnitudes more power than HDs. There are also a lot of low-power systems that use a HD, e.g. tv recorders or home entertainment systems. Also if you use some of the recently available ARM base plug computers, the power consumption of one HD makes a lot of difference compared to the remaining system. E.g. a SheevaPlug[0] consumes 2.3W in idle mode or 7W with full CPU according to wikipedia and running Fedora on it is supported within the secondary archs project. Regards Till [0] http://en.wikipedia.org/wiki/SheevaPlug pgp6lvw9oKhw9.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-RRD-Simple/devel perl-RRD-Simple.spec, 1.14, 1.15 RRD-Simple-1.44-pod.patch, 1.1, NONE
Author: pghmcfc
Update of /cvs/pkgs/rpms/perl-RRD-Simple/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv18421
Modified Files:
perl-RRD-Simple.spec
Removed Files:
RRD-Simple-1.44-pod.patch
Log Message:
Drop POD patch, only needed with Test::Pod 1.40
Index: perl-RRD-Simple.spec
===
RCS file: /cvs/pkgs/rpms/perl-RRD-Simple/devel/perl-RRD-Simple.spec,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -p -r1.14 -r1.15
--- perl-RRD-Simple.spec3 Mar 2010 14:05:01 - 1.14
+++ perl-RRD-Simple.spec11 Mar 2010 10:49:30 - 1.15
@@ -1,12 +1,11 @@
Name: perl-RRD-Simple
Version: 1.44
-Release: 5%{?dist}
+Release: 6%{?dist}
Summary: Simple interface to create and store data in RRD files
Group: Development/Libraries
License: ASL 2.0
URL: http://search.cpan.org/dist/RRD-Simple
Source0:
http://search.cpan.org/CPAN/authors/id/N/NI/NICOLAW/RRD-Simple-%{version}.tar.gz
-Patch0:RRD-Simple-1.44-pod.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(Module::Build)
@@ -31,9 +30,6 @@ if you do not need to, nor want to, both
%prep
%setup -q -n RRD-Simple-%{version}
-# Fix broken POD (CPAN RT#50868)
-%patch0 -p1
-
# Don't want provides/requires from %{_docdir}
%global docfilt %{__perl} -p -e 's|%{_docdir}/%{name}-%{version}\\S+||'
# RRD::Simple version should be from distribution version, not svn revision
@@ -72,6 +68,9 @@ LC_ALL=C ./Build test
%{_mandir}/man3/RRD::Simple::Examples.3pm*
%changelog
+* Thu Mar 11 2010 Paul Howarth p...@city-fan.org - 1.44-6
+- Drop POD patch, only needed with Test::Pod 1.40
+
* Wed Mar 3 2010 Paul Howarth p...@city-fan.org - 1.44-5
- Change buildreq perl(Test::Deep) to a build conflict until upstream fixes
failing t/32exported_function_interface.t (#464964, CPAN RT#46193)
--- RRD-Simple-1.44-pod.patch DELETED ---
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Adventurous yet Safety-Minded
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/11/2010 09:24 AM, yersinia wrote:
On Wed, Mar 10, 2010 at 1:54 PM, Alexander Kahl e-u...@fsfe.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/10/2010 01:06 PM, Steven I Usdansky wrote:
There is no real recovery for traditional package systems as each change
on a package (install, update, remove etc.) changes the state of the
system as a whole, i.e. the system relies on side effects (mostly
writing files into shared/global locations) and provides no referential
transparency for such actions, same output for same input is never
guaranteed.
My (silly perhaps) personal opinion that the rollback part of a package
management system depends very much on QA which are made the same packages
in first place. The way you write seems that the problem is insoluble for a
package manager: if so it did seem strange that several rpm developers have
lost so time to implement it in the first place and to extend it over time.
Because they've never seemed to question the foundations of a system
that relies on global state made up by interdependence between packages
during and after build and install time. What we have now is basically
an automaton that works deterministic in theory but is unpredictable in
practice. Using a mechanism like filesystem snapshots could enable real
rollbacks to a state that did actually exist but will make you lose
every other change happened in the meantime which might not be what you
want. Implementing and using RPM rollbacks, including filesystem-level
rollbacks or not, is like guessing a lost (full rollback of all
actions) or new (partly rollback, some actions) state by interpolating
stuff, like rollback of B after installation of {A,B,C} at state `e'
could yield a state approximate to the one after installation of {A,C}
at state `e'. This can turn out as a lucky day in Las Vegas at best.
Running C after B has been installed could have modified files belonging
to A or C, installation of C might behave different if B was installed
during %post (currently we work around the latter case by always
requiring all otherwise optional dependencies being present).
Better but still not perfect would be filesystem rollback to `e',
installation of {A,C} to get the real desired state without B.
There are of course cases where package maintainer work and QA can
improve rollback quality:
Imagine mysql-server would run an unconditional database format upgrade
upon update in %post (which it luckily doesn't!) ruining your day after
an RPM rollback. Here, the maintainers could increase the atomicity of
the package by creating a snapshot of the currently running database(s),
upgrading the snapshot and storing the old data to an offside storage
that is brought back into place upon rollback.
To my knowledge right now though, we neither have a mechanism to help
with that nor any guideline encouraging such behavior. Same goes for
configuration files with something better than those lame .rpm{save,new}
backup files.
But I think this has already been discussed in the past, many time. For
example http://lists.rpm.org/pipermail/rpm-maint/2008-February/001912.html
Quoting from that post:
- Most scriptlets in RedHat packages are fairly simple so their
typically is nothing to really undo.
But if they're not simple (which is the case too often), the user is
screwed.
- In house scriptlets were always written with the view that they
were going to be in rolled back so we made them work.
In house scriptlets, yeah, but we're a community with many contributors.
And there *are* update scriptlets as noted above without proper offside
storage and rollbacks for that.
- Often we could work around an upstream scriptlets issuses in
rollback via some other rpm, or some code external to rpm.
Which will, with current technology in place, again give an
unpredictable state `e3' instead of install (e, {A,C}) - e2.
...
That said it will never be as reliable and simple as a rollback of a
filesystem snapshot (however that is implemented). OTOH, that solution
is outside the rpm problem space.
But it's in scope of the packaging and filesystem layout spaces, read on.
and
http://lists.rpm.org/pipermail/rpm-list/2009-April/000227.html
Quoting again:
The problem with rollback is that scripts with in the rpm can execute
arbitrary shell commands.
Correct.
This means that RPM cannot foresee which files are
affected by a package and therefore cannot backup all files.
Correct, we're doing changes without properly recording former state.
http://lists.rpm.org/pipermail/rpm-list/2009-April/000231.html
Is it a implementation problem - difficult, sure, no dubt - or a
universal law ? I think the first but JMHO.
No, it's a logical problem of global state and referential transparency.
There are several scopes of this where rolling back is affected, most of
the actually covered and solved by Nix in elegant ways:
- - Non-atomic, global state of the
Re: To semi-rolling or not to semi-rolling, that is the question...
On 09/03/10 19:06, Doug Ledford wrote: On 03/09/2010 11:45 AM, Kevin Kofler wrote: Jesse Keating wrote: Slight variation on this. All builds from devel/ (or master in the new git world) would go to the koji tag dist-rawhide-candidate. Builds which are tagged with dist-rawhide-candidate trigger AutoQA tests, of the nature rawhide acceptance (this would have to get fleshed out at some point, but it'd be something that builds upon the tests we would already do post-build). Builds that pass rawhide acceptance would get tagged into dist-rawhide, would show up in the build roots, and would be part of the nightly rawhide compose. Builds that do not remain in dist-rawhide-candidate. A maintainer can review the failed cases and make a decision, override the system or do a new build. Egregious use of system overriding would trigger FESCo attention and perhaps some sort of retraining or sanctioning. The assumption is that automated QA catches all possible breakage, which is not true. In fact *no* QA will catch all the Rawhide breakage as some is caused by the mere fact of things being different, which is intentional and part of what Rawhide is about (e.g. the libata change in the kernel, the change from KDE 3 to 4 etc.). Releases are needed to handle this kind of changes in a smooth way. But automated QA will also miss many actual bugs. Things like the libata kernel change and KDE 3 to 4 migration are intentional events and all that's needed to make the transition smooth is to coordinate the release of a seamless upgrade package set. You make it sound like these things are impossible when nothing could be further from the truth. And it's expected that a responsible maintainer is aware of these sorts of intentional update events and all that needs to be done is for them to conscientiously build their packages into the rawhide-candidate dist repo and coordinate a release of a complete set of packages. Automated QA need not catch this type of event. And automated QA *will* catch many more bugs than it misses (speaking from the mouth of experience knowing all the automated QA checks my rhel packages must pass prior to each update), and there was never an assumption that it would catch *all* issues. In fact the suggestion that automated QA would need to catch *all* issues before the proposal meets your approval makes it very apparent how disingenuous your stance on this proposal is. FACT: the semi-rolling update model you so love today is not foolproof and does not keep users from experiencing periodic, occasional breakage (see KDE update thread). FACT: you are strongly in support of the current semi-rolling model that you practice today (see multiple threads). FACT: you have purported that even with things occasionally breaking as they did on the recent KDE update, that these things are impossible to prevent 100% and that the system is working as designed (see KDE thread). So, for you to say this automated QA wouldn't catch *all* issues and therefore this proposal is unworkable, and then on the other hand say that major updates in RELEASED products that cause breakage are OK and working as designed puts your hypocrisy very much in the spotlight. A consumable rawhide need only meet the level that our released products do today (a level that you personally have helped to drag down BTW) and at that point you have *NO* valid grounds to object to it. And if we made rawhide meet that level of consumability, we should at the same time be *raising* the bar for our released products. Your argument appears to be that since we can't make rawhide meet what should possibly be the raised bar of the released products then the idea won't work so lets lower the bar across the board and give up. I'm sorry Kevin, but you and I will simply have to agree to disagree. I will *not* capitulate to your stance on this issue. god you don't half talk a lot of nonsense! if you want another ubuntu go work for canonical and be done with it, fedora is great the way it is, and if you asked your users instead of assuming you know what they want you will find this out! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Install fedora-easy-karma by default? (was: Re: Expect more positive bodhi karma / check karma automatism)
On Wed, Mar 10, 2010 at 7:36 PM, Bill Nottingham nott...@redhat.com wrote: Till Maas (opensou...@till.name) said: Also thanks for packaging that immediately -- what about installing it by default? It's a tiny package and we really do want our users to provide feedback. I do not mind, if it is installed by default, but I am not sure, whether this is a good idea. Users will still need a FAS account, install packages from updates-testing and know that it exist to use it. Given that it at the moment requires a FAS account, perhaps having it as default in the Fedora packager group is a good first step. Hey, why don't we register for FAS accounts with firstboot? Good idea. We could also register FAS accounts within the Fedora-Tour once it's ready. I think it would be a good place with lots of space to explain the user what benefits a FAS account has. -- LG Thomas Dubium sapientiae initium -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: QA's Package update policy proposal
On Wednesday, March 10, 2010, 7:11:31 PM, Kevin Kofler wrote: Al Dunsmuir wrote: The update to an older stable release should be made widely available in that release's updates-testing after the equivalent (not necessarily identical) fix has been widely tested in the latest stable release. Uh, no, just no. They should go to updates-testing for both releases at the same time. Anything else: 1. makes things harder for the maintainer, as he/she has to go through all the Bodhi procedures twice, 2. just delays the fix for users for no good reason. I can somewhat understand the argument that they should get separate testing (even though I disagree with it), or even that the stable pushes should be staged (even though I also disagree with that), but I really don't see what it hurts to have the update available in updates-testing right away. Testing is what updates-testing is for. A lot of the conflict that I am seeing is based on two different basic assumptions: 1) the update will be good and 2) the update will fail. It is OK after sufficient unit testing to go with approach #1 on the latest release. If it turns out there are problems, they can be fixed in one or more additional iterations. For older releases, the presumption/requirement for stability is higher. To meet that, I believe more people would prefer going with approach #2 for these releases. Once the update works out OK with no regressions in the latest release, you have a much higher probability that your the equivalent update to the older release will also be stable and meet that release's stability requirement. Throwing both into their respective updates-testing simultaneously does allow for wider user testing... but is limited by the actual amount of testing. Allowing both releases to be promoted to stable at the same time is the real problem. If you do not (or can not) hold back the older (and in user expectations, more stable) release update than any problem will have a much higher perceived and actual impact. If you don't have the resources to ensure that older releases remain more stable than newer releases, perhaps you do need to revisit whether updates to both releases are a good idea. This minimizes the risk that due to a different execution environment, build environment, configuration or whatever the seemingly equivalent fix does not work but causes a regression. You may start at the same place in the older stable release, but may end up down and entirely different rabbit hole. Is this really such a common issue that it makes it worth delaying all updates, including bugfixes, while waiting for testing that may never arrive (because those folks who like testing things tend to run the current stuff)? Kevin Kofler Problems will happen, likely in the worst possible way at the worst possible time for your users. If you work on that assumption, it just makes sense to take more care and time to roll out your fixes the more stable the release is expected to be. If you and the users have a mismatch regarding expectations of stability, it doesn't matter whether your changes are fixes or retrofitted enhancement - there will be highly visible problem if you try to cut corners in either time or effort. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PROPOSAL: Fedora user survey
On 09/03/10 05:05, Seth Vidal wrote: On Mon, 8 Mar 2010, Jon Masters wrote: Folks, I will propose this to FESCo through their normal channels. My proposal is that we create a Fedora User Survey and create a link on the fp.o website with a few very simple questions. One of those questions would be what users think about the current update policy, using plain (and as non-bias as possible) language to explain. This isn't an attempt to undermine FESCo, but you have to remember that users don't typically directly vote for FESCo or otherwise get involved in big decisions like this that will affect them. The developers do this, and we are motivated by our own experiences. While I'm not looking to create another California referendum process for Fedora, I do think occasional (maybe annual) surveys for user input would be useful. -1 It sure looks like a californian referendum process. Let me make this abundantly clear: I have ZERO interest in developing a distro which is driven by mob vote of whomever happens to be on the internet. -sv jeez now who's taking his ball home and not playing :O -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PROPOSAL: Fedora user survey
On Tue, Mar 9, 2010 at 6:05 AM, Seth Vidal skvi...@fedoraproject.orgwrote: On Mon, 8 Mar 2010, Jon Masters wrote: Folks, I will propose this to FESCo through their normal channels. -1 It sure looks like a californian referendum process. Let me make this abundantly clear: I have ZERO interest in developing a distro which is driven by mob vote of whomever happens to be on the internet. There are also other opinion https://wiki.ubuntu.com/ServerTeam/Survey/Launch -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Suggestions (how to choose mirrors)
On 01/27/2010 08:12 PM, James Antill wrote: On Wed, 2010-01-27 at 10:50 +0100, Roberto Ragusa wrote: If the downloads are sorted by increasing size, you basically use the small ones to sample the mirrors and make a good choice for the big ones at the end of the list. Except we got significant complaints when we did that sort, so I'm not dying to do it again (even though I did it, and thought it was better). yum install yum-plugin-download-order Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
What happened to mercurial-1.5-2.fc11?
fc13 and fc12 are shown here:
https://admin.fedoraproject.org/updates/search/mercurial?_csrf_token=9d135a7a59b1892cc911a5f075633fb7dd4ef993
But not fc11. So I tried to rebuild, and got:
2046149 build (dist-f11-updates-candidate,
/cvs/pkgs:rpms/mercurial/F-11:mercurial-1_5-2_fc11): open
(ppc03.phx2.fedoraproject.org) - FAILED: GenericError: Build already exists
(id=160549, state=COMPLETE): {'name': 'mercurial', 'task_id': 2046149,
'pkg_id': 2518, 'epoch': None, 'completion_time': None, 'state': 0,
'version': '1.5', 'owner': 286, 'release': '2.fc11', 'id': 160549}
0 free 0 open 1 done 1 failed
OK, then where is it?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: QA's Package update policy proposal
Al Dunsmuir wrote: For older releases, the presumption/requirement for stability is higher. Nonsense. The previous and current stable releases are both equally supported, there isn't one which is more stable than the other. If you don't have the resources to ensure that older releases remain more stable than newer releases, perhaps you do need to revisit whether updates to both releases are a good idea. The goal of continuing to maintain the previous stable release is NOT to have a more conservative release available, but simply to allow users to pick their own time for upgrading to the new release due to the disruptive changes made between the old and the new release (i.e. those changes which are intentionally NOT being pushed as updates, e.g. because they remove features, require manual configuration changes or whatever reason). In fact, the EOL time is chosen such that users can opt to skip a release entirely. This doesn't mean that those users do not expect to get the same kind of updates the current stable release gets (i.e. non-disruptive, but not particularly conservative updates). In fact it's quite the opposite, as a user I expect the release to be supported equally throughout its lifetime. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adventurous yet Safety-Minded
Alexander Kahl wrote: On 03/10/2010 08:26 PM, Steven I Usdansky wrote: If there's a magic solution that will satisfy the vast majority of Fedora users, I have absolutely no clue as to what it might be. Please read: http://nixos.org/nix/ Esp. Atomic upgrades and rollbacks That's not a solution for Fedora at all. It's a completely different package manager (competing with RPM). It also works by keeping all the old versions of all packages stored on disk all the time, a massive waste of disk space, and also not compliant with the FHS (Filesystem Hierarchy Standard). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adventurous yet Safety-Minded
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/11/2010 02:16 PM, Kevin Kofler wrote: Alexander Kahl wrote: On 03/10/2010 08:26 PM, Steven I Usdansky wrote: If there's a magic solution that will satisfy the vast majority of Fedora users, I have absolutely no clue as to what it might be. Please read: http://nixos.org/nix/ Esp. Atomic upgrades and rollbacks That's not a solution for Fedora at all. It's a completely different package manager (competing with RPM). Well, now that you mention it..! ;) It also works by keeping all the old versions of all packages stored on disk all the time, a massive waste of disk space, Please define massive if you're keeping exactly what's needed to keep everything running and prune anything else by using a sophisticated, tunable garbage collection mechanism. and also not compliant with the FHS (Filesystem Hierarchy Standard). Yep. It's much better, comparable to the GAC (global assembly cache) of the CLR (Mono), just applied as a packaging / filesystem layout paradigm for the whole system. Please read my other post in reply to yersinia - sorry, this thread is cluttered, bad MUAs. - -- Alexander Kahl GNU/Linux Software Developer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkuY70YACgkQVTRddCFHw12oiACgqZp+94Q6rUQM2jAaKzWfobP8 oOgAoKTV9OurZ8oBq1pwn2oniZFXPOeC =GsWd -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: QA's Package update policy proposal
Hello Kevin, Thursday, March 11, 2010, 8:09:02 AM, you wrote: Al Dunsmuir wrote: For older releases, the presumption/requirement for stability is higher. Nonsense. The previous and current stable releases are both equally supported, there isn't one which is more stable than the other. Often the reason that folks are using an older stable release because they *can not* update to the new stable release because it doesn't work for them, or they *choose* to wait until the new release is *proven* stable. If you ignore that and assume you are free to do as you will to any active release, I would submit you are putting your own wants ahead of your users. Everyone loses in that case, and it is quite natural that conflict arises. Simultaneously updating all active releases is like climbing a mountain without safety ropes. It works fine while everything goes well, but the first slip means you are in for a big fall. Maintaining the older releases with a heightened emphasis on stability is Fedora's safety rope. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
POSTUN scriptlet failure in rpm package cyrus-sasl
Saw this in today's updates: Cleanup: cyrus-sasl-2.1.23-4.fc12.i686 195/254 groupdel: group 'saslauth' does not exist Non-fatal POSTUN scriptlet failure in rpm package cyrus-sasl warning: %postun(cyrus-sasl-2.1.23-4.fc12.i686) scriptlet failed, exit status 6 This looks benign, but I suppose it could check if the group exists before attempting to delete it. -- Mat Booth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What happened to mercurial-1.5-2.fc11?
Neal Becker wrote, at 03/11/2010 09:52 PM +9:00:
fc13 and fc12 are shown here:
https://admin.fedoraproject.org/updates/search/mercurial?_csrf_token=9d135a7a59b1892cc911a5f075633fb7dd4ef993
But not fc11. So I tried to rebuild, and got:
2046149 build (dist-f11-updates-candidate,
/cvs/pkgs:rpms/mercurial/F-11:mercurial-1_5-2_fc11): open
(ppc03.phx2.fedoraproject.org) - FAILED: GenericError: Build already exists
(id=160549, state=COMPLETE): {'name': 'mercurial', 'task_id': 2046149,
'pkg_id': 2518, 'epoch': None, 'completion_time': None, 'state': 0,
'version': '1.5', 'owner': 286, 'release': '2.fc11', 'id': 160549}
0 free 0 open 1 done 1 failed
OK, then where is it?
It seems that you solved this issue by yourself now (I guess
you just forgot to submit push request before).
Mamoru
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adventurous yet Safety-Minded
On Thu, 2010-03-11 at 11:53 +0100, Alexander Kahl wrote: Most of what is described here is already covered by Nix (leaving out the hardware driver part). This is why I endorse dumping yum, RPM *and* the stupid FHS in favor of Nix, focusing all development on something that is clearly superior by substantiating the synthesis of DOS (*cough*) and POSIX style installations: Minimal redundancy, maximum compatibility, (mostly) predictable rollbacks, atomicity, referential transparency: Purely functional package management. Oh, and by the way, we could leave behind all those discussions regarding dynamic linking: RPATH for everything and everyone. If you've linked against libfoo-4.2-2 during build time, libfoo-4.2-2 will be present during runtime, same location, same file. Period. :) I'm sorry for not studying the Nix concepts in depth, but can you please answer me just a simple question how security or other critical bugfixes _in libraries_ are handled under this RPATH for everything paradigm? -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: POSTUN scriptlet failure in rpm package cyrus-sasl
n Thu, Mar 11, 2010 at 2:52 PM, Mat Booth fed...@matbooth.co.uk wrote: Saw this in today's updates: Cleanup: cyrus-sasl-2.1.23-4.fc12.i686 195/254 groupdel: group 'saslauth' does not exist Already fixed -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adventurous yet Safety-Minded
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/11/2010 03:05 PM, Tomas Mraz wrote: On Thu, 2010-03-11 at 11:53 +0100, Alexander Kahl wrote: Oh, and by the way, we could leave behind all those discussions regarding dynamic linking: RPATH for everything and everyone. If you've linked against libfoo-4.2-2 during build time, libfoo-4.2-2 will be present during runtime, same location, same file. Period. :) I'm sorry for not studying the Nix concepts in depth, but can you please answer me just a simple question how security or other critical bugfixes _in libraries_ are handled under this RPATH for everything paradigm? Yep: Nix is a mixed source/binary distro, as far as I understand the documentation, stuff gets (re)build locally when necessary; furthermore Nix uses PatchELF: http://nixos.org/patchelf.html I've been running NixOS in a VM for a while and created Nix RPMs for Fedora (unreleased though) to investigate and understand the system better. Furthermore the system heavily relies on automated testing and nightly builds before pushing out anything anywhere. - -- Alexander Kahl GNU/Linux Software Developer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkuZBMEACgkQVTRddCFHw12SoACePlZeFvrG/SVpgeFN/E2Uf1Be BM0AoKHYEcAVrNch5MisXtK4LbeS7Vkb =nSwo -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: POSTUN scriptlet failure in rpm package cyrus-sasl
On Thu, Mar 11, 2010 at 02:31:43PM -, Quentin Armitage wrote: See https://bugzilla.redhat.com/show_bug.cgi?id=572399 groupdel: group 'saslauth' does not exist Non-fatal POSTUN scriptlet failure in rpm package cyrus-sasl warning: %postun(cyrus-sasl-2.1.23-4.fc12.i686) scriptlet failed, exit status 6 This looks benign, but I suppose it could check if the group exists before attempting to delete it. There's actually a not so benign side of this. Here's what the Guidelines say about removing groups: We never remove users or groups created by packages. There's no sane way to check if files owned by those users/groups are left behind (and even if there would, what would we do to them?), and leaving those behind with ownerships pointing to now nonexistent users/groups may result in security issues when a semantically unrelated user/group is created later and reuses the UID/GID. Also, in some setups deleting the user/group might not be possible or/nor desirable (eg. when using a shared remote user/group database). Cleanup of unused users/groups is left to the system administrators to take care of if they so desire. https://fedoraproject.org/wiki/Packaging:UsersAndGroups I've updated bugzilla with this information as well. -Toshoi pgpCosn5zBJO0.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: POSTUN scriptlet failure in rpm package cyrus-sasl
On Thu, 2010-03-11 at 10:04 -0500, Toshio Kuratomi wrote: On Thu, Mar 11, 2010 at 02:31:43PM -, Quentin Armitage wrote: See https://bugzilla.redhat.com/show_bug.cgi?id=572399 groupdel: group 'saslauth' does not exist Non-fatal POSTUN scriptlet failure in rpm package cyrus-sasl warning: %postun(cyrus-sasl-2.1.23-4.fc12.i686) scriptlet failed, exit status 6 This looks benign, but I suppose it could check if the group exists before attempting to delete it. There's actually a not so benign side of this. Here's what the Guidelines say about removing groups: We never remove users or groups created by packages. There's no sane way to check if files owned by those users/groups are left behind (and even if there would, what would we do to them?), and leaving those behind with ownerships pointing to now nonexistent users/groups may result in security issues when a semantically unrelated user/group is created later and reuses the UID/GID. Also, in some setups deleting the user/group might not be possible or/nor desirable (eg. when using a shared remote user/group database). Cleanup of unused users/groups is left to the system administrators to take care of if they so desire. https://fedoraproject.org/wiki/Packaging:UsersAndGroups I've updated bugzilla with this information as well. Someone should perhaps correct the http://fedoraproject.org/wiki/PackageUserCreation then. Or add some rules on how to resolve conflicts among the current rules. (I'm joking.) -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Example of karma not being functional [Was:POSTUN scriptlet failure in rpm package cyrus-sasl]
On 03/11/2010 02:52 PM, Mat Booth wrote: Saw this in today's updates: Cleanup: cyrus-sasl-2.1.23-4.fc12.i686 195/254 groupdel: group 'saslauth' does not exist Non-fatal POSTUN scriptlet failure in rpm package cyrus-sasl warning: %postun(cyrus-sasl-2.1.23-4.fc12.i686) scriptlet failed, exit status 6 This case is a nice example demonstrating several defects in applying karma votes for QA: 1. The update package was sitting in updates-testing since 2010-02-22. 2. It did receive +3 karma points before being pushed to updates c.f. https://admin.fedoraproject.org/updates/cyrus-sasl-2.1.23-6.fc12 = There are people who claim to have tested it and not having noticed anything unusual. 3. During today's update I was immediately greeted by the same error message Mat cites above and BZ'ed it. c.f. https://bugzilla.redhat.com/show_bug.cgi?id=572399 4. Despite the fact this package had been pushed to updates, I had been able to cast a karma vote on the package in bodhi. c.f. https://admin.fedoraproject.org/updates/cyrus-sasl-2.1.23-6.fc12 = A malfunction in bodhi 5. Unlike in many other similar cases before, the packager responded almost immediately and tried to provide an updated package (Thanks!). However, due to the fact update-candidates are not immediately pushed to updates-testing, this package is not available in updates-testing. = karma voting on packages in updates-testing is not applicable in situations like these (being directly affect by a bug, the bug still being hot) Seemingly, other people who were affected by this bug did pick up the package from other sources (Most probably directly from bodhi) and provided feedback through BZ c.f. https://bugzilla.redhat.com/show_bug.cgi?id=572399 Think about it, FESCO! Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: POSTUN scriptlet failure in rpm package cyrus-sasl
On Thu, Mar 11, 2010 at 04:35:13PM +0100, Tomas Mraz wrote: On Thu, 2010-03-11 at 10:04 -0500, Toshio Kuratomi wrote: We never remove users or groups created by packages. There's no sane way to check if files owned by those users/groups are left behind (and even if there would, what would we do to them?), and leaving those behind with ownerships pointing to now nonexistent users/groups may result in security issues when a semantically unrelated user/group is created later and reuses the UID/GID. Also, in some setups deleting the user/group might not be possible or/nor desirable (eg. when using a shared remote user/group database). Cleanup of unused users/groups is left to the system administrators to take care of if they so desire. https://fedoraproject.org/wiki/Packaging:UsersAndGroups I've updated bugzilla with this information as well. Someone should perhaps correct the http://fedoraproject.org/wiki/PackageUserCreation then. Or add some rules on how to resolve conflicts among the current rules. (I'm joking.) So this is interesting. That page is not a Packaging Guideline. You can tell because it's not Packaging:UserCreation. The FPC is aware that the page exists but pretty much left it alone as it documents a program, fedora-usermgmt, that Enrico Scholz wrote to solve issues with user creation in the way that he thought best. However, if it's causing confusion we should definitely make some sort of change. What should that be? Options: * Put a large admonition at the top that says I am not a Packaging Guideline and point to the packaging guideline page for user creation. * Remove the page * Have the FPC vote whether use of fedora-usermgmt is disallowed and remove the page if so * Rename the page * Someone works on the text of the page to make it clear that it's only documenting the fedora-usermgmt application, not something written into the packaging guidelines. * Update the page to remove the userdel and groupdel portions. What combination of the above seems most suitable to people? -Toshio pgp28bLJFomrr.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100311 changes
Compose started at Thu Mar 11 08:15:14 UTC 2010 Broken deps for i386 -- accountsdialog-0.5.1-1.fc14.i686 requires libcheese-gtk.so.17 calibre-0.6.42-1.fc14.i686 requires libMagickCore.so.2 calibre-0.6.42-1.fc14.i686 requires libMagickWand.so.2 drawtiming-0.7.1-1.fc13.i686 requires libMagick++.so.2 drawtiming-0.7.1-1.fc13.i686 requires libMagickCore.so.2 easystroke-0.5.2-1.fc13.i686 requires libboost_serialization-mt.so.5 emotion-0.1.0.042-5.fc12.i686 requires libecore_job.so.0 emotion-0.1.0.042-5.fc12.i686 requires libevas.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_fb.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_x.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_evas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_txt.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_job.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libevas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_fb.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_imf_evas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libefreet.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_file.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libefreet_mime.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_imf.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_con.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_ipc.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libedbus.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libehal.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_x.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libedje.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_evas.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_ipc.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libevas.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_fb.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_file.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_con.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_x.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libedje.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_evas.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_ipc.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libevas.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_fb.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_file.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_con.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_x.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_evas.so.0 evolution-couchdb-0.3.2-2.fc13.i686 requires libcouchdb-glib-1.0.so.1 ewl-0.5.2.042-12.fc12.i686 requires libecore_txt.so.0 ewl-0.5.2.042-12.fc12.i686 requires libevas.so.0 ewl-0.5.2.042-12.fc12.i686 requires libecore.so.0 ewl-0.5.2.042-12.fc12.i686 requires libefreet.so.0 ewl-0.5.2.042-12.fc12.i686 requires libecore_file.so.0 ewl-0.5.2.042-12.fc12.i686 requires libefreet_mime.so.0 ewl-0.5.2.042-12.fc12.i686 requires libedje.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_txt.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libevas.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_file.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libedje.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_evas.so.0 hornsey-1.5.2-0.1.fc13.i686 requires libclutter-gst-0.10.so.0 inkscape-0.47-6.fc13.i686 requires libMagickCore.so.2 inkscape-0.47-6.fc13.i686 requires libMagick++.so.2 inkscape-view-0.47-6.fc13.i686 requires libMagick++.so.2 inkscape-view-0.47-6.fc13.i686 requires libMagickCore.so.2 1:libguestfs-1.0.85-2.fc14.i686 requires /lib/libntfs-3g.so.74 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 openvas-libnasl-2.0.2-3.fc13.i686 requires libopenvas_hg.so.2 openvas-libnasl-2.0.2-3.fc13.i686 requires libopenvas.so.2 paperbox-0.4.4-2.fc12.i686 requires libtrackerclient.so.0 php-pecl-imagick-2.2.2-4.fc12.i686 requires libMagickWand.so.2 php-pecl-imagick-2.2.2-4.fc12.i686 requires libMagickCore.so.2 pyclutter-gst-0.9.2-1.fc12.i686
Re: POSTUN scriptlet failure in rpm package cyrus-sasl
Toshio Kuratomi (a.bad...@gmail.com) said: The FPC is aware that the page exists but pretty much left it alone as it documents a program, fedora-usermgmt, that Enrico Scholz wrote to solve issues with user creation in the way that he thought best. However, if it's causing confusion we should definitely make some sort of change. What should that be? Options: * Put a large admonition at the top that says I am not a Packaging Guideline and point to the packaging guideline page for user creation. * Remove the page * Have the FPC vote whether use of fedora-usermgmt is disallowed and remove the page if so * Rename the page * Someone works on the text of the page to make it clear that it's only documenting the fedora-usermgmt application, not something written into the packaging guidelines. * Update the page to remove the userdel and groupdel portions. What combination of the above seems most suitable to people? The first item I think is the obvious change; the page can be renamed if people really find it's confusing. Putting fedora-usermgmt before FPC would be a separate item. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora::App::MaintainerTools 0.006
Hi Chris, funny I just bumped into your module while searching for a module that would abstract out the information from META.yml. Would you suggest to use the CPAN::MetaMuncher in your package or something else? In the former case would it be possible to put it in its own CPAN package? regards Gabor On Thu, Mar 11, 2010 at 8:43 AM, Chris Weyl cw...@alumni.drew.edu wrote: Hey all -- I just wanted to post a quick little update; I've pushed Fedora::App::MaintainerTools 0.006 to the CPAN. While there's still a significant amount to do before casual usage, I've been using this on a day-to-day basis to update specs, and functionality has been coming along nicely even if tests and documentation are sorely lacking. Recent changes include: 0.006 Wed Mar 10 2010 - we can now build new specs/srpms recursively! (And display them as a dep tree.) - Initial changes required to enable fully-managed spec mode have been committed, along with a helper command to make breaking out the custom sections (to auto.ini) easier. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: POSTUN scriptlet failure in rpm package cyrus-sasl
Tomas Mraz tm...@redhat.com writes: We never remove users or groups created by packages. Someone should perhaps correct the http://fedoraproject.org/wiki/PackageUserCreation then. fwiw, %__fe_userdel + %__fe_groupdel evaluate to a noop in rawhide (unless, '--with fedora_userdel' is set). Enrico -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-DBD-CSV/devel perl-DBD-CSV.spec,1.10,1.11
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-DBD-CSV/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv2708
Modified Files:
perl-DBD-CSV.spec
Log Message:
* Thu Mar 11 2010 Marcela Mašláňová mmasl...@redhat.com - 0.27-1
- update
- replace DESTDIR
Index: perl-DBD-CSV.spec
===
RCS file: /cvs/pkgs/rpms/perl-DBD-CSV/devel/perl-DBD-CSV.spec,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -p -r1.10 -r1.11
--- perl-DBD-CSV.spec 11 Mar 2010 13:35:56 - 1.10
+++ perl-DBD-CSV.spec 11 Mar 2010 16:49:02 - 1.11
@@ -15,6 +15,8 @@ BuildRequires: perl(DBD::File) = 0.30
BuildRequires: perl(SQL::Statement) = 0.1011
BuildRequires: perl(Text::CSV_XS) = 0.16
BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Harness)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
Requires: perl(SQL::Statement) = 0.1011
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 513596] perl-DBD-CSV-0.2002 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=513596 Marcela Mašláňová mmasl...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Resolution||RAWHIDE -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Push scripts, mash (was: Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback))
Kevin Kofler wrote: as long as you require only a few 32-bit packages, requesting them explicitly is not the end of the world. So if we were to drop support for that always install all libs as multilibs option Eh? I didn't even know there was such an option. And I agree, /that/ should be dropped. and require explicitly picking the wanted 32-bit stuff from the 32-bit repo, that shouldn't be a real issue for you. As long as I can still install libs to build i*86 on my mostly-x86_64 system, without yum getting confused and broken, then I'm okay. My concern is really just the yum getting confused and broken part. (I would prefer to not have to jump through hoops to get i*86 stuff, though, i.e. having to manually set up a repo would make me unhappy.) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Oops. -- Shannon Foraker (David Weber, Ashes of Victory) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Push scripts, mash (was: Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback))
On Thu, 11 Mar 2010, Matthew Woehlke wrote: Kevin Kofler wrote: as long as you require only a few 32-bit packages, requesting them explicitly is not the end of the world. So if we were to drop support for that always install all libs as multilibs option Eh? I didn't even know there was such an option. And I agree, /that/ should be dropped. man yum.conf; /multilib_policy it is set to best in fedora. and require explicitly picking the wanted 32-bit stuff from the 32-bit repo, that shouldn't be a real issue for you. As long as I can still install libs to build i*86 on my mostly-x86_64 system, without yum getting confused and broken, then I'm okay. My concern is really just the yum getting confused and broken part. (I would prefer to not have to jump through hoops to get i*86 stuff, though, i.e. having to manually set up a repo would make me unhappy.) the issue is not yum getting confused but really there being some interesting conflicting files.. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Install fedora-easy-karma by default?
Rahul Sundaram wrote: On 03/11/2010 02:14 AM, Matthew Woehlke wrote: Can you leave bodhi feedback with an FAS account if you haven't signed a CLA? (The thing about FAS accounts I am not crazy about is the CLA. What about using a bugzilla account instead?) What is the problem you have with the CLA? I tried to send you a reply, but it bounced; gmail says the address you gave does not exist. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Oops. -- Shannon Foraker (David Weber, Ashes of Victory) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
CLA problems (was: Re: Install fedora-easy-karma by default?)
On Thu, Mar 11, 2010 at 09:20:11AM +0530, Rahul Sundaram wrote: On 03/11/2010 02:14 AM, Matthew Woehlke wrote: Can you leave bodhi feedback with an FAS account if you haven't signed a CLA? (The thing about FAS accounts I am not crazy about is the CLA. What about using a bugzilla account instead?) What is the problem you have with the CLA? Imho it is to complex, which scares potential contributor away. Especially if only a comment and a karma value are required, the CLA is way to complex to require it. Regards Till pgpStmOHP9LdN.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: CLA problems (was: Re: Install fedora-easy-karma by default?)
On Thu, 11 Mar 2010, Till Maas wrote: On Thu, Mar 11, 2010 at 09:20:11AM +0530, Rahul Sundaram wrote: On 03/11/2010 02:14 AM, Matthew Woehlke wrote: Can you leave bodhi feedback with an FAS account if you haven't signed a CLA? (The thing about FAS accounts I am not crazy about is the CLA. What about using a bugzilla account instead?) What is the problem you have with the CLA? Imho it is to complex, which scares potential contributor away. Especially if only a comment and a karma value are required, the CLA is way to complex to require it. We don't require it though I thought? Can somone who has not signed the CLA confirm? -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Board Meeting Recap 2010-03-11
Forwarding to devel@, from advisory-bo...@. - Forwarded message from Matt Domsch m...@domsch.com - Date: Thu, 11 Mar 2010 12:03:05 -0600 From: Matt Domsch m...@domsch.com To: advisory-bo...@lists.fedoraproject.org Subject: Fedora Board Meeting Recap 2010-03-11 User-Agent: Mutt/1.5.20 (2009-08-17) https://fedoraproject.org/wiki/Meeting:Board_meeting_2010-03-11 == Roll Call == * Present: Matt Domsch, Paul Frields, John Poelstra, Mike McGrath, Colin Walters, Josh Boyer, Dennis Gilmore, Christopher Aillon, Chris Tyler, Tom spot Callaway * Assigned meeting secretary: Matt Domsch == Agenda == === Update policy === https://fedorahosted.org/board/ticket/58 * https://fedoraproject.org/wiki/Stable_release_updates_vision * QUESTION: Is there anyone on the Board who cannot support this statement? If so, what would have to change for you to do so? Paul: Jesse Keating provided a draft policy for what updates should be done. Board will take this into consideration, if necessary, in another round of discussions (not this meeting). John, Mike, Spot, Dennis, Matt, Josh: let's finish the Board's draft today that we have worked on so hard all week--other proposals can be factored in later Christopher Aillon: remove discussion about ''new packages''--this confuses the issue; new packages are a separate topic--this is about '''updates''' Spot: leave ''new packages'' part in because there has been a lot confusion around this. New packages are not considered updates and may be handled differently. Dennis: Dependency Groups of packages should be bundled together and pushed simultaneously. (Matt: this is due to how 'make update' works today; it needs to take multiple packages into account if it doesn't already) Josh, Spot, Paul: decision as to allow/disallow new packages to be introduced into stable releases is to be left to FESCo. * Decision: text added to Background: This policy is not meant to govern the introduction of new packages. * Decision: unanimous approval, remove draft status. Josh to publish. Paul to email FAB list. Paul and Josh to come up with appropriate title and wiki namespace. Paul: we know we can't please everyone. Stay polite as the next discussion flares, but stay the course. == Next meeting == * PROPOSED: Wed 2010-03-18 UTC 1700 * Next secretarial duty: Tom 'spot' Callaway * Regrets: Matt Domsch ___ advisory-board mailing list advisory-bo...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/advisory-board - End forwarded message - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On Thu, 11 Mar 2010, Jesse Keating wrote: https://fedoraproject.org/wiki/Stable_Release_Updates_Proposal Here is the link. I'm going to start a new thread here. # Stable releases should not be used for tracking upstream version closely when this is likely to change the user experience beyond fixing bugs and security issues. # Close tracking of upstream should be done in the Rawhide repo wherever possible, and we should strive to move our patches upstream. That might be harsh for some soname updates. Six months is a long time to wait on new functionality after upstream released it. Even for users running only full Fedora releases. Though I see various phrasing around this that would allow exceptions, which is good. Example: SHA256 support added to bind 9.6.2 less then a week ago (from 9.6.1). Bind 9.6.x is in F-12, and arpa. will be signed with SHA256 in 4 days. This leaves quite the window until F-13 is released (where users are on bind-9.7.x that contains SHA25 already). In this case, F-12 should really upgrade from 9.6.1 to 9.6.2. I understand this when thinking about large sets (KDA, Gnome) or common libraries that has too many in and out of tree dependancies (openssl 0.9x vs openssl 1.x), but it might not always be valid. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On Thu, 11 Mar 2010, Paul Wouters wrote: That might be harsh for some soname updates. Six months is a long time to wait on new functionality after upstream released it. Even for users running only full Fedora releases. Though I see various phrasing around this that would allow exceptions, which is good. Example: SHA256 support added to bind 9.6.2 less then a week ago (from 9.6.1). Bind 9.6.x is in F-12, and arpa. will be signed with SHA256 in 4 days. This leaves quite the window until F-13 is released (where users are on bind-9.7.x that contains SHA25 already). In this case, F-12 should really upgrade from 9.6.1 to 9.6.2. And it will be impossible for users running the non-sha256 bind to communicate with the sha256 supporting arpa? I guess I don't understand what do the users of the existing bind LOSE? Is ARPA expecting everyone to upgrade to a sha256 supporting bind immediately? There's no migration window? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On Thu, Mar 11, 2010 at 01:52:06PM -0500, Paul Wouters wrote: That might be harsh for some soname updates. If a user has built an application against a library, it's not especially reasonable to then break that application by bumping a soname in a stable release. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
Once upon a time, Paul Wouters p...@xelerance.com said: That might be harsh for some soname updates. Six months is a long time to wait on new functionality after upstream released it. People keep tossing out six months. How often is it that a new Fedora release comes out right before a new upstream, and that upstream is not already in testing in Fedora? Why not handle those cases similar to how GNOME and Firefox (and IIRC OpenOffice.org?) have been handled in the past, where a test/RC release was in Fedora leading up to the Fedora release, and the final upstream release is pushed as an update (if/when needed)? Going from test/RC to final usuaully isn't going to involve major changes (soname bumps, UI changes, etc.) and so should be an acceptable update to everybody. You'd be looking at a typical peak of around 5 months between upstream release and Fedora release, with an average of more like 2-3 months, which is a lot different from the 6 months that keeps being repeated as the waiting time for something new. For example (just an example - please don't take this as picking on KDE!), KDE 4.4.0 was released on February 9, and F13 is scheduled for May 11. That's a 3 month gap, not 6 months. In my opinion, I don't think it is entirely unreasonable to wait 3 months for a major new release. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F13 -EGPUDRIVERNOWORKIE
W dniu 10 marca 2010 20:49 użytkownik Michał Piotrowski mkkp...@gmail.com napisał: I can install F13 in text mode later and send some more informations about these issues with both drivers. Unfortunately I can't https://bugzilla.redhat.com/show_bug.cgi?id=572658 Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Install fedora-easy-karma by default?
Rahul Sundaram wrote: On 03/11/2010 11:00 PM, Matthew Woehlke wrote: I tried to send you a reply, but it bounced; gmail says the address you gave does not exist. I got the mail. Thanks. Yes, sorry. Must not have read the bounce close enough; I was trying to forward a copy to myself (different account) and got *my* address wrong :-). -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Oops. -- Shannon Foraker (David Weber, Ashes of Victory) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On Thu, Mar 11, 2010 at 1:36 PM, Jesse Keating jkeat...@redhat.com wrote: On Thu, 2010-03-11 at 12:21 -0600, Matt Domsch wrote: Paul: Jesse Keating provided a draft policy for what updates should be done. Board will take this into consideration, if necessary, in another round of discussions (not this meeting). https://fedoraproject.org/wiki/Stable_Release_Updates_Proposal Here is the link. I'm going to start a new thread here. Feedback welcome. Should there be a caveat for cases like I'm dealing with right now -- pidgin-sipe 1.9.0 provides both security fixes and new features compared to pidgin-sipe 1.8.1. If these guidelines are to be followed, then I both should (security fixes) and shouldn't (new features) be pushing this release into F12 and F11. (And if the answer is backport the security fixes to 1.8.1 then I'm afraid I don't really have the skills nor have the time to spend on such massive effort). Regards, -- McGill University IT Security Konstantin Ryabitsev Montréal, Québec -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
On Thu, 2010-03-11 at 00:19 -0500, Felix Miata wrote: Have you tried to buy a replacement PATA disk lately, particularly one no larger than the 2^28 ATA-5 addressing limit? Buying a replacement 20G HD, or one compatible with it even if 10X or more the storage size actually needed, has become a difficult task, particularly if a new product and a warranty longer than 90 days is desired. The bother is that it looks like HD makers will have their way with 512 as they have with PATA, forcing a lot of otherwise useful hardware into landfills prematurely. You know you can buy a PCI SATA controller card for about $10 in any PC junk store, right? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expect more positive bodhi karma / check karma automatism
On Thu, Mar 11, 2010 at 2:07 AM, Till Maas opensou...@till.name wrote: On Wed, Mar 10, 2010 at 04:51:34PM -0700, Stephen John Smoogen wrote: The biggest query command I would like at the moment is something like: fedora-easy-karma --list # lists packages to be voted on. fedora-easy-karma --list-new # list pacakges I haven't voted on already. fedora-easy-karma by default already skips updates, that you already commented on, this can be disabled with --include-commented. So would it be enough, if there is an option --list-only, that skips the questions whether or not to comment, but only displays the update descriptions? What I am looking for is something where I can get a short list of packages I would be asked to comment on if I ran the program. The reason being that I removed a couple hundred packages yesterday because I don't run them, haven't run them, and probably wouldn't know how to test them :). -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expect more positive bodhi karma / check karma automatism
Additionally, I have some RFE's too. ;) - Could you add a 'q' for quit or something. Or at least not catch control-c? If I am in the middle of doing something and need to reboot or wander off, I would perfer to be able to just stop. - Perhaps also a 'n' and 'p' for next and previous ? If I am looking at them quickly, I sometimes hit a return when I should have stopped and tested something. The only way to go back is to get to the end and restart and find the update I passed. - Perhaps add a (FEK) or something to the comments? It would then be more obvious how many people are using this tool? Again, great work on this... thanks! kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On Thu, 2010-03-11 at 14:56 -0500, Konstantin Ryabitsev wrote: Should there be a caveat for cases like I'm dealing with right now -- pidgin-sipe 1.9.0 provides both security fixes and new features compared to pidgin-sipe 1.8.1. If these guidelines are to be followed, then I both should (security fixes) and shouldn't (new features) be pushing this release into F12 and F11. (And if the answer is backport the security fixes to 1.8.1 then I'm afraid I don't really have the skills nor have the time to spend on such massive effort). If you're going by my page, you'll note that Generally it is expected that these types of bugs can be fixed without introducing new major upstream releases. When this is not the case the update should be considered a new upstream version and treated accordingly. And then if you read the new upstream versions you'll see: For new upstream versions of packages which provide new features, but don't just fix critical bugs, an update can still be issued, but it is vital that the new upstream version does not regress or drastically change a user's experience. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Note: comps moved to Fedora Hosted git
As discussed both on-list, and at this week's FESCo meeting (http://meetbot.fedoraproject.org/fedora-meeting/2010-03-09/fesco.2010-03-09-20.00.txt) the 'comps' module used for mapping packages to package groups in Fedora has moved from CVS to Fedora Hosted git. You may view the module at: http://git.fedorahosted.org/git/?p=comps.git and check it out at any of: http://git.fedorahosted.org/git/comps.git (r/o) git://git.fedorahosted.org/comps.git (r/o) ssh://git.fedorahosted.org/git/comps.git (r/w, for packagers) Access control and policies remain the same. The old comps module in CVS will remain in a read-only state while users of it upgrade their scripts. If you have any issues with the new location, please file a ticket in release-engineering trac: https://fedorahosted.org/rel-eng/newticket Thanks, Bill Nottingham ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On Thu, 11 Mar 2010 14:56:05 -0500 Konstantin Ryabitsev i...@fedoraproject.org wrote: (And if the answer is backport the security fixes to 1.8.1 then I'm afraid I don't really have the skills nor have the time to spend on such massive effort). You can always find a co-maintainer skilled enough to help you in such rare cases... just saying. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-13 Branched report: 20100311 changes
Compose started at Thu Mar 11 09:15:07 UTC 2010 Broken deps for i386 -- doodle-0.6.7-5.fc12.i686 requires libextractor.so.1 easystroke-0.5.2-1.fc13.i686 requires libboost_serialization-mt.so.5 edje-0.9.9.050-6.fc12.i686 requires libembryo.so.0 gnome-python2-totem-2.29.1-4.fc13.i686 requires libtotem-plparser.so.12 1:gnumeric-1.9.17-3.fc13.i686 requires libgoffice-0.8.so.7 1:gnumeric-plugins-extras-1.9.17-3.fc13.i686 requires libgoffice-0.8.so.7 kipi-plugins-1.1.0-2.fc13.i686 requires libhighgui.so.4 kipi-plugins-1.1.0-2.fc13.i686 requires libcxcore.so.4 kipi-plugins-1.1.0-2.fc13.i686 requires libcv.so.4 kipi-plugins-1.1.0-2.fc13.i686 requires libcvaux.so.4 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgobject-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libntfs-3g.so.74.0.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgcc_s-4.4.3-20100211.so.1 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libntfs-3g.so.74 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libglib-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgthread-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgio-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgmodule-2.0.so.0.2303.0 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 nip2-7.20.7-2.fc13.i686 requires libgoffice-0.8.so.7 zikula-module-menutree-2.2-1.fc13.noarch requires zikula = 0:1.2 Broken deps for x86_64 -- doodle-0.6.7-5.fc12.i686 requires libextractor.so.1 doodle-0.6.7-5.fc12.x86_64 requires libextractor.so.1()(64bit) easystroke-0.5.2-1.fc13.x86_64 requires libboost_serialization-mt.so.5()(64bit) edje-0.9.9.050-6.fc12.i686 requires libembryo.so.0 edje-0.9.9.050-6.fc12.x86_64 requires libembryo.so.0()(64bit) gnome-python2-totem-2.29.1-4.fc13.x86_64 requires libtotem-plparser.so.12()(64bit) 1:gnumeric-1.9.17-3.fc13.i686 requires libgoffice-0.8.so.7 1:gnumeric-1.9.17-3.fc13.x86_64 requires libgoffice-0.8.so.7()(64bit) 1:gnumeric-plugins-extras-1.9.17-3.fc13.x86_64 requires libgoffice-0.8.so.7()(64bit) kipi-plugins-1.1.0-2.fc13.x86_64 requires libcvaux.so.4()(64bit) kipi-plugins-1.1.0-2.fc13.x86_64 requires libcv.so.4()(64bit) kipi-plugins-1.1.0-2.fc13.x86_64 requires libhighgui.so.4()(64bit) kipi-plugins-1.1.0-2.fc13.x86_64 requires libcxcore.so.4()(64bit) 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgobject-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libntfs-3g.so.74.0.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgcc_s-4.4.3-20100211.so.1 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libntfs-3g.so.74 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libglib-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgthread-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgio-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgmodule-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.x86_64 requires /lib64/libgthread-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.x86_64 requires /lib64/libntfs-3g.so.74 1:libguestfs-1.0.84-2.fc13.x86_64 requires /lib64/libgio-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.x86_64 requires /lib64/libgmodule-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.x86_64 requires /lib64/libgobject-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.x86_64 requires /lib64/libglib-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.x86_64 requires /lib64/libgcc_s-4.4.3-20100211.so.1 1:libguestfs-1.0.84-2.fc13.x86_64 requires /lib64/libntfs-3g.so.74.0.0 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit) nip2-7.20.7-2.fc13.x86_64 requires libgoffice-0.8.so.7()(64bit) zikula-module-menutree-2.2-1.fc13.noarch requires zikula = 0:1.2 New package bfa-firmware Brocade Fibre Channel HBA Firmware New package rubygem-yard Documentation tool for consistent and usable documentation in Ruby New package tlomt-sniglet-fonts A rounded, sans-serif font useful for headlines New package ueagle-atm4-firmware Firmwares for USB ADSL Modems based on Eagle IV Chipset Updated Packages: FlightGear-2.0.0-1.fc13 --- * Fri Feb 26 2010 Fabrice Bellet fabr...@bellet.info 2.0.0-1 - New upstream release FlightGear-Atlas-0.4.0-0.4.cvs20100226.fc13 --- * Sat Feb 27 2010 Fabrice Bellet fabr...@bellet.info 0.4.0-0.4.cvs20100226 - Rebuild with missing librt library * Fri Feb 26 2010 Fabrice Bellet
Re: Expect more positive bodhi karma / check karma automatism
On Thu, Mar 11, 2010 at 01:22:35PM -0700, Kevin Fenzi wrote: Additionally, I have some RFE's too. ;) - Could you add a 'q' for quit or something. Or at least not catch control-c? If I am in the middle of doing something and need to reboot or wander off, I would perfer to be able to just stop. Uh, I catching CTRL-C is not intended, I'll look into this the next days. But you can use CTRL-D to quit. - Perhaps also a 'n' and 'p' for next and previous ? If I am looking at them quickly, I sometimes hit a return when I should have stopped and tested something. The only way to go back is to get to the end and restart and find the update I passed. Yes, this is annoying, I'll add this to TODO. In the meantime: In the git repo there is a version that accepts patterns to select an update, so you can just append the full name (no v-r) of a build to select only it or use shell pattern, e.g. gstreamer\* to only get updates that include a build or rpm matching this patterin. - Perhaps add a (FEK) or something to the comments? It would then be more obvious how many people are using this tool? The git version will set it's own http user agent so people with access to the server logs can create some usage statistics. But I could also add this, if nobody objects. Regards Till pgp2R9CL6KBE0.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Example of karma not being functional [Was:POSTUN scriptlet failure in rpm package cyrus-sasl]
On Thu, 2010-03-11 at 16:35 +0100, Ralf Corsepius wrote: This case is a nice example demonstrating several defects in applying karma votes for QA: 1. The update package was sitting in updates-testing since 2010-02-22. 2. It did receive +3 karma points before being pushed to updates c.f. https://admin.fedoraproject.org/updates/cyrus-sasl-2.1.23-6.fc12 = There are people who claim to have tested it and not having noticed anything unusual. They didn't claim that. They claimed that it 'works fine here' and 'works fo[r] me' (the other message just says 'thanks', but we can count it as 'works for me' as that's what the radio button says). The point is: this update *does* work. The error message is non-fatal. The software works. So what they claim is correct. What you claim is also correct. What this highlights is, indeed, a defect, though - the same one I raised at the FESco meeting: we don't have a definition of what exact criteria a package should meet to get a +1. Should we vote down updates which have non-fatal scriptlet errors? That question doesn't yet have a clear answer. It doesn't, however, mean the initial testers were 'not carefully enough', as you claim on the ticket. It just means you were working to different criteria. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On Thu, 11 Mar 2010, Seth Vidal wrote: And it will be impossible for users running the non-sha256 bind to communicate with the sha256 supporting arpa? I guess I don't understand what do the users of the existing bind LOSE? Is ARPA expecting everyone to upgrade to a sha256 supporting bind immediately? There's no migration window? If someone has dnssec enabled in bind including DLV, then the key will be found and its use will be attempted. I am not sure what happens on an older bind 9.6.1 when that happens. One will hope it will just continue to be treated as insecure and not as bogus (aka servfail). I have not tested this. But I understand your generic point. It's a feature so put it in rawhide/next release. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To semi-rolling or not to semi-rolling, that is the question...
On 03/09/2010 07:46 PM, Kevin Kofler wrote: Doug Ledford wrote: Things like the libata kernel change and KDE 3 to 4 migration are intentional events That's the whole problem. Under our current model, we have places and times where to perform those intentional disruptive changes, they're called releases. In a consumable Rawhide, we don't (*), and that's an unavoidable limit to its consumability. Rawhide is a poor substitute for our current release model. (*) Sure, we can add flag days as you propose, but that's too often for users (at least 6 times as often, anything less frequent would make development basically impossible) You're assuming that each flag day will in fact be one where the user has to do something. That's not necessarily true. The hda-sda switch happened, what, 2 years or more ago? Yeah, it was a big deal. We've not really had an event like that since, and don't currently have one on the horizon. So, the FUD that 1 flag day per month means we'll actually have 1 user intervention required event per month is highly unlikely. No amount of testing, coordination etc. is going to make it acceptable to e.g. dump KDE 4 on KDE 3 users overnight. You handle a flag day like a mini-release. It's coordinate, users know about it ahead of time, there is no dumping things on people overnight. Jesse is proposing to have automated QA as the ONLY filter for packages to go to a supposedly consumable repository. So I replied that this cannot work because it cannot catch all issues. At the very least, the maintainer must be able to manually flag things as not being suitable for the consumable repository just yet. Sure. And to have something consumable enough to replace (at least for a class of users) releases, something like updates- testing is needed. Sure. All you have to do is build into rawhide-unstable then tell users to yum --enablerepo=rawhide-unstable upgrade foo to get that behavior if you want. You could split things out into two repos, but I'm not sure it's entirely worth it. But in general, yes, a testing repo would be wise to have. No, my argument is that Rawhide cannot even meet what is the CURRENT bar of our released products. For example, in KDE SIG, we DO NOT push changes we know to be disruptive, e.g.: * KDE 4 as an update to a release which shipped with KDE 3, * Amarok 2 as an update to a release which shipped with Amarok 1, * KDevelop 4 as an update to a release which shipped with KDevelop 3, and similarly the kernel maintainers DID NOT enable libata in update kernels for releases which shipped without libata, even when they pushed a new kernel where upstream enabled libata by default. We also do not push feature upgrades such as KDE 4.4 without long and tedious testing (as I explained further up). The current update system is NOT the free-for-all you seem to think it is. The updates are actually very carefully weighed for risks vs. benefits. It's NOT a consumable Rawhide, and any attempt to replace them with a Rawhide made consumable is bound to fail. In your opinion. I say it *could* succeed, and could be consumable. I say you lack the desire to see how things could be instead of how things are. You say I have rose colored glasses on. We get it. I'm sorry Kevin, but you and I will simply have to agree to disagree. I will *not* capitulate to your stance on this issue. But I think you're entirely missing my point! No, I very much get your point, I just think you are wrong. -- Doug Ledford dledf...@redhat.com GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Webcam test day - results deleted?
I was just about to enter some webcam test results but the results that were there earlier seem to have disappeared! Is it just me or has some clutz deleted the entries? -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On Thu, 2010-03-11 at 16:22 -0500, Paul Wouters wrote: On Thu, 11 Mar 2010, Seth Vidal wrote: And it will be impossible for users running the non-sha256 bind to communicate with the sha256 supporting arpa? I guess I don't understand what do the users of the existing bind LOSE? Is ARPA expecting everyone to upgrade to a sha256 supporting bind immediately? There's no migration window? If someone has dnssec enabled in bind including DLV, then the key will be found and its use will be attempted. I am not sure what happens on an older bind 9.6.1 when that happens. One will hope it will just continue to be treated as insecure and not as bogus (aka servfail). I have not tested this. But I understand your generic point. It's a feature so put it in rawhide/next release. Paul If the case was that it would stop working badly, that falls under the type of update I listed that depends on external data providers. That type of update is allowed. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Webcam test day - results deleted?
On Thu, 11 Mar 2010, Bruno Wolff III wrote: On Thu, Mar 11, 2010 at 21:43:24 +, mike cloaked mike.cloa...@gmail.com wrote: I was just about to enter some webcam test results but the results that were there earlier seem to have disappeared! Is it just me or has some clutz deleted the entries? Did you look at the history? That might give a clue if it was intentional or a mistake. It seems ok to me - https://fedoraproject.org/wiki/Test_Day:2010-03-11_webcams Is that not the page you're looking at? -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
On 2010/03/11 12:10 (GMT-0800) Adam Williamson composed: You know you can buy a PCI SATA controller card for about $10 in any PC junk store, right? PC BIOS treat those as SCSI cards, which do not play nice with boot device order control by the PC BIOS, if not OS device names. Even when neither is a problem, it's no given that a PCI slot is available, or the junk store has enough cards for all machines with dead HDs on the LAN. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: POSTUN scriptlet failure in rpm package cyrus-sasl
On Thu, Mar 11, 2010 at 11:35:55AM -0500, Bill Nottingham wrote: Toshio Kuratomi (a.bad...@gmail.com) said: Options: * Put a large admonition at the top that says I am not a Packaging Guideline and point to the packaging guideline page for user creation. * Remove the page * Have the FPC vote whether use of fedora-usermgmt is disallowed and remove the page if so * Rename the page * Someone works on the text of the page to make it clear that it's only documenting the fedora-usermgmt application, not something written into the packaging guidelines. * Update the page to remove the userdel and groupdel portions. What combination of the above seems most suitable to people? The first item I think is the obvious change; Done. If people still find it confusing we'll progress to renaming or FPC. -Toshio pgp2Ol00qqKsY.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Webcam test day - results deleted?
On Thu, 2010-03-11 at 21:43 +, mike cloaked wrote: I was just about to enter some webcam test results but the results that were there earlier seem to have disappeared! Is it just me or has some clutz deleted the entries? Eyeballing the history: https://fedoraproject.org/w/index.php?title=Test_Day:2010-03-11_webcamsaction=history I see only once change which made the page marginally smaller, and that was just shortening the Name field for one of the entries. So no, I don't think anyone took out any results. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
ons 2010-03-10 klockan 15:57 -0600 skrev Eric Sandeen: There has been a lot of work upstream on 4k sector support, and in general yes, we are ready. Problems can probably be expected in case the drive does not report its real block size to the software, though, like my WD15EARS (I think) or VMware's emulated SCSI drives. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
Alexander Boström wrote: ons 2010-03-10 klockan 15:57 -0600 skrev Eric Sandeen: There has been a lot of work upstream on 4k sector support, and in general yes, we are ready. Problems can probably be expected in case the drive does not report its real block size to the software, though, like my WD15EARS (I think) or VMware's emulated SCSI drives. There's only so much we can do in the face of bad hardware ;) -Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Webcam test day - results deleted?
On Thu, Mar 11, 2010 at 9:51 PM, Mike McGrath mmcgr...@redhat.com wrote: Did you look at the history? That might give a clue if it was intentional or a mistake. It seems ok to me - https://fedoraproject.org/wiki/Test_Day:2010-03-11_webcams Is that not the page you're looking at? Yup - seems it was my bad - I had another page which was in the QA wiki which had the start of the page but not the rest of it - your url works fine. My apologies... thanks - I will now add my results... Mike -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
Chris Adams wrote: Once upon a time, Paul Wouters p...@xelerance.com said: That might be harsh for some soname updates. Six months is a long time to wait on new functionality after upstream released it. People keep tossing out six months. How often is it that a new Fedora release comes out right before a new upstream, and that upstream is not already in testing in Fedora? The average is 3 months which is just as unreasonable. For example (just an example - please don't take this as picking on KDE!), KDE 4.4.0 was released on February 9, and F13 is scheduled for May 11. That's a 3 month gap, not 6 months. In my opinion, I don't think it is entirely unreasonable to wait 3 months for a major new release. I disagree. Sorry. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
Matthew Garrett wrote: On Thu, Mar 11, 2010 at 01:52:06PM -0500, Paul Wouters wrote: That might be harsh for some soname updates. If a user has built an application against a library, it's not especially reasonable to then break that application by bumping a soname in a stable release. If the application is in Fedora as all applications eventually ought to be, we will take care of rebuilding it. Otherwise, whoever built it (some third- party repository or the user him/herself) is responsible for rebuilding it. This has always worked fine, I don't see the problem. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On 11/03/10 22:45, Kevin Kofler wrote: Chris Adams wrote: Once upon a time, Paul Woutersp...@xelerance.com said: That might be harsh for some soname updates. Six months is a long time to wait on new functionality after upstream released it. People keep tossing out six months. How often is it that a new Fedora release comes out right before a new upstream, and that upstream is not already in testing in Fedora? The average is 3 months which is just as unreasonable. For example (just an example - please don't take this as picking on KDE!), KDE 4.4.0 was released on February 9, and F13 is scheduled for May 11. That's a 3 month gap, not 6 months. In my opinion, I don't think it is entirely unreasonable to wait 3 months for a major new release. I disagree. Sorry. Kevin Kofler +1 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On Thu, Mar 11, 2010 at 1:36 PM, Jesse Keating jkeat...@redhat.com wrote: https://fedoraproject.org/wiki/Stable_Release_Updates_Proposal Here is the link. I'm going to start a new thread here. Thanks for drafting this. Would it make sense to look at the API coupling dimension? When a package provides an API/ABI that other software (packaged or not!) depends on, the likelyhood of breakage and impact are much higher. IME, when the update affects a large set of interdependent, tightly coupled packages (and external sw) (ie: KDE) the chances of a smooth upgrade are vanishingly small, unless you spend QA efforts similar to an OS release. At the opposite end of the spectrum Leaf packages -- (ie: gnote), are less likely to break, and less disruptive when it happens. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adventurous yet Safety-Minded
Alexander Kahl wrote: Please define massive if you're keeping exactly what's needed to keep everything running and prune anything else by using a sophisticated, tunable garbage collection mechanism. The whole point of the exercise was to do a lot of updates. But the more updates we do, the more disk space the old versions you're keeping around are going to eat up. and also not compliant with the FHS (Filesystem Hierarchy Standard). Yep. It's much better, comparable to the GAC (global assembly cache) of the CLR (Mono), Yuck! Do you seriously call that better? Anyway, the FHS is not really negotiable. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On Thu, 2010-03-11 at 17:59 -0500, Martin Langhoff wrote: On Thu, Mar 11, 2010 at 1:36 PM, Jesse Keating jkeat...@redhat.com wrote: https://fedoraproject.org/wiki/Stable_Release_Updates_Proposal Here is the link. I'm going to start a new thread here. Thanks for drafting this. Would it make sense to look at the API coupling dimension? When a package provides an API/ABI that other software (packaged or not!) depends on, the likelyhood of breakage and impact are much higher. IME, when the update affects a large set of interdependent, tightly coupled packages (and external sw) (ie: KDE) the chances of a smooth upgrade are vanishingly small, unless you spend QA efforts similar to an OS release. At the opposite end of the spectrum Leaf packages -- (ie: gnote), are less likely to break, and less disruptive when it happens. I had thought about these things, but they didn't strike me as a high level update type. And for the leaf node packages, when they do break it's not as less disruptive as you might think. Leaf node packages exist for a reason, they are likely very important to somebody, and if that breaks, that's going to be a very big issue for that somebody. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Gnome panel
Anyone having any issues with the latest gnome-panel update that has come out in last day or two? As in, when trying to log out the panel just crashes and resets itself? Went back to last gnome good panel but that one has issues when running with the rest of the gnome updates. -- Mike Chambers Madisonville, KY Best lil town on Earth! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
Jesse Keating wrote: I had thought about these things, but they didn't strike me as a high level update type. And for the leaf node packages, when they do break it's not as less disruptive as you might think. Leaf node packages exist for a reason, they are likely very important to somebody, and if that breaks, that's going to be a very big issue for that somebody. But if they're outdated, that can also be a big issue. Some leaf packages are under heavy development, so users don't want to run old versions, nor do upstream developers want them to. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gnome panel
On Thu, 2010-03-11 at 17:10 -0600, Mike Chambers wrote: Anyone having any issues with the latest gnome-panel update that has come out in last day or two? As in, when trying to log out the panel just crashes and resets itself? Went back to last gnome good panel but that one has issues when running with the rest of the gnome updates. I've had it crash a few times today, yeah. Filed a bug on one occurrence. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
Once upon a time, Kevin Kofler kevin.kof...@chello.at said: Matthew Garrett wrote: If a user has built an application against a library, it's not especially reasonable to then break that application by bumping a soname in a stable release. If the application is in Fedora as all applications eventually ought to be, we will take care of rebuilding it. Otherwise, whoever built it (some third- party repository or the user him/herself) is responsible for rebuilding it. This has always worked fine, I don't see the problem. What about somebody developing on their own computer? Having to rebuild because you (or possibly somebody else, if a system has a dedicated admin) loaded an update is highly irritating. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
Once upon a time, Kevin Kofler kevin.kof...@chello.at said: Chris Adams wrote: Once upon a time, Paul Wouters p...@xelerance.com said: That might be harsh for some soname updates. Six months is a long time to wait on new functionality after upstream released it. People keep tossing out six months. How often is it that a new Fedora release comes out right before a new upstream, and that upstream is not already in testing in Fedora? The average is 3 months which is just as unreasonable. Why? What do you consider a reasonable interval? For example (just an example - please don't take this as picking on KDE!), KDE 4.4.0 was released on February 9, and F13 is scheduled for May 11. That's a 3 month gap, not 6 months. In my opinion, I don't think it is entirely unreasonable to wait 3 months for a major new release. I disagree. Sorry. Can you at least give some reasons? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On Thu, Mar 11, 2010 at 11:47:03PM +0100, Kevin Kofler wrote: Matthew Garrett wrote: If a user has built an application against a library, it's not especially reasonable to then break that application by bumping a soname in a stable release. If the application is in Fedora as all applications eventually ought to be, we will take care of rebuilding it. Otherwise, whoever built it (some third- party repository or the user him/herself) is responsible for rebuilding it. This has always worked fine, I don't see the problem. You don't see a problem with breaking someone's application just because they've installed an update to a stable release of Fedora? It's obviously fine to do so when upgrading between releases, but within a release it's just gratuitously irritating. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
Once upon a time, Kevin Kofler kevin.kof...@chello.at said: Jesse Keating wrote: I had thought about these things, but they didn't strike me as a high level update type. And for the leaf node packages, when they do break it's not as less disruptive as you might think. Leaf node packages exist for a reason, they are likely very important to somebody, and if that breaks, that's going to be a very big issue for that somebody. But if they're outdated, that can also be a big issue. Some leaf packages are under heavy development, so users don't want to run old versions, nor do upstream developers want them to. Developers can't always get what they want. Just because Fedora updates to upstream's release-of-the-day doesn't mean Ubuntu, SuSE, etc. have updated (so hopefully upstream is still paying attention to older releases). Most reasonable upstreams I have worked with fully understand that not everybody is running yesterday's release and will work with you if you find a problem with an older release. If an upstream can't handle that, I would say that is the upstream's problem, not Fedora's. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- 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 Tuesday 09 March 2010 04:41:07 pm Michael Schwendt wrote: On Tue, 9 Mar 2010 16:54:16 -0500, Bill wrote: 20:59:11 dgilmore Kevin_Kofler: i dont see Michael Schwendt as infulencial. he choose to largely abstain from fedora years ago Huh? Now, what exactly is your problem with me? What the heck are you referring to? Sorry for not responding to you earlier. i choose not to read devel@ due to how poisonous it has been i marked the 1700 odd emails read and carried on. I have nothing against you at all. I was referring to things like http://www.redhat.com/archives/fedora-advisory-board/2007-June/msg00120.html Where rather than work with fedora as you previously had you chose to be less involved. which is perfectly fine and ok. however i should have not said anything when Kevin Brought up your name. I sent you a private apology. and ill say again here sorry i should not have said anything it was not appropriate for me to do so Dennis signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
Chris Adams wrote: What about somebody developing on their own computer? Having to rebuild because you (or possibly somebody else, if a system has a dedicated admin) loaded an update is highly irritating. Huh? I have to compile the stuff I am developing very often anyway. Having to rebuild it once is not going to be the end of the world. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
Matthew Garrett wrote: You don't see a problem with breaking someone's application just because they've installed an update to a stable release of Fedora? It's obviously fine to do so when upgrading between releases, but within a release it's just gratuitously irritating. The application is not broken if whoever built it does his/her job. It's not like there's no notification about soname bumps (when done right; I know some people do not follow procedures, but then that's the problem, not the soname bump). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On 03/12/2010 05:44 AM, Kevin Kofler wrote: Chris Adams wrote: What about somebody developing on their own computer? Having to rebuild because you (or possibly somebody else, if a system has a dedicated admin) loaded an update is highly irritating. Huh? I have to compile the stuff I am developing very often anyway. Having to rebuild it once is not going to be the end of the world. No but it is often disruptive if ABI changes are in libraries in an update and we should avoid that as much as possible. This is part of treating Fedora as a platform instead of a loose set of packages. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
Chris Adams wrote: Once upon a time, Kevin Kofler kevin.kof...@chello.at said: The average is 3 months which is just as unreasonable. Why? What do you consider a reasonable interval? The time it actually takes to test the update. I.e. at most 3 weeks. For example (just an example - please don't take this as picking on KDE!), KDE 4.4.0 was released on February 9, and F13 is scheduled for May 11. That's a 3 month gap, not 6 months. In my opinion, I don't think it is entirely unreasonable to wait 3 months for a major new release. I disagree. Sorry. Can you at least give some reasons? Once 4.n+1.0 is out, 4.n.x is no longer updated, there are no further bugfix releases, any bugs in it will stay unfixed. And there are also nice new features in the new version. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On Fri, 12 Mar 2010 01:14:36 +0100 Kevin Kofler kevin.kof...@chello.at wrote: Chris Adams wrote: What about somebody developing on their own computer? Having to rebuild because you (or possibly somebody else, if a system has a dedicated admin) loaded an update is highly irritating. Huh? I have to compile the stuff I am developing very often anyway. Having to rebuild it once is not going to be the end of the world. It is if you are not the developer but the user. If you want bleeding edge, ABI breaking stuff, just use rawhide. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
Chris Adams wrote: Developers can't always get what they want. Just because Fedora updates to upstream's release-of-the-day doesn't mean Ubuntu, SuSE, etc. have updated (so hopefully upstream is still paying attention to older releases). It is (especially for leaf packages) much more likely they're going to say one or more of: * screw you, use a sane distro (and we lose the user), * just build our tarball from source (with the result that the user ends up with an unpackaged mess in /usr/local which grows like mold), * screw the distro packages, use ours (and this leads us to the third- party package chaos problem, which is characterized by low-quality packages, dependency hell, inter-repository compatibility issues etc.). Most reasonable upstreams I have worked with fully understand that not everybody is running yesterday's release and will work with you if you find a problem with an older release. If an upstream can't handle that, I would say that is the upstream's problem, not Fedora's. Upstream cannot go back in time and magically fix a bug in an old release. The bug is often already fixed in the current release, so the solution is for us to package the current release. And no, backporting fixes is often not practical. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To semi-rolling or not to semi-rolling, that is the question...
Doug Ledford wrote: You're assuming that each flag day will in fact be one where the user has to do something. That's not necessarily true. The hda-sda switch happened, what, 2 years or more ago? Yeah, it was a big deal. We've not really had an event like that since, and don't currently have one on the horizon. So, the FUD that 1 flag day per month means we'll actually have 1 user intervention required event per month is highly unlikely. There are many more changes which require user intervention, even if it's not as obvious (as in don't intervene and your system won't boot). For example, after upgrading from F8 to F9, i.e. moving from KDE 3 to KDE 4, I had to tweak my desktop configuration in a few places. And even less blatant changes sometimes require some sort of user intervention (such as recreating some configuration because it's represented differently in the new version and upstream didn't provide a way to migrate it automatically). And required user intervention is not the only source of trouble, things like feature regressions, data (e.g. savegame) compatibility etc. are, too. You handle a flag day like a mini-release. It's coordinate, users know about it ahead of time, there is no dumping things on people overnight. Except it's not a mini-release. You can't just stay on the old branch (and still get security, bugfix and other nondisruptive updates) if you aren't ready for the change as you can with our releases. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On 03/12/2010 06:14 AM, Kevin Kofler wrote: How is it disruptive? Surely not because I have to rebuild the stuff I am developing myself and have to compile very often anyway Just because you are in a position to rebuild stuff when necessary, does not mean that is convenient for all consumers of a library to do so and rebuilding and pushing out updates for software outside the repository is often problematic. Look at real life environments outside the developer boxes that you live in. If you don't even agree with a basic principle that breaking ABI should be avoided in updates, we don't really have much left to discuss. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On Fri, Mar 12, 2010 at 01:26:26AM +0100, Kevin Kofler wrote: Chris Adams wrote: Developers can't always get what they want. Just because Fedora updates to upstream's release-of-the-day doesn't mean Ubuntu, SuSE, etc. have updated (so hopefully upstream is still paying attention to older releases). It is (especially for leaf packages) much more likely they're going to say one or more of: * screw you, use a sane distro (and we lose the user), * just build our tarball from source (with the result that the user ends up with an unpackaged mess in /usr/local which grows like mold), * screw the distro packages, use ours (and this leads us to the third- party package chaos problem, which is characterized by low-quality packages, dependency hell, inter-repository compatibility issues etc.). Most reasonable upstreams I have worked with fully understand that not everybody is running yesterday's release and will work with you if you find a problem with an older release. If an upstream can't handle that, I would say that is the upstream's problem, not Fedora's. Upstream cannot go back in time and magically fix a bug in an old release. The bug is often already fixed in the current release, so the solution is for us to package the current release. And no, backporting fixes is often not practical. I know that backporting fixes is often not practical, especially if there is a lot of code churn upstream. How often this is the case depends on the project of course. Do you have any cost estimates on that though? (honest question, I'm not involved with KDE so I can't even guess) As in, on average what are the costs of leaving a bug in vs. the cost of updating to a new release. I noticed that there's a number of bugs that only affect a subset of users that (often) can work around the issue. So the cost - while high to a particular user - may be quite limited. Updating to a new release will affect _every_ user and given that software is imperfect it's likely that existing bugs will just be replaced by new, different bugs. So on the one side you have the cost of having known bugs, on the other side you have the benefit of fixing (some) bugs but the cost of new bugs and a potential change in the user experience. Which one is higher than the other one? Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On Fri, Mar 12, 2010 at 01:44, Kevin Kofler kevin.kof...@chello.at wrote: Rahul Sundaram wrote: On 03/12/2010 05:44 AM, Kevin Kofler wrote: Chris Adams wrote: What about somebody developing on their own computer? Having to rebuild because you (or possibly somebody else, if a system has a dedicated admin) loaded an update is highly irritating. Huh? I have to compile the stuff I am developing very often anyway. Having to rebuild it once is not going to be the end of the world. No but it is often disruptive if ABI changes are in libraries in an update and we should avoid that as much as possible. This is part of treating Fedora as a platform instead of a loose set of packages. How is it disruptive? Surely not because I have to rebuild the stuff I am developing myself and have to compile very often anyway… If it's stuff coming from a third-party repo, it's that repo's responsibility to rebuild the package and get it out together with the Fedora update. « Alright, today I'll be implementing feature XYZ in my Foobar program. » [... a short hack later, testing the change...] « Why doesn't it work? It was working fine last time I tried, what's happening » [... an hour of debugging later...] « $...@!%µ the Libbar librazy was updated and isn't compatible anymore. Great, I just lost an hour trying to solve a problem in my program when it was coming from an soname bump! Thank you (not) $distro maintainer!!! » I have a very short programming experience, and yet it already happened to me. I can't imagine how little patience must remain for those who have been facing this kind of problems for years. :-/ -- Mathieu Bridon -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gnome panel
On Thu, 2010-03-11 at 15:20 -0800, Adam Williamson wrote: On Thu, 2010-03-11 at 17:10 -0600, Mike Chambers wrote: Anyone having any issues with the latest gnome-panel update that has come out in last day or two? As in, when trying to log out the panel just crashes and resets itself? Went back to last gnome good panel but that one has issues when running with the rest of the gnome updates. I've had it crash a few times today, yeah. Filed a bug on one occurrence. Looks like new build being compiled, but saw on koji that it failed. Hope it's a fix. -- Mike Chambers Madisonville, KY Best lil town on Earth! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
Rahul Sundaram wrote: If you don't even agree with a basic principle that breaking ABI should be avoided in updates, we don't really have much left to discuss. I don't see this as being a basic principle at all. For an enterprise distro like RHEL or CentOS, sure. But not for something like Fedora. What counts is that all software in Fedora depending on the library gets rebuilt and pushed at the same time. (That's what grouped updates are for.) We do not support third-party software. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
Mathieu Bridon wrote: « Alright, today I'll be implementing feature XYZ in my Foobar program. » [... a short hack later, testing the change...] « Why doesn't it work? It was working fine last time I tried, what's happening » [... an hour of debugging later...] « $...@!%µ the Libbar librazy was updated and isn't compatible anymore. Great, I just lost an hour trying to solve a problem in my program when it was coming from an soname bump! Thank you (not) $distro maintainer!!! » It takes you an hour to figure that out? The error message you get when you're trying to use a library with the wrong soname is quite clear! And the next time it happens, you know that you should just make clean; make before checking anything else if something like this happens. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On Thu, 2010-03-11 at 23:41 +, Matthew Garrett wrote: You don't see a problem with breaking someone's application just because they've installed an update to a stable release of Fedora? It's obviously fine to do so when upgrading between releases, but within a release it's just gratuitously irritating. On F13, upgrade gnome-panel to version in updates-testing and you'll get panel crashes almost immediately when tryign to start an application or just logout of gnome. Soo, if we were using rawhide, almost every gnome user would be having crashes soon as they upgrade (minus the ones that watch for breakage first before they upgrade). Anyway, perfect example to test first (cuz maintainer might have accidentily missed something), and not just update straight to the branch. -- Mike Chambers Madisonville, KY Best lil town on Earth! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
Once upon a time, Kevin Kofler kevin.kof...@chello.at said: I don't see this as being a basic principle at all. For an enterprise distro like RHEL or CentOS, sure. But not for something like Fedora. What counts is that all software in Fedora depending on the library gets rebuilt and pushed at the same time. (That's what grouped updates are for.) We do not support third-party software. There's a difference between not supporting third-party software (is that actually documented somewhere or another Kevin Kofler rule?) and intentionally breaking it. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On 03/12/2010 06:52 AM, Kevin Kofler wrote: Rahul Sundaram wrote: If you don't even agree with a basic principle that breaking ABI should be avoided in updates, we don't really have much left to discuss. I don't see this as being a basic principle at all. For an enterprise distro like RHEL or CentOS, sure. But not for something like Fedora. What counts is that all software in Fedora depending on the library gets rebuilt and pushed at the same time. (That's what grouped updates are for.) We do not support third-party software. I disagree. Imagining that we are living in a island where no software exists outside the repository is just delusional and the assumption that everyone has the bandwidth to deal with all that churn is wrong as well. I should make people sit in a dial-up connection and have them update software now and then to bring them back to the ground. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On Thu, Mar 11, 2010 at 03:59:46PM -0500, Simo Sorce wrote: On Thu, 11 Mar 2010 14:56:05 -0500 Konstantin Ryabitsev i...@fedoraproject.org wrote: (And if the answer is backport the security fixes to 1.8.1 then I'm afraid I don't really have the skills nor have the time to spend on such massive effort). You can always find a co-maintainer skilled enough to help you in such rare cases... just saying. The Fedora Objectives page[1] says: In general, we prefer to move to a newer version for updates rather than backport fixes. I know this is what we're talking about, but it's not like we lack existing policy on this - the idea that there's no direction to help maintainers do the same things is not correct. Ewan [1] https://fedoraproject.org/wiki/Objectives -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On Fri, Mar 12, 2010 at 01:15:56AM +0100, Kevin Kofler wrote: Matthew Garrett wrote: You don't see a problem with breaking someone's application just because they've installed an update to a stable release of Fedora? It's obviously fine to do so when upgrading between releases, but within a release it's just gratuitously irritating. The application is not broken if whoever built it does his/her job. It's not like there's no notification about soname bumps (when done right; I know some people do not follow procedures, but then that's the problem, not the soname bump). If the software is not maintained within Fedora, there's no notification of soname bumps. -- Matthew Garrett | mj...@srcf.ucam.org -- 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 Thu, 11 Mar 2010 17:55:18 -0600, Dennis wrote: I was referring to things like http://www.redhat.com/archives/fedora-advisory-board/2007-June/msg00120.html Where rather than work with fedora as you previously had you chose to be less involved. which is perfectly fine and ok. Aha. Don't forget the earlier threads and the later ones (I have them locally, but they should be in the old archives). They are interesting! And in 2008 I was still active and responsive and even continued with buildsys maintenance, http://cvs.fedoraproject.org/viewvc/extras-buildsys/ChangeLog?revision=1.126.2.44.2.1.2.40root=fedoraview=markup and additionally moved activity into new areas. however i should have not said anything when Kevin Brought up your name. I sent you a private apology. and ill say again here sorry i should not have said anything it was not appropriate for me to do so I've received it and will reply tomorrow. It has been a long and hard day. I think you do me wrong, but I'd also like to apologise for trying to provoke a reaction from you with the screenshot I posted to fab list. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
Dne 12.3.2010 02:24, Rahul Sundaram napsal(a): I disagree. Imagining that we are living in a island where no software exists outside the repository is just delusional and the assumption that everyone has the bandwidth to deal with all that churn is wrong as well. I should make people sit in a dial-up connection and have them update software now and then to bring them back to the ground. Rahul, I used Debian, I know Debian, Debian was a friend of mine. I don't want Fedora to be just yet another copycat of Debian. Please keep it Fedora instead. Matěj P.S.: Reference is of course http://is.gd/aj75K -- http://www.ceplovi.cz/matej/, Jabber: mceplatceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC He uses statistics as a drunken man uses lamp-posts... for support, rather than illumination. -- Andrew Lang -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
