Re: Move a configuration file
Hello, Le 07/03/2010 20:42, Ville Skyttä a écrit : >> If I change the path in conf.d/BackupPC.conf ; users who have modified >> the .conf file will get a conf.rpmnew file ; that's fine. >> > If apache.users moves from /usr/share/BackupPC to /etc/BackupPC, it'll break > these setups because the old conf.d/BackupPC.conf that is left in place still > refers to the old location, no? > You are right, indeed. > >> The ones who did not change the .conf file will have it replaced by RPM, >> breaking the apache authentication. >> > ...assuming apache.users was modified and the modified one is required for > authentication to work? Is apache.users a config file? If it was not > modified, nothing should break. But I'm guessing that it is a config file > and > people are supposed to modify it so it's likely that these setups would break > as well. > apache.users is not shipped by the package, it's up to the user to create it with the appropriate command, and in the right place. By default, .conf and README files are pointing to /usr/share/BackupPC. > >> Any thoughts about that? >> > Not suitable as an update to released distro versions IMO. The way I've > handled cases like this sometime is to do it only between distro versions, > and > try to do migration in package scriptlets for some conceivably common cases. > > And adding a note about this to distro release notes would not hurt. > > One example of such migration (that I'm not at all proud of, but AFAIK it > ended up working fine) is %post in the vdr package. Hm, I see I've put a > TODO > comment to get rid of it in F-13 but have happily forgotten it... will do for > F-14 right away ;) > I think this could be the better solution for that case. A simple symlink as James has proposed would not be ok I think, since the apache.user file is not shipped with the package, It will add a possibly dangling symlink, I'd prefer not to do that. I think I'll do that "the vdr way", it appears to be the most flexible solution for my issue. Many thanks all for your help :-) Regards, Johan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
On Saturday 06 March 2010 19:38:16 Michał Piotrowski wrote: > 2010/3/6 Naheem Zaffar : > > 2010/3/6 Michał Piotrowski > > > >> Why I can install KDE 4.4 in F11 and I can't install latest gnome? > >> (I'm just asking because I'm curious, not because I use Linux on > >> desktop) > > > > I think for many people the issue is not that it can be an update (maybe > > the enhancements etc are useful to someone). > > > > As an end user, I would think there should be asafety precaution on non > > urgent updates to go through updates-testing. > > > > FTR, I DO like and want feature updates. > > > > Updates-testing will not catch everything, but it should help catch soime > > "nuclear" issues that otherwise may have sneaked past. > > > > I think the current update process is very good and well liked by me. But > > tweaking it is not a big problem. > > > > PS other places that have more stable updates also have their problems - > > there are many users who dislike Ubuntu because bugs are not fixed and > > they have to live with them far too long. > > I generally agree with your POV for actual stable F12 - latest and > greatest updates for peoples who likes bleeding edge. But previous > stable (F11) IMHO should be considered as "in maintenance mode" - > security and bug fixes only. This is what I said 100 times in all previous threads in last two weeks!!! Even KDE SIG is working on stability proposal that practically means - do not touch Fn-1 and I'd like to generalize it match Fedora... For mc update - no description is really very bad mistake! Jaroslav > Just my 0.02 $. > > Regards, > Michal -- Jaroslav Řezník Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Harmless KDE feature upgrades - yeah right
On Friday 05 March 2010 18:37:06 Matthew Woehlke wrote: > Petrus de Calguarium wrote: > > As I had expected, breaking up the monolithic > > packages into individual packages is a whole lot > > of unnecessary work. Better to provide releases > > as they occur, than to waste time unnecessarily > > breaking down the monolithic packages. To what > > end and benefit? Who, nowadays, doesn't have at > > least one hard drive of at least 80-100GB, likely > > You have heard of netbooks, yes? SSD's? I have all of 4 GiB, and not all > of that available for packages. We are planning some splits because we're planning KDE netbook spin. Netbook Plasma is new and very interesting piece of software and of course we'd like to support even old EEE 701 - I have one next to me ;-) Hopefully it's going to be F14 stuff. Jaroslav > > IIRC I had to remove kcalc because I can't afford to install the entire > printing stack. -- Jaroslav Řezník Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
On Saturday 06 March 2010 23:48:23 Kalev Lember wrote: > On 03/07/2010 12:25 AM, Orcan Ogetbil wrote: > > On Sat, Mar 6, 2010 at 5:16 PM, Christoph Wickert wrote: > >> +1, Michał! People who want the latest and greatest have already updated > >> to F12 months ago anyway, so there is not much use in pushing new > >> versions to F11. > > > > Why? I don't want to update/reinstall all my machines every 6 months. > > And I expect the same amount of latestness an greatestness from F-11 and > > F-12. And I am not alone. (See the discussions in the devel list for the > > last 2 weeks. > > > > When version X of a software is supported in F-12, the same version X > > can be supported most of the time in F-11. And if it can be supported, > > it should be supported. > > I'd personally want to be able to _choose_ if and when I want to get all > the new stuff. If I have time, I upgrade to new Fedora release and > happily deal with all the problems that come up. This is exactly what > new distro releases are for -- people prepare for the upgrade and take > time to do it. > > But what happened now is that a major Desktop Environment version was > dumped in a stable Fedora release, and it annoyed some people (me > included). If the new version had only come with F-13 instead, then I'd > have an option to choose _when_ I want to upgrade from F-12 to F-13 to > deal with the problems that might arise with the new version. But if the > new version is dumped upon me in the middle of a week, I'm left without > a choice. I have to immediately deal with whatever problems arise from > the upgrade. Now think how someone who administers more than one > computer would react to that -- I'm sure they also want to choose when > to get major upgrades so that they could upgrade when they feel they > have enough time for that. Major KDE update was in time of Fedora 9, so it's not an issue today. And this it the first problem - we should not call major, minor, bugfix release because it doesn't mean the same for every each app out in the wild!!! (KDE versioning is X.Y.Z where X is major, Y is minor and Z is bugfix release). Jaroslav > So yes, I'd prefer to upgrade (not reinstall! as you said) once every 6 > months, instead of having to deal with changing expectations every > single day. -- Jaroslav Řezník Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update question: some user data
Le Sam 6 mars 2010 20:04, Adam Williamson a écrit : > The numbers do surprise me, to be honest. As I write this, it's 34-8 - > that's over 80% - in favour of 'adventurous' updates. Advanced users (those most likely to want a more stable rawhide to use it as primary system) use irc, mailing lists, bugzilla, etc. Normal users (those that need a stable Fedora so they can spend their time writing apps, doing i18n, etc) do not read Fedora forums (if they had this kind of time they would not object to adventurous time-wasting updates). About the only population likely to read Fedora forums regularly are tinkerers that have not moved to the advanced stage and its communication channels, but need something to coordinated workarounds when one of the experimental updates they so like break their system. This something is Fedora forums. It would have been highly surprising that you'd get a different answer by posting your poll here. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
On 03/08/2010 11:20 AM, Jaroslav Reznik wrote: > Major KDE update was in time of Fedora 9, so it's not an issue today. > > And this it the first problem - we should not call major, minor, bugfix > release > because it doesn't mean the same for every each app out in the wild!!! Yes, it can get confusing. I think it was Kevin Kofler who suggested to talk about "feature releases" vs. "bugfix releases" instead to avoid confusion. > (KDE versioning is X.Y.Z where X is major, Y is minor and Z is bugfix > release). I disagree. According to kde.org and wikipedia, X.Y is called a major release, and Z is maintainance update. A few quotes: KDE 4.3.0 announcement, http://www.kde.org/ > KDE 4.3.0 released > /.../ KDE 4.3 is the latest major release in the KDE 4 series /.../ KDE standard releases, http://en.wikipedia.or/wiki/KDE#Standard_releases > There are two main types of releases, major releases and maintenance > releases. > Major releases (with two version numbers, for example 3.5) contain > new features. -- Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
On Monday 08 March 2010 10:41:18 Kalev Lember wrote: > On 03/08/2010 11:20 AM, Jaroslav Reznik wrote: > > Major KDE update was in time of Fedora 9, so it's not an issue today. > > > > And this it the first problem - we should not call major, minor, bugfix > > release because it doesn't mean the same for every each app out in the > > wild!!! > > Yes, it can get confusing. I think it was Kevin Kofler who suggested to > talk about "feature releases" vs. "bugfix releases" instead > to avoid confusion. Again you can't cut bugfixes from features :( > > (KDE versioning is X.Y.Z where X is major, Y is minor and Z is bugfix > > release). > > I disagree. According to kde.org and wikipedia, X.Y is called a major > release, and Z is maintainance update. A few quotes: Ah, you're probably right - I've read it somewhere... > KDE 4.3.0 announcement, http://www.kde.org/ > > > KDE 4.3.0 released > > /.../ KDE 4.3 is the latest major release in the KDE 4 series /.../ > > KDE standard releases, http://en.wikipedia.or/wiki/KDE#Standard_releases > > > There are two main types of releases, major releases and maintenance > > releases. > > Major releases (with two version numbers, for example 3.5) contain > > new features. -- Jaroslav Řezník Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
should man-pages-* have Requires: man?
For now in fedora there are 11 packages which contains language
mutations of man-pages (man-pages-{cs,da,de,es,fr,it,ja,ko,pl,ru,uk})
and man-pages package.
Only 2 of them (man-pages-es, man-pages-it) requires man package. I
think man dependences should be consistent in all man-pages* packages.
From my point of view man dependency should be in all of them.
Any ideas?
Ivana Hutarova Varekova
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
On Mon, 8 Mar 2010, Jaroslav Reznik wrote: >> Yes, it can get confusing. I think it was Kevin Kofler who suggested to >> talk about "feature releases" vs. "bugfix releases" instead >> to avoid confusion. > > Again you can't cut bugfixes from features :( Again, you can't cut regressions from features :( To name few, your last push comes with: - kmail that can't anymore 'Add address to book'. - kaddressbook doesn't have 'Merge' feature anymore. - kaddressbook View, Edit, Tools menus are empty. Probably caused by some clitch in configs, which i could not find. Same version ubuntu binaries have them populated. - constant 'whining dialogs' from Akonadi, which probably confuse users. - konqueror RMB-click on tab-header doesn't open tab-menu anymore. Probably caused by fixing the 'rmb against page goes back in history' bug, being a new bug itself. while the previous installed version did not have them. Those are regressions that probably get fixed in coming releases, but are real pita for people providing support and probably have to spend time holding hands and explaining them to users. Someone said it well: You take away the consumer's ability to CHOOSE themselves by pushing features to every release. That ability is very much what UNIX, opensource etc is all about. Tuju -- You want to throw out the baby with the bathwater! - K. Kofler Your baby is my bathwater. I don't want the OS you're building. - J. Keating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
sos update causing PackageKit to barf
The latest sos update is not signed: [hugh...@hughsie-t61 packages]$ rpm -qp sos-1.9-1.fc12.noarch.rpm warning: sos-1.9-1.fc12.noarch.rpm: Header V3 RSA/SHA256 Signature, key ID 57bbccba: NOKEY This causes PackageKit to barf. How come this update was pushed without a signature and all the other are fine? Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: sos update causing PackageKit to barf
On Mon, 8 Mar 2010 10:42:00 +, Richard wrote: > The latest sos update is not signed: > > [hugh...@hughsie-t61 packages]$ rpm -qp sos-1.9-1.fc12.noarch.rpm > warning: sos-1.9-1.fc12.noarch.rpm: Header V3 RSA/SHA256 Signature, > key ID 57bbccba: NOKEY That means you don't have the key installed: $ rpm -Kv sos-1.9-1.fc12.noarch.rpm sos-1.9-1.fc12.noarch.rpm: Header V3 RSA/SHA256 signature: OK, key ID 57bbccba Header SHA1 digest: OK (db9c3b4d1c5a5990e1c4b72cbb4c76d7c65a25e9) V3 RSA/SHA256 signature: OK, key ID 57bbccba MD5 digest: OK (85ddf4a6d8615965a79f06e7f09be84c) $ rpm -q gpg-pubkey-57bbccba gpg-pubkey-57bbccba-4a6f97af > This causes PackageKit to barf. How come this update was pushed > without a signature and all the other are fine? It is signed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
Am Montag, den 08.03.2010, 12:27 +0200 schrieb Juha Tuomala: > Again, you can't cut regressions from features :( > > To name few, your last push comes with: > - kmail that can't anymore 'Add address to book'. > - kaddressbook doesn't have 'Merge' feature anymore. > - kaddressbook View, Edit, Tools menus are empty. Probably caused by >some clitch in configs, which i could not find. Same version >ubuntu binaries have them populated. > - constant 'whining dialogs' from Akonadi, which probably confuse users. > - konqueror RMB-click on tab-header doesn't open tab-menu anymore. >Probably caused by fixing the 'rmb against page goes back in >history' bug, being a new bug itself. Have you filed *all* of them in bugzilla? This is important, otherwise the KDE SIG wont be able to see how many regressions were introduced. TIA, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: sos update causing PackageKit to barf
On 8 March 2010 10:59, Michael Schwendt wrote: > That means you don't have the key installed: This is a fresh F13 pre-alpha spin, updated last a few days ago. > $ rpm -Kv sos-1.9-1.fc12.noarch.rpm > sos-1.9-1.fc12.noarch.rpm: > Header V3 RSA/SHA256 signature: OK, key ID 57bbccba > Header SHA1 digest: OK (db9c3b4d1c5a5990e1c4b72cbb4c76d7c65a25e9) > V3 RSA/SHA256 signature: OK, key ID 57bbccba > MD5 digest: OK (85ddf4a6d8615965a79f06e7f09be84c) > > $ rpm -q gpg-pubkey-57bbccba > gpg-pubkey-57bbccba-4a6f97af > It is signed. Sure, but doesn't 57BBCCBA indicate that it's a F12 signed package, not a F13 signed package? I don't appear to have the 4a6f97af signature installed by default on my fresh F13 (not upgraded from F12) workstation. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: selinux-policy-targeted update failure
On 7 March 2010 20:18, Neal Becker wrote: > Updating : selinux-policy-targeted-3.6.32-92.fc12.noarch > 64/215 > libsepol.scope_copy_callback: audioentropy: Duplicate declaration in module: > type/attribute entropyd_var_ru\ > n_t (No such file or directory). > libsemanage.semanage_link_sandbox: Link packages failed (No such file or > directory). > semodule: Failed! > > There is one bug already for Fedora11 package with same version [1], follow up there and check if this has also been reported for F12. https://bugzilla.redhat.com/show_bug.cgi?id=511067 -- Rakesh Pandit https://fedoraproject.org/wiki/User:Rakesh freedom, friends, features, first -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Announcing `gold-rebuild' - link your packages with gold now
Past months I spent investigating `gold' - the new GNU linker and how it now works with stock Fedora packages. Result is `gold-rebuild', Bash script which automates `gold's involvement in Mock buildroot. Tarball can be obtained here: http://mnowak.fedorapeople.org/gold-rebuild/dist/ What it can do for you? You give it package name or comps group to rebuild and it downloads binutils daily snapshot, incorporates it into latest Rawhide binutils SRPM and builds it with `gold' instead of usual `ld' as a /usr/bin/ld. Such resulting RPM packages are placed in local repository and are used in Mock later when building (linking) you selected package or comps group. Documentation lives here: https://fedoraproject.org/wiki/GoldLinking Script has its limitations and catches but should work fine at i686 and x86_64 (PPC seems to be broken) on Fedora 12 and 13. So far when rebuilding Base group: TOTAL: 99 PASS: 84 FAIL: 15 See attachment for complete list. Regarding fails, they are being classified by the script so you can easily figure out, where might be the problem (GCC v. gold v. fedora). It would be wise to contact your package upstream with patches regarding gold-instead-of-ld usage. Regarding passes: It just says package can be compiled and linked by gold. No one`s claiming the binaries are 100% OK and working :) (in sources testsuite such as prelink claims it might not ~ but prelink is likely special case). Let me know if you came across bugs in this script or you think it should have some sort of improvement you need. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Announcing `gold-rebuild' - link your packages with gold now
- "Michal Nowak" wrote: > See attachment for complete list. Regarding fails, they are being Here is comes. Michal[ GROUP @Base PACKAGES REBUILD ] ld: CVS snapshot from date: 20100303 gcc: gcc-4.4.3-4.fc12 (likely, just a guess) kernel: Linux assam 2.6.32.9-67.fc12.x86_64 #1 SMP Sat Feb 27 09:26:40 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux (from this machine) [1/99] Package: hardlink-1.0-9.fc12 Time: 2:15.40 Size: 28K Status:PASS [2/99] Package: crontabs-1.10-31.fc12 Time: 0:34.05 Size: 12K Status:PASS [3/99] Package: mkbootdisk-1.5.4-1.fc12 Time: 0:34.40 Size: 12K Status:PASS [4/99] Package: unix2dos-2.2-34.fc12 Time: 0:29.90 Size: 36K Status:PASS [5/99] Package: rdate-1.4-14.fc12 Time: 0:33.66 Size: 28K Status:PASS [6/99] Package: prctl-1.4-5.2.1 Error type: FEDORA/NO_SUITABLE_ARCH Error msg: Mock Version: 1.0.5 ENTER do(['bash', '--login', '-c', 'rpmbuild -bs --target x86_64 --nodeps builddir/build/SPECS/prctl.spec'], False, '/var/lib/mock/fedora-12-x86_64/root/', None, 0, True, 0, 0, 492, None, logger=) Executing command: ['bash', '--login', '-c', 'rpmbuild -bs --target x86_64 --nodeps builddir/build/SPECS/prctl.spec'] Building target platforms: x86_64 Building for target x86_64 Wrote: /builddir/build/SRPMS/prctl-1.4-5.2.1.src.rpm LEAVE do --> ENTER do(['bash', '--login', '-c', 'rpmbuild -bb --target x86_64 --nodeps builddir/build/SPECS/prctl.spec'], False, '/var/lib/mock/fedora-12-x86_64/root/', None, 0, True, 0, 0, 492, None, logger=) Executing command: ['bash', '--login', '-c', 'rpmbuild -bb --target x86_64 --nodeps builddir/build/SPECS/prctl.spec'] error: Architecture is not included: x86_64 Building target platforms: x86_64 Building for target x86_64 EXCEPTION: Command failed. See logs for output. Status:FAIL [7/99] Package: yum-updatesd-0.9-3.fc12 Time: 0:39.40 Size: 24K Status:PASS [8/99] Package: dos2unix-3.1-36.fc12 Time: 0:29.90 Size: 36K Status:PASS [9/99] Package: bridge-utils-1.2-8.fc12 Time: 0:38.45 Size: 60K Status:PASS [10/99] Package: pam_passwdqc-1.0.5-4.fc12 Time: 0:35.33 Size: 76K Status:PASS [11/99] Package: irqbalance-0.55-25.fc12 Time: 0:55.55 Size: 84K Status:PASS [12/99] Package: finger-0.17-39.fc12 Time: 0:33.55 Size: 88K Status:PASS [13/99] Package: authd-1.4.3-28.fc12 Time: 0:35.67 Size: 84K Status:PASS [14/99] Package: pcmciautils-015-4.fc12 Time: 0:38.65 Size: 92K Status:PASS [15/99] Package: talk-0.17-33.2.4 Error type: PKG/UNDEF_REFER Error msg: /usr/bin/ld: display.o: in function do_quit:display.c:629: error: undefined reference to 'LINES' /usr/bin/ld: display.o: in function do_quit:display.c:630: error: undefined reference to 'stdscr' /usr/bin/ld: display.o: in function dorefresh:display.c:211: error: undefined reference to 'stdscr' /usr/bin/ld: display.o: in function dorefresh:display.c:213: error: undefined reference to 'LINES' /usr/bin/ld: display.o: in function dorefresh:display.c:217: error: undefined reference to 'COLS' /usr/bin/ld: display.o: in function dorefresh:display.c:217: error: undefined reference to 'acs_map' /usr/bin/ld: display.o: in function middle_message:display.c:615: error: undefined reference to 'COLS' /usr/bin/ld: display.o: in function middle_message:display.c:618: error: undefined reference to 'stdscr' /usr/bin/ld: display.o: in function init_window:display.c:112: error: undefined reference to 'COLS' /usr/bin/ld: display.o: in function real_init_display:display.c:128: error: undefined reference to 'COLS' /usr/bin/ld: display.o: in function real_init_display:display.c:128: error: undefined reference to 'LINES' /usr/bin/ld: display.o: in function real_init_display:display.c:147: error: undefined reference to 'cbreak' collect2: make[1]: Leaving directory `/builddir/build/BUILD/netkit-ntalk-0.17/talk' ld returned 1 exit status make[1]: *** [talk] Error 1 EXCEPTION: Command failed. See logs for output. Status:FAIL [16/99] Package: gpart-0.1h-12.fc12 Error type: FEDORA/NO_SUITABLE_ARCH Error msg: Mock Version: 1.0.5 ENTER do(['bash', '--login', '-c', 'rpmbuild -bs --target x86_64 --nodeps builddir/build/SPECS/gpart.spec'], False, '/var/lib/mock/fedora-12-x86_64/root/', None, 0, True, 0, 0, 492, None, logger=) Executing command: ['bash', '--login', '-c', 'rpmbuild -bs --target x86_64 --nodeps builddir/build/SPECS/gpart.spec'] Building target platforms: x86_64 Building for target x86_64 Wrote: /builddir/build/SRPMS/gpart-0.1h-12.fc12.src.rpm LEAVE do --> ENTER do(['bash', '--login', '-c', 'rpmbuild -bb --target x86_64 --nodeps builddir/build/SPECS/gpart.spec'], False, '/var/lib/mock/fedora-12-x86_64/root/', None, 0, True, 0, 0, 492, None, logger=) Executing command: ['bash', '--login', '-c', 'rpmbuild -bb --target x86_64 --nodeps builddir/build/SPECS/gpart.spec'] error: Architecture is not included: x86_64 Bu
Re: Announcing `gold-rebuild' - link your packages with gold now
On Mon, Mar 08, 2010 at 06:44:18AM -0500, Michal Nowak wrote: > So far when rebuilding Base group: TOTAL: 99 PASS: 84 FAIL: 15 > See attachment for complete list. Regarding fails, they are being > classified by the script so you can easily figure out, where might > be the problem (GCC v. gold v. fedora). It would be wise to contact > your package upstream with patches regarding gold-instead-of-ld usage. > Regarding passes: It just says package can be compiled and linked by > gold. No one`s claiming the binaries are 100% OK and working :) > (in sources testsuite such as prelink claims it might not ~ but prelink > is likely special case). Well, not a special case. Currently all gold linked binaries and libraries are just not prelinkable at all. gold author is aware of it and said he'd fix it. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: sos update causing PackageKit to barf
On Mon, 8 Mar 2010 11:20:45 +, Richard wrote: > > That means you don't have the key installed: > > This is a fresh F13 pre-alpha spin, updated last a few days ago. > > > $ rpm -Kv sos-1.9-1.fc12.noarch.rpm > > sos-1.9-1.fc12.noarch.rpm: > > Header V3 RSA/SHA256 signature: OK, key ID 57bbccba > > Header SHA1 digest: OK (db9c3b4d1c5a5990e1c4b72cbb4c76d7c65a25e9) > > V3 RSA/SHA256 signature: OK, key ID 57bbccba > > MD5 digest: OK (85ddf4a6d8615965a79f06e7f09be84c) > > > > $ rpm -q gpg-pubkey-57bbccba > > gpg-pubkey-57bbccba-4a6f97af > > It is signed. > > Sure, but doesn't 57BBCCBA indicate that it's a F12 signed package, > not a F13 signed package? True. It's a build inherited from F12, 2010-02-17, and should have been resigned appropriately: http://lists.fedoraproject.org/pipermail/test/2010-February/088750.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Karma threshold for kernel
Hi, what kind of karma threshold is set for the kernel? The page in bodhi says it has a karma of 9, but if you count it, it's 13+ and 10- And the kernel got -5 since it's pushed to stable. Shouldn't that one stay out of stable for now? https://admin.fedoraproject.org/updates/kernel-2.6.32.9-67.fc12 I'm running 2.6.32.9-70 meanwhile from updates-testing. -- LG Thomas Dubium sapientiae initium -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Karma threshold for kernel
On Mon, Mar 08, 2010 at 01:36:18PM +0100, Thomas Janssen wrote: >Hi, > >what kind of karma threshold is set for the kernel? > >The page in bodhi says it has a karma of 9, but if you count it, it's >13+ and 10- > >And the kernel got -5 since it's pushed to stable. Shouldn't that one >stay out of stable for now? 1) Anonymous karma doesn't count towards the karma totals. 2) Karma after it goes to stable is good for informational purposes, but it will not cause an update to get removed from Stable. We don't back out updates after that are pushed stable except in very rare cases. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
howto group push?
mercurial and tortoise-hg need (generally) to be pushed in sync. They are maintained by 2 different people. What are suggested ways to make sure pushes are synchronized? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: howto group push?
On Mon, Mar 08, 2010 at 08:09:43AM -0500, Neal Becker wrote: >mercurial and tortoise-hg need (generally) to be pushed in sync. They >are maintained by 2 different people. What are suggested ways to make sure >pushes are synchronized? The maintainers should coordinate, and one of them should bundle both packages into a single bodhi update. It's the only way to guarantee they get pushed at the same time. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Should %{name}-javadoc package require %{name}?
Hello All!
I just found that many java-related packages have packaging issues,
and one of them draws my attention - explicit "Requires: %{name} =
%{version}-%{release}" in some *-javadoc packages. Since my java
experience is rather small, I would like to ask you, dear List,
whether %{name}-javadoc sub-packages really must require %{name}?
--
With best regards, Peter Lemenkov.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: howto group push?
On Mon, 2010-03-08 at 08:20 -0500, Josh Boyer wrote: > The maintainers should coordinate, and one of them should bundle both packages > into a single bodhi update. It's the only way to guarantee they get pushed at > the same time. > > josh They would need commit rights for both packages. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: howto group push?
leigh scott wrote: > On Mon, 2010-03-08 at 08:20 -0500, Josh Boyer wrote: > >> The maintainers should coordinate, and one of them should bundle both >> packages >> into a single bodhi update. It's the only way to guarantee they get >> pushed at the same time. >> >> josh > > They would need commit rights for both packages. > > > > IIRC, wasn't there some kind of 'group push' operation to make sure they are both updated together? Is is reasonable that they may be out-of-sync in updates-testing (temporarily), but when pushed to stable they are pushed as a group? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Push an update to F-13
What is the new process to push an update to F-13 between alpha and beta? The packages I have in mind are out of the set of critical packages. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Announcing `gold-rebuild' - link your packages with gold now
On 8 March 2010 11:44, Michal Nowak wrote: > Past months I spent investigating `gold' - the new GNU linker > and how it now works with stock Fedora packages. Using gold, I get: /usr/bin/ld: --no-add-needed: unknown option /usr/bin/ld: use the --help option for usage information collect2: ld returned 1 exit status This is with fully updated F13. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: should man-pages-* have Requires: man?
Le Lundi 8 Mars 2010 11:25:40, Ivana Hutarova Varekova a écrit :
> For now in fedora there are 11 packages which contains language
> mutations of man-pages (man-pages-{cs,da,de,es,fr,it,ja,ko,pl,ru,uk})
> and man-pages package.
> Only 2 of them (man-pages-es, man-pages-it) requires man package. I
> think man dependences should be consistent in all man-pages* packages.
> From my point of view man dependency should be in all of them.
> Any ideas?
Fully agree.
Regards,
Alain
--
La version française des pages de manuel Linux
http://manpagesfr.free.fr
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: howto group push?
On Mon, Mar 08, 2010 at 08:28:29AM -0500, Neal Becker wrote: >leigh scott wrote: > >> On Mon, 2010-03-08 at 08:20 -0500, Josh Boyer wrote: >> >>> The maintainers should coordinate, and one of them should bundle both >>> packages >>> into a single bodhi update. It's the only way to guarantee they get >>> pushed at the same time. > >IIRC, wasn't there some kind of 'group push' operation to make sure they are >both updated together? Pushes are done on whatever is submitted at the time for the various updates repo targets. If both packages happen to be in the same push request, they'll get pushed at the same time. However, the only way to guarantee that is to bundle them in the same update. >Is is reasonable that they may be out-of-sync in updates-testing >(temporarily), but when pushed to stable they are pushed as a group? Not really. If they aren't in lock-step in updates-testing then you'll have broken deps there (or just broken packages). josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: howto group push?
On Mon, Mar 08, 2010 at 01:22:48PM +, leigh scott wrote: >On Mon, 2010-03-08 at 08:20 -0500, Josh Boyer wrote: > >> The maintainers should coordinate, and one of them should bundle both >> packages >> into a single bodhi update. It's the only way to guarantee they get pushed >> at >> the same time. >> >> josh > >They would need commit rights for both packages. There are ways to work with that. Provenpackagers, CVS Admins, etc. Even if one of them does require commits to both, it seems fairly warranted in this case given the dependent nature of the two packages in question. Cooperation is good. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: selinux-policy-targeted update failure
On 03/07/2010 09:48 AM, Neal Becker wrote: > Updating : selinux-policy-targeted-3.6.32-92.fc12.noarch > 64/215 > libsepol.scope_copy_callback: audioentropy: Duplicate declaration in module: > type/attribute entropyd_var_ru\ > n_t (No such file or directory). > libsemanage.semanage_link_sandbox: Link packages failed (No such file or > directory). > semodule: Failed! > > > This should have executed in the post install # semodule -n -s targeted -r moilscanner -r mailscanner -r gamin -r audio_entropy -r iscsid -r polkit_auth -r polkit -r rtkit_daemon -r ModemManager Could you execute it and try again? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Announcing `gold-rebuild' - link your packages with gold now
Michal Nowak writes: > Past months I spent investigating `gold' - the new GNU linker > and how it now works with stock Fedora packages. > [...] Do your scripts provide some evidence of exciting speedups with gold? - FChE -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Announcing `gold-rebuild' - link your packages with gold now
On Mon, Mar 08, 2010 at 09:24:29AM -0500, Frank Ch. Eigler wrote: > Michal Nowak writes: > > > Past months I spent investigating `gold' - the new GNU linker > > and how it now works with stock Fedora packages. > > [...] > > Do your scripts provide some evidence of exciting speedups with gold? Or slowdowns? Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Karma threshold for kernel
On Mon, Mar 8, 2010 at 2:00 PM, Josh Boyer wrote: > On Mon, Mar 08, 2010 at 01:36:18PM +0100, Thomas Janssen wrote: >>Hi, >> >>what kind of karma threshold is set for the kernel? >> >>The page in bodhi says it has a karma of 9, but if you count it, it's >>13+ and 10- >> >>And the kernel got -5 since it's pushed to stable. Shouldn't that one >>stay out of stable for now? > > 1) Anonymous karma doesn't count towards the karma totals. Ah, got it, thanks. > 2) Karma after it goes to stable is good for informational purposes, but it > will not cause an update to get removed from Stable. We don't back out > updates > after that are pushed stable except in very rare cases. Stupid me. I thought it's not yet in stable. -- LG Thomas Dubium sapientiae initium -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Push an update to F-13
On 08/03/10 13:29, Laurent Rineau wrote: > What is the new process to push an update to F-13 between alpha and beta? The > packages I have in mind are out of the set of critical packages. The same process you would use to push an update to F-12 - Bodhi. Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 Branched report: 20100306 changes
On Sat, 2010-03-06 at 19:32 +, Branched Report wrote: > > Updated Packages: > > avrdude-5.10-1.fc12 > --- > * Fri Feb 19 2010 Bart Vanbrabant - 5.10-1 > - New upstream version. Several new devices and programmers supported. Some > bugfixes and a new features to apply external reset if JTAG ID could not be > read. > > man-pages-it-2.80-5.fc12 > > * Wed Mar 03 2010 Ding-Yi Chen - 2.80-5 > - Resolves: #560507 [man-pages-it] Package wrangler fix > - Remove comments of extra subpackage, as upstream already merge > them. > > * Mon Feb 01 2010 Ding-Yi Chen - 2.80-4 > - Resolves: #560507 > [man-pages-it] Package wrangler fix > - Remove comments of extra subpackage, as upstream already merge them. > > * Mon Nov 30 2009 Dennis Gregorovic - 2.80-3.1 > - Rebuilt for RHEL 6 > sos-1.9-1.fc12 > -- > * Wed Feb 17 2010 Adam Stokes = 1.9-1 > - version bump 1.9 > - replaced compression utility with xz > - strip threading/multiprocessing > - simplified progress indicator > - pylint update > - put global vars in class container > - unittests > - simple profiling > - make use of xgettext as pygettext is deprecated > The report lists 3 fc12 packages as updates for F-13. Doing a yum update of avrdude shows the new version as 5.10-2.fc13 and not 5.10-1.fc12 as listed. For man-pages-it, yum update lists 2.80-5.fc13 and not 2.80-5.fc12 as listed. For sos, yum attempts to update to the listed version, i.e. 1.9-1.fc12 but then produces the following error: warning: rpmts_HdrFromFdno: Header V3 RSA/SA256 Signature, key ID 57bbccba: NOKEY Public key for sos-1.9-1.fc12.noarch.rpm is not installed -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Karma threshold for kernel
Josh Boyer wrote: > 2) Karma after it goes to stable is good for informational purposes, but it > will not cause an update to get removed from Stable. We don't back out > updates > after that are pushed stable except in very rare cases. I'll ask again: Why does bodhi accept karma or comments after the stable push has been made? It just causes email spam. There's one guy who has been submitted the same bogus comment and negative karma for abrt for the past week. An abrt update that has long since been pushed. I see it happen every time for the kernel updates as well. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Harmless KDE feature upgrades - yeah right
A segfaulty version of KDE filelight seems to have been pushed into F13, F12 and (astonishingly) F11. Just filing a bug about that one ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Karma threshold for kernel
On Mon, Mar 08, 2010 at 08:55:34AM -0600, Michael Cronenworth wrote: >Josh Boyer wrote: >> 2) Karma after it goes to stable is good for informational purposes, but it >> will not cause an update to get removed from Stable. We don't back out >> updates >> after that are pushed stable except in very rare cases. > > >I'll ask again: > >Why does bodhi accept karma or comments after the stable push has been >made? It just causes email spam. There's one guy who has been submitted >the same bogus comment and negative karma for abrt for the past week. An >abrt update that has long since been pushed. I see it happen every time >for the kernel updates as well. Because nobody has fixed: https://fedorahosted.org/bodhi/ticket/358 https://fedorahosted.org/bodhi/ticket/185 Patches for those would be very welcome I think. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
How does one deal with obsoleted updates from updates-testing
My F-13 system produces the following output from yum list extras: Extra Packages glibc.i686 2.11.90-14 installed glibc-common.i686 2.11.90-14 installed glibc-devel.i686 2.11.90-14 @updates-testing glibc-headers.i686 2.11.90-14 @updates-testing gtksourceview2.i6862.9.7-1.fc13 installed nscd.i686 2.11.90-14 installed The glibc packages (including nscd) were in updates-testing, but have been obsoleted, and so 2.11.90-12 is now the current version again. What is the mechanism for becoming aware that a package that has been installed through updates-testing has been obsoleted (especially since the standard install of F-13 rc has updates-testing enabled)? Bodhi doesn't even list gtksourceview2-2.9.7-1.fc13, so I can't see where that came from, but the current version for F-13 appears to be 2.9.5-1.fc13. Also, why are some packages listed as @updates-testing and others as installed when all the packages are installed? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How does one deal with obsoleted updates from updates-testing
On Mon, 8 Mar 2010, Quentin Armitage wrote: > The glibc packages (including nscd) were in updates-testing, but have > been obsoleted, and so 2.11.90-12 is now the current version again. What > is the mechanism for becoming aware that a package that has been > installed through updates-testing has been obsoleted (especially since > the standard install of F-13 rc has updates-testing enabled)? They've not been obsoleted, they've just been updated. Obsoleted has a different special meaning in rpm-parlance. > Bodhi doesn't even list gtksourceview2-2.9.7-1.fc13, so I can't see > where that came from, but the current version for F-13 appears to be > 2.9.5-1.fc13. > > Also, why are some packages listed as @updates-testing and others as > installed when all the packages are installed? Depends on which version of yum they were installed with. If the version is older than yum 3.2.25 - then it won't list the repo they were installed from in a 'yum list installed'. if it was 3.2.25 or newer, it will. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
What are the rules for which package we build against in F-13?
So I submitted a rebuild for libguestfs in F-13 (just now). This was built against: plymouth-core-libs 0.8.0-0.20100114.2.fc13 But the version of plymouth that I get when I install plymouth from F-13 updates-testing on a local machine (after 'yum --enablerepo=\* clean all') is: plymouth-core-libs 0.8.0-0.20100225.1.fc13 and neither of those versions is mentioned by Bodhi. Bodhi seems to suggest that it should be building against and using another version entirely: https://admin.fedoraproject.org/updates/search/plymouth plymouth-0.8.0-0.20100305.1.fc13 I'm confused by this situation ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are the rules for which package we build against in F-13?
On Mon, Mar 08, 2010 at 03:29:37PM +, Richard W.M. Jones wrote: > >So I submitted a rebuild for libguestfs in F-13 (just now). This >was built against: > >plymouth-core-libs 0.8.0-0.20100114.2.fc13 Yes, that's what in dist-f13. You can view this with: koji latest-pkg dist-f13 or for the buildroot explicitly: koji latest-pkg dist-f13-build >But the version of plymouth that I get when I install plymouth from >F-13 updates-testing on a local machine (after >'yum --enablerepo=\* clean all') is: > >plymouth-core-libs 0.8.0-0.20100225.1.fc13 Updates-testing packages aren't included in the buildroot. >and neither of those versions is mentioned by Bodhi. Bodhi seems to >suggest that it should be building against and using another version >entirely: > >https://admin.fedoraproject.org/updates/search/plymouth >plymouth-0.8.0-0.20100305.1.fc13 Bodhi doesn't suggest what you build against at all. It's just saying that the latest submitted plymouth package is that one. >I'm confused by this situation ... The buildroots are populated from packages in the: dist-f13 dist-f13-override dist-f12-updates tags. If a package isn't in one of those tags, it's not going to be in the buildroot. If you need to build against a newer version of a package, then you need to file a ticket on the rel-eng trac instance asking for a buildroot override (which will get it tagged into dist-f13-override). josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are the rules for which package we build against in F-13?
On Mon, Mar 08, 2010 at 10:37:43AM -0500, Josh Boyer wrote: > The buildroots are populated from packages in the: > > dist-f13 > dist-f13-override > dist-f12-updates > > tags. If a package isn't in one of those tags, it's not going to be in the > buildroot. If you need to build against a newer version of a package, then > you > need to file a ticket on the rel-eng trac instance asking for a buildroot > override (which will get it tagged into dist-f13-override). OK thanks, good explanation. It looks like I'll need to file a ticket in that case. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update question: some user data
On Mon, 2010-03-08 at 10:27 +0100, Nicolas Mailhot wrote: > > Le Sam 6 mars 2010 20:04, Adam Williamson a écrit : > > > The numbers do surprise me, to be honest. As I write this, it's 34-8 - > > that's over 80% - in favour of 'adventurous' updates. > > Advanced users (those most likely to want a more stable rawhide to use it as > primary system) use irc, mailing lists, bugzilla, etc. Normal users (those > that need a stable Fedora so they can spend their time writing apps, doing > i18n, etc) do not read Fedora forums (if they had this kind of time they would > not object to adventurous time-wasting updates). I don't think that's an assertion you have any kind of evidence to support. It's really quite sad that half the people who've responded to the poll have done so by attempting to poke holes in it, as it happens not to line up with what they think. If you think the poll is wrong - provide some data to disprove it. Counteracting it with yet more assertions built on precisely no evidence is not convincing. > About the only population likely to read Fedora forums regularly are tinkerers > that have not moved to the advanced stage and its communication channels, Wow, condescending much? -- 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
[Bug 570979] UTF8 PO files not being read as UTF8
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=570979 --- Comment #3 from Iain Arnell 2010-03-08 11:07:52 EST --- Sorry, all, I'm not trying to be difficult, but I know that upstream is hesitant when it comes to changing existing behaviour (see his comments in pod regarding quoted vs. non-quoted strings), so I'm also very reluctant to introduce a patch that could easily break things for existing code that expects to get unencoded strings. If there's no movement on this upstream, I'll happily consider a patch that extends existing behaviour. Maybe a new set of load_file/save_file methods that handle automatic detection of encoding; or an optional parameter to existing methods; or allow file handles to be passed instead of file names; or whatever. -- 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
rawhide report: 20100308 changes
Compose started at Mon Mar 8 08:15:10 UTC 2010 Broken deps for i386 -- ale-0.9.0.3-2.fc12.i686 requires libMagickCore.so.2 autotrace-0.31.1-23.fc12.i686 requires libMagickCore.so.2 blahtexml-0.6-5.fc12.i686 requires libxerces-c.so.28 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 gdl-0.9-0.10.rc4.fc13.i686 requires libMagick++.so.2 gdl-0.9-0.10.rc4.fc13.i686 requires libMagickCore.so.2 gdl-python-0.9-0.10.rc4.fc13.i686 requires libMagick++.so.2 gdl-python-0.9-0.10.rc4.fc13.i686 requires libMagickCore.so.2 hornsey-1.5.2-0.1.fc13.i686 requires libclutter-gst-0.10.so.0 imageinfo-0.05-10.fc12.i686 requires libMagickCore.so.2 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 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 nip2-7
Re: selinux-policy-targeted update failure
On Monday 08 March 2010, Daniel J Walsh wrote: > On 03/07/2010 09:48 AM, Neal Becker wrote: > > Updating : selinux-policy-targeted-3.6.32-92.fc12.noarch > > > > 64/215 > > libsepol.scope_copy_callback: audioentropy: Duplicate declaration in > > module: type/attribute entropyd_var_ru\ > > n_t (No such file or directory). > > libsemanage.semanage_link_sandbox: Link packages failed (No such file or > > directory). > > semodule: Failed! > > This should have executed in the post install > > # semodule -n -s targeted -r moilscanner -r mailscanner -r gamin -r > audio_entropy -r iscsid -r polkit_auth -r polkit -r rtkit_daemon -r > ModemManager > > Could you execute it and try again? sudo semodule -n -s targeted -r moilscanner -r mailscanner -r gamin -r audio_entropy -r iscsid -r polkit_auth -r polkit -r rtkit_daemon -r ModemManager libsemanage.semanage_direct_remove: Module moilscanner was not found. libsemanage.semanage_direct_remove: Module mailscanner was not found. libsemanage.semanage_direct_remove: Module gamin was not found. libsemanage.semanage_direct_remove: Module audio_entropy was not found. libsemanage.semanage_direct_remove: Module iscsid was not found. libsemanage.semanage_direct_remove: Module polkit_auth was not found. libsemanage.semanage_direct_remove: Module polkit was not found. libsemanage.semanage_direct_remove: Module rtkit_daemon was not found. libsemanage.semanage_direct_remove: Module ModemManager was not found. semodule: Failed! Note selinux is disabled. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Managing spec files
Hi All, I am looking at building a fedora package. I have been over guidelines and taken a look at the build system. What I am not clear on is how I maintain spec files for different distributions i.e., F12, F11, F10, or even EPEL. Do I have to branch and maintain each spec file separately or is there a better way? Are there any tools that abstract the commonality? Do people try to write spec files that work on any distro with conditionals? Thanks for any wise words, Matt. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Managing spec files
On Mon, Mar 8, 2010 at 5:50 PM, Matt Ford wrote: > Hi All, > > I am looking at building a fedora package. I have been over guidelines > and taken a look at the build system. What I am not clear on is how I > maintain spec files for different distributions i.e., F12, F11, F10, or > even EPEL. Initially to have a package added in principal it only has to work on rawhide for release with the next release. > > Do I have to branch and maintain each spec file separately or is there a > better way? Are there any tools that abstract the commonality? Do > people try to write spec files that work on any distro with conditionals? > It is true that the separate .spec files are maintained separately. What many people try and do is maintain them as identical, at least at the start. Have a look at: http://fedoraproject.org/wiki/Packaging/DistTag#Conditionals of course with time with different update policies it will happen that say EPEL and rawhide .specs diverge. > Thanks for any wise words, > > Matt. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- Steve Traylen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update question: some user data
Le Lun 8 mars 2010 17:05, Adam Williamson a écrit : > I don't think that's an assertion you have any kind of evidence to > support. It's really quite sad that half the people who've responded to > the poll have done so by attempting to poke holes in it, as it happens > not to line up with what they think. Adam, if you can't realise that the users most likely to haunt a support forum are the people most likely to break their setup regularly by being "adventurous", I don't see what can convince you. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update question: some user data
On 03/08/2010 11:05 AM, Adam Williamson wrote: > On Mon, 2010-03-08 at 10:27 +0100, Nicolas Mailhot wrote: >> >> Le Sam 6 mars 2010 20:04, Adam Williamson a écrit : >> >>> The numbers do surprise me, to be honest. As I write this, it's 34-8 - >>> that's over 80% - in favour of 'adventurous' updates. >> >> Advanced users (those most likely to want a more stable rawhide to use it as >> primary system) use irc, mailing lists, bugzilla, etc. Normal users (those >> that need a stable Fedora so they can spend their time writing apps, doing >> i18n, etc) do not read Fedora forums (if they had this kind of time they >> would >> not object to adventurous time-wasting updates). > > I don't think that's an assertion you have any kind of evidence to > support. Well, I stand as a data point that matches this assertion (although you could leave out the rhetoric about advanced users and all, the data point of "people that use Fedora to get work done" versus "people that user Fedora to tinker" I think is probably a fairly accurate assessment of what people might or might not be found on Fedora Forums). > It's really quite sad that half the people who've responded to > the poll have done so by attempting to poke holes in it, as it happens > not to line up with what they think. That's not fair. Yes, many have poked holes in the poll, but to be fair, as you said, it's unscientific and it *does* have holes in its methodology. > If you think the poll is wrong - provide some data to disprove it. I'm sorry, but that's a scientifically specious argument. Invalid data doesn't become valid because there is no valid counter data. It is valid or invalid all on its own. To date, no one has run a scientifically valid poll, but that doesn't make your poll any better or worse, it just makes it all by itself. > Counteracting it with yet more assertions built on precisely no evidence > is not convincing. Well, one of the questions to be asked before going any further on this is what audience do we care about? I've heard it over and over again that Fedora is supposed to be a developer's platform, and not a user's platform. If that's true, then the people that should be voting on this is the people that make Fedora, not the people that consume it. If the reverse is true, then it really doesn't matter what the users vote anyway because then it's up to us to decide *which* user segment we wish to target and build the OS to satisfy them. So, are we an OS for the developer or for the user? If the developer, then the poll as it stands is prima fascia broken because the Fedora Forums user base does not directly map to the active fedora developer base. If we are an OS for the developer, then the poll should require a Fedora Account System login to vote, not a Fedora Forums login. If we are an OS for the user, then as I mention, voting is kind of pointless as that just says what user base we *have*, not what we could have or want to have. We would simply decide which niche we wanted to fill and then fill it. Now, as for the wording. It was both subjective and vague. Neither of those leads to a good poll without at a minimum putting in additional questions to narrow down responses. As an example of why I call it subjective and vague, I could have worded the same "adventurous" and "conservative" options as "gratuitous" and "reasonable", and I have no doubt that this wording change would effect the results of the poll (and probably drastically so). To be a valid poll, we have to be precise enough that people know what they are voting on without the wording leading their thoughts. -- Doug Ledford 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
Re: Update question: some user data
On Sat, 2010-03-06 at 13:15 -0700, Kevin Fenzi wrote: > On Sat, 06 Mar 2010 11:04:31 -0800 > Adam Williamson wrote: > > ...snip... > > > What do people make of this? > > I'm no expert on polls/polling, but I suspect that many of the people > who are more interested in a 'stable/less updates' Fedora don't > frequent things like the forums or users list. Sure, they might search > it or post a question when they run into an issue, but they are more > likely to spend their time... well, using their machine. Yeah. This is by no means a representative sampling of Fedora users. The term you're looking for here is selection bias: http://en.wikipedia.org/wiki/Selection_bias Adam's poll results are valid *only* for Fedora users who: a) Are members of the Fedora forum, b) Enthusiasts/power-users to the degree that they would notice a new threads/poll within a day of its posting, and c) Hold a strong enough opinion to feel the need to answer the poll. It seems obvious that this group would lean more towards the adventurous, power-user side of things. Furthermore (as Mike points out later in the thread) the presentation of the poll is also problematic. The choices - "conservative" or "adventurous" - are subjective and each have strong emotional implications. "Conservative" typically has negative connotations, especially among enthusiasts and power-users. Adam, I definitely applaud your effort to gather some actual data on the problem, but the data gathered here is not going to tell us anything we don't already know. If we spent some time designing a more proper survey and chose an actual random representative sampling of Fedora users - random sampling from FAS accounts, website users, forum accounts, bugzilla accounts, etc. - that data might be more relevant. But even then, what will we learn? I'd be willing to wager that the data would distill down to three facts which are already practically axiomatic: 1) Nearly everyone wants Fedora to be as stable as possible. 2) Nearly everyone wants Fedora to be advanced and featureful. 3) Some people are willing to sacrifice stability for features. So the only unknown is: exactly what percentage of our *current* users are willing to accept a loss of stability in favor of New Hotness? But I'm fairly certain this question is *irrelevant*. Our current users' expectations are already set by their past experience with Fedora. If they're still Fedora users, they're willing to accept - and *have* accepted - whatever we're currently doing. In short: I fully support gathering actual data, but I think it would be more useful to gather data to help shape overall *goals*, and work toward those goals. It might also be useful to poll people *outside* our current user/developer base and find out what we'd need to do to attract *new* users and contributors. -w -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should %{name}-javadoc package require %{name}?
On Monday 08 March 2010, Peter Lemenkov wrote:
> Hello All!
>
> I just found that many java-related packages have packaging issues,
> and one of them draws my attention - explicit "Requires: %{name} =
> %{version}-%{release}" in some *-javadoc packages. Since my java
> experience is rather small, I would like to ask you, dear List,
> whether %{name}-javadoc sub-packages really must require %{name}?
No, unless they actually require something from the main package, which would
be unusual.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Upcoming Fedora 13 Schedule
Start End Name Thu 04-Mar Tue 09-Mar Stage & Sync Alpha to Mirrors Tue 09-Mar Tue 09-Mar Alpha Public Availability Tue 09-Mar Tue 23-Mar Alpha Testing Fri 12-Mar Fri 12-Mar Beta Blocker Meeting (F13Beta) #1 Tue 16-Mar Tue 16-Mar Software: Start Rebuild all translated packages Tue 16-Mar Tue 23-Mar Software: Rebuild all translated packages Wed 17-Mar Thu 18-Mar Create Beta Test Compose (TC) Thu 18-Mar Wed 24-Mar Test Beta 'Test Compose' Fri 19-Mar Fri 19-Mar Beta Blocker Meeting (F13Beta) #2 Tue 23-Mar Tue 23-Mar End of Alpha Testing -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should %{name}-javadoc package require %{name}?
From package guideline
Requiring Base Package
Devel packages must require the base package using a fully versioned
dependency: Requires: %{name} = %{version}-%{release}. Usually, subpackages
other than -devel should also require the base package using a fully versioned
dependency.
在2010-03-09 01:42:40，"Ville Skyttä" 写道：
>On Monday 08 March 2010, Peter Lemenkov wrote:
>> Hello All!
>>
>> I just found that many java-related packages have packaging issues,
>> and one of them draws my attention - explicit "Requires: %{name} =
>> %{version}-%{release}" in some *-javadoc packages. Since my java
>> experience is rather small, I would like to ask you, dear List,
>> whether %{name}-javadoc sub-packages really must require %{name}?
>
>No, unless they actually require something from the main package, which would
>be unusual.
>--
>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: Update question: some user data
On Mon, Mar 08, 2010 at 08:05:12AM -0800, Adam Williamson wrote: > If you think the poll is wrong - provide some data to disprove it. > Counteracting it with yet more assertions built on precisely no evidence > is not convincing. The evidence that it's wrong is that it's a self-selected sample set. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
libedit: transferring ownership
I would like to transfer ownership of the libedit package to Kamil Dudka (kdudka). I am a bit wary of PackageDB transferring not letting me select the new owner. Could someone please take care of it or advise what I need to do about this? I do not want to remain as a co-maintainer. Thanks, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
On Mon, Mar 08, 2010 at 12:27:07PM +0200, Juha Tuomala wrote: > > > > On Mon, 8 Mar 2010, Jaroslav Reznik wrote: > >> Yes, it can get confusing. I think it was Kevin Kofler who suggested to > >> talk about "feature releases" vs. "bugfix releases" instead > >> to avoid confusion. > > > > Again you can't cut bugfixes from features :( > > Again, you can't cut regressions from features :( > Two notes: 1) regressions can occur whether you're introducing features or bugfixes in your new version. 2) The novelist in me cringes when we use absolutes. Better wording, which maybe we all understand by now would be: >> KDE upstream releases bugfixes and features in the same release. > KDE releases both fix bugs and introduce new bugs. -Toshio pgpK6zEkJ7aVi.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Managing spec files
On Mar 8, 2010, at 10:59 AM, Steve Traylen wrote: >> > It is true that the separate .spec files are maintained separately. What many > people try and do is maintain them as identical, at least at the start. > Have a look at: > http://fedoraproject.org/wiki/Packaging/DistTag#Conditionals > of course with time with different update policies it will happen that say > EPEL > and rawhide .specs diverge. > Maintaining a single spec with disttag conditionals is great, and makes the world a lot easier *if* you are maintaining the same source version of the package across all distros. Once you split source versions (as Steve said generally with rawhide)... its not really practical to maintain a single spec and you end up with multiple buildroots/specs. --- derks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upcoming Bugzilla Changes
On Sat, 2010-03-06 at 20:07 +0100, Till Maas wrote: > On Fri, Mar 05, 2010 at 08:14:38AM -0800, Adam Williamson wrote: > > On Fri, 2010-03-05 at 13:27 +0100, Till Maas wrote: > > > > > Especially it needs to be made sure that only bugs created prior to > > > adding "F13" to RedHat Bugzilla or the branching of F13, depending on > > > what happened later, are touched by the "Rawhide bug rebase". > > > > We already did that, though tk009 forgot to mention it. If you look at > > the proposed query, it's cut off at the date of the branch announcement. > > The query I was given in IRC does not take into account, which version > was specified when the bug was created. In the other subthread I > provided a script to work around this limitation. I don't see any reason that would be more accurate than considering the current specified version. We've never done that with previous rebase queries. Why do you think it would be more accurate? -- 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: Karma threshold for kernel
On Mon, 8 Mar 2010 10:07:05 -0500, Josh wrote: > On Mon, Mar 08, 2010 at 08:55:34AM -0600, Michael Cronenworth wrote: > >Josh Boyer wrote: > >> 2) Karma after it goes to stable is good for informational purposes, but it > >> will not cause an update to get removed from Stable. We don't back out > >> updates > >> after that are pushed stable except in very rare cases. > > > > > >I'll ask again: > > > >Why does bodhi accept karma or comments after the stable push has been > >made? Because it can be useful to comment on the testing _all_ previous karma submitters have done. Please keep stable update tickets open for further comments. > It just causes email spam. Nah. The same way you could consider all bodhi comments "spam". If you are the first commenter of a popular package, you receive lots of notifications for all subsequent comments (where sometimes people even use bodhi to argue about something). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 569298] Branch perl-Hash-WithDefaults for EPEL
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=569298 --- Comment #1 from Chris Weyl 2010-03-08 13:26:07 EST --- I'm trying to avoid EPEL at the moment, but I have no problems with your branching (and owning those branches of) any of my packages for it. :) -- 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
[Bug 569295] Branch perl-Hash-Case for EPEL
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=569295 --- Comment #1 from Chris Weyl 2010-03-08 13:26:08 EST --- I'm trying to avoid EPEL at the moment, but I have no problems with your branching (and owning those branches of) any of my packages for it. :) -- 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
[Bug 569301] Branch perl-Config-IniHash for EPEL
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=569301 --- Comment #1 from Chris Weyl 2010-03-08 13:26:07 EST --- I'm trying to avoid EPEL at the moment, but I have no problems with your branching (and owning those branches of) any of my packages for it. :) -- 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
[Bug 569299] Branch perl-PerlIO-gzip for EPEL
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=569299 --- Comment #1 from Chris Weyl 2010-03-08 13:26:08 EST --- I'm trying to avoid EPEL at the moment, but I have no problems with your branching (and owning those branches of) any of my packages for it. :) -- 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: Should %{name}-javadoc package require %{name}?
On Monday 08 March 2010, Chen Lei wrote:
> Requiring Base Package
>
> Devel packages must require the base package using a fully versioned
> dependency: Requires: %{name} = %{version}-%{release}. Usually,
> subpackages other than -devel should also require the base package using a
> fully versioned dependency.
It says "usually". But anyway I think the main of this is that *if* the
subpackage requires the main package in the first place, the dependency should
usually be fully versioned; I don't think its intent is to encourage pulling
artificial dependencies out of thin air.
By the way, the same applies to -devel packages so the "must" is a too strong
expression for them although they usually actually do require the main
package. But when they don't, there is no reason to add any dependency to the
main package, versioned or not. (And yes, when they do, it's good to mandate
the dependency to be fully versioned.)
Would not hurt to rephrase this in the guidelines to avoid confusion.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update question: some user data
Last time I looked at the admin logs for Fedoraforum i.e who's voted , there was at least 15 votes from Fedora project members. On Mon, 2010-03-08 at 18:12 +0100, Nicolas Mailhot wrote: > > Adam, if you can't realise that the users most likely to haunt a support forum > are the people most likely to break their setup regularly by being > "adventurous", I don't see what can convince you. > > -- > Nicolas Mailhot > > > -- > 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: How does one deal with obsoleted updates from updates-testing
On Mon, 2010-03-08 at 10:26 -0500, Seth Vidal wrote: > > On Mon, 8 Mar 2010, Quentin Armitage wrote: > > > The glibc packages (including nscd) were in updates-testing, but have > > been obsoleted, and so 2.11.90-12 is now the current version again. What > > is the mechanism for becoming aware that a package that has been > > installed through updates-testing has been obsoleted (especially since > > the standard install of F-13 rc has updates-testing enabled)? > > They've not been obsoleted, they've just been updated. Obsoleted has a > different special meaning in rpm-parlance. > Sorry, I should have been clearer. glibc-2.11.90.14 is showing in Bodhi as being Status: obsolete. Bodhi shows that version was pushed to testing, and it was installed on my system when I installed F-13 on 1st March. That version appears is now no longer in updates-testing, and the current version is the earlier version, glibc-2.11.90-12. So far as I can see, there is no automatic mechanism to become aware of when a package has been in updates-testing and has subsequently been removed (?due to obsoleting in Bodhi), and the package needs reverting to an earlier version. > > > > Bodhi doesn't even list gtksourceview2-2.9.7-1.fc13, so I can't see > > where that came from, but the current version for F-13 appears to be > > 2.9.5-1.fc13. > > I can't see any reference to gtksourceview2-2.9.7-1.fc13 in Bodhi, but it was installed on my F-13 system on 1st March. The current version for F-13 seems to be 2.9.5-1, but I cannot see anything that says gtksourceview2 as been removed. Quentin Armitage -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Managing spec files
BJ Dierkes wrote: > > On Mar 8, 2010, at 10:59 AM, Steve Traylen wrote: > >>> >> It is true that the separate .spec files are maintained separately. What >> many people try and do is maintain them as identical, at least at the >> start. Have a look at: >> http://fedoraproject.org/wiki/Packaging/DistTag#Conditionals >> of course with time with different update policies it will happen that >> say EPEL and rawhide .specs diverge. >> > > Maintaining a single spec with disttag conditionals is great, and makes > the world a lot easier *if* you are maintaining the same source > version of the package across all distros. Once you split source versions > (as Steve said generally with rawhide)... its not really practical to > maintain a single spec and you end up with multiple buildroots/specs. > > --- > derks I always just hard link them together. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Karma threshold for kernel
Michael Schwendt wrote: > Nah. The same way you could consider all bodhi comments "spam". If you > are the first commenter of a popular package, you receive lots of > notifications for all subsequent comments (where sometimes people > even use bodhi to argue about something). Michael, how is posting: u...@radiopresenter.me.uk (unauthenticated) - 2010-03-08 13:36:44 (karma: 0) Error Type: Error Value: Error getting repository data for installed, repository not foundFile : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 3125, in main()File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 3122, in main backend.dispatcher(sys.argv[1:])File : /usr/lib/python2.6/site- packages/packagekit/backend.py, line 710, in dispatcher self.dispatch_command(args[0], args[1:])File : /usr/lib/python2.6/site- packages/packagekit/backend.py, line 657, in dispatch_command self.update_packages(only_trusted, package_ids)File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 1948, in update_packages signed = self._is_package_repo_signed(pkg)File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 1437, in _is_package_repo_signed repo = self.yumbase.repos.getRepo(pkg.repoid) File : /usr/lib/python2.6/site-packages/yum/repos.py, line 121, in getRepo 'Error getting repository data for $s, repository not found' $ (repoid) Multiple times a week not considered spam? Really? Posting this prior to stable pushes is fine -- I never consider it spam. If I could CC you on some of those updates maybe you would change your opinion. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
On Sat, 2010-03-06 at 20:47 -0500, Orcan Ogetbil wrote: > Then make it 3 months, 4 months... Leave it in testing forever if you > get too many complaints. But make it available for those who want it. This is not the purpose of updates-testing, it is not an alternative update repo. It is there for focused testing of packages you - the developer - believe are already ready to be pushed out as updates; basically it's where you send your update 'release candidates' for others to make sure you got it right. If it works, it goes to updates. If not, you unpush it, fix it, and try again. Things should not live there. What you describe is the function of a separate 'backports' style repo, as discussed earlier in the thread. Since we don't have one at present, the best option is to do a scratch build and host it yourself, *not* misuse updates-testing to host a package you have no immediate intention of shipping as an update. The current processes just are not set up for updates-testing to be used for this purpose. -- 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: Another great update
On Sat, 2010-03-06 at 22:17 -0500, Orcan Ogetbil wrote: > And as you obviously didn't finish reading my sentence, that is not > the only solution I proposed. Read again, there is a 0 additional repo > proposal too. Having multiple package versions in a single repository is essentially like having multiple repositories, only much worse managed... -- 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
F-13 Branched report: 20100308 changes
Compose started at Mon Mar 8 09:15:17 UTC 2010 Broken deps for i386 -- blahtexml-0.6-5.fc12.i686 requires libxerces-c.so.28 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 koan-2.0.3.1-1.fc13.noarch requires mkinitrd 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/libglib-2.0.so.0.2303.0 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/libgio-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgmodule-2.0.so.0.2303.0 libvirt-qpid-0.2.17-3.fc12.i686 requires qpidc >= 0:0.5.790661 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 matahari-0.0.4-7.fc13.i686 requires qpidc >= 0:0.5.819819 ovirt-server-0.100-4.fc12.noarch requires qpidd ovirt-server-0.100-4.fc12.noarch requires qpidc php-facedetect-1.0.0-4.fc13.i686 requires libhighgui.so.2.0 php-facedetect-1.0.0-4.fc13.i686 requires libcvaux.so.2.0 php-facedetect-1.0.0-4.fc13.i686 requires libcv.so.2.0 php-facedetect-1.0.0-4.fc13.i686 requires libcxcore.so.2.0 player-3.0.1-5.fc13.i686 requires libml.so.2.0 player-3.0.1-5.fc13.i686 requires libhighgui.so.2.0 player-3.0.1-5.fc13.i686 requires libcxcore.so.2.0 player-3.0.1-5.fc13.i686 requires libcv.so.2.0 player-3.0.1-5.fc13.i686 requires libcvaux.so.2.0 qmf-devel-0.5.819819-4.fc13.i686 requires qpidc-client-devel = 0:0.5.819819-4.fc13 qpidc-server-devel-0.5.819819-4.fc13.i686 requires qpidc-client-devel = 0:0.5.819819-4.fc13 qpidc-server-rdma-0.5.819819-4.fc13.i686 requires qpidc-client-rdma = 0:0.5.819819-4.fc13 qpidc-server-ssl-0.5.819819-4.fc13.i686 requires qpidc-client-ssl = 0:0.5.819819-4.fc13 zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 Broken deps for x86_64 -- blahtexml-0.6-5.fc12.x86_64 requires libxerces-c.so.28()(64bit) 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) koan-2.0.3.1-1.fc13.noarch requires mkinitrd 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/libglib-2.0.so.0.2303.0 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/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/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 libvirt-qpid-0.2.17-3.fc12.x86_64 requires qpidc >= 0:0.5.790661 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit) matahari-0.0.4-7.fc13.x86_64 requires qpidc >= 0:0.5.819819 ovirt-server-0.100-4.fc12.noarch requires qpidd ovirt-server-0.100-4.fc12.noarch requires qpidc php-facedetect-1.0.0-4.fc13.x86_64 requires libcv.so.2.0()(64bit) php-facedetect-1.0.0-4.fc13.x86_64 requires libcxcore.so.2.0()(64bit) php-facedetect-1.0.0-4.fc13.x86_64 requires libcvaux.so.2.0()(64bit) php-facedetect-1.0.0-4.fc13.x86_64 requires libhighgui.so.2.0()(64bit) player-3.0.1-5.fc13.i686 requires libml.so.2.0 player-3.0.1-5.fc13.i686 requires libhighgui.so.2.0 player-3.0.1-5.fc13.i686 requires libcxcore.so.2.0 player-3.0.1-5.fc13.i686 requires libcv.so.2.0 player-3.0.1-5.fc13.i686 requires libcvaux.so.2.0 player-3.0.1-5.fc13.x86_64 requires libcvaux.so.2.0()(64bit) player-3.0.1-5.fc13.x86_64 requires libcv.so.2.0()(64bit) player-3.0.1-5.fc13.x86_64 requires libml.so.2.0()(64bit) player-3.0.1-5.fc13.x86_64 requires libcxcore.so.2.0()(64bit) player-3.0.1-5.fc13.x86_64 requires lib
[Bug 552616] branch perl-Glib for EPEL-5 please
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=552616 --- Comment #3 from Kevin Fenzi 2010-03-08 13:41:11 EST --- Hey Spot. Any news here? Have you had a chance to look at the tests? Can we just disable them from EPEL? Or is there some way to fix them? -- 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: selinux-policy-targeted update failure
On 03/08/2010 06:28 AM, Rakesh Pandit wrote: > On 7 March 2010 20:18, Neal Becker wrote: > >> Updating : selinux-policy-targeted-3.6.32-92.fc12.noarch >> 64/215 >> libsepol.scope_copy_callback: audioentropy: Duplicate declaration in module: >> type/attribute entropyd_var_ru\ >> n_t (No such file or directory). >> libsemanage.semanage_link_sandbox: Link packages failed (No such file or >> directory). >> semodule: Failed! >> >> >> > There is one bug already for Fedora11 package with same version [1], > follow up there and check if this has also been reported for F12. > > https://bugzilla.redhat.com/show_bug.cgi?id=511067 > > Is this happening on a disabled selinux system? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: selinux-policy-targeted update failure
On Sun, 2010-03-07 at 09:48 -0500, Neal Becker wrote: > Updating : selinux-policy-targeted-3.6.32-92.fc12.noarch > 64/215 > libsepol.scope_copy_callback: audioentropy: Duplicate declaration in module: > type/attribute entropyd_var_ru\ > n_t (No such file or directory). > libsemanage.semanage_link_sandbox: Link packages failed (No such file or > directory). > semodule: Failed! Heh, this is fun. I gave that update a +1 because it seems to _work_ fine. I didn't see that error because I've started doing my updates with gnome-packagekit (we in QA decided to have more of us use PackageKit, because almost everyone uses yum, so no-one notices when PK is broken). But PK apparently just throws away such console output, so I didn't see it. Is there a sekrit PK mode you can use to get such output, does anyone know? Maybe if I just launch it from a console... -- 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
[389-devel] Please review: Bug 571514 - upgrade to 1.2.6 should upgrade 05rfc4523.ldif (cert schema)
https://bugzilla.redhat.com/show_bug.cgi?id=571514 https://bugzilla.redhat.com/attachment.cgi?id=398603&action=diff https://bugzilla.redhat.com/attachment.cgi?id=398603&action=edit -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
How to install software without root password (PolicyKit?)
Hi, Fedora 12 was planned to have installation of packages without users needing to enter root password. How do I enable this feature via PolicyKit? I read this article: http://skvidal.wordpress.com/2009/11/18/polkit-and-package-kit-and-changing-settings/ but even after doing that it is still the same and "yum install package" asks for root password. Cheers! -- pratite me na twitteru - www.twitter.com/valentt blog: http://kernelreloaded.blog385.com linux, anime, spirituality, windsurf, wireless, ronjenje, pametne kuće, zwave registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turko...@hotmail.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Karma threshold for kernel
On Mon, 08 Mar 2010 13:29:23 -0600, Michael wrote: > Michael Schwendt wrote: > > Nah. The same way you could consider all bodhi comments "spam". If you > > are the first commenter of a popular package, you receive lots of > > notifications for all subsequent comments (where sometimes people > > even use bodhi to argue about something). > > Michael, how is posting: > > u...@radiopresenter.me.uk (unauthenticated) - 2010-03-08 13:36:44 (karma: 0) > Error Type: Error Value: Error getting > repository data for installed, repository not foundFile : > /usr/share/PackageKit/helpers/yum/yumBackend.py, line 3125, in > main()File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line > 3122, in > main backend.dispatcher(sys.argv[1:])File : > /usr/lib/python2.6/site- > packages/packagekit/backend.py, line 710, in dispatcher > self.dispatch_command(args[0], args[1:])File : /usr/lib/python2.6/site- > packages/packagekit/backend.py, line 657, in dispatch_command > self.update_packages(only_trusted, package_ids)File : > /usr/share/PackageKit/helpers/yum/yumBackend.py, line 1948, in > update_packages > signed = self._is_package_repo_signed(pkg)File : > /usr/share/PackageKit/helpers/yum/yumBackend.py, line 1437, in > _is_package_repo_signed repo = self.yumbase.repos.getRepo(pkg.repoid) > File : /usr/lib/python2.6/site-packages/yum/repos.py, line 121, in getRepo > 'Error getting repository data for $s, repository not found' $ (repoid) > > Multiple times a week not considered spam? Really? Posting this prior to > stable pushes is fine -- I never consider it spam. It's a clueless user, who abuses bodhi's features to post anonymous comments. Just turn off that feature, and let people register for either a Fedora account or a Fedora Bodhi account. Then it would be possible to take further action. > If I could CC you on > some of those updates maybe you would change your opinion. Are you kidding? It would only influence my opinion about you. I've been subscribed to enough bodhi tickets before. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: should man-pages-* have Requires: man?
On 03/08/2010 11:25 AM, Ivana Hutarova Varekova wrote:
> For now in fedora there are 11 packages which contains language
> mutations of man-pages (man-pages-{cs,da,de,es,fr,it,ja,ko,pl,ru,uk})
> and man-pages package.
> Only 2 of them (man-pages-es, man-pages-it) requires man package. I
> think man dependences should be consistent in all man-pages* packages.
> From my point of view man dependency should be in all of them.
There is no strong dependency between "man" and "man-pages".
"man" is just one utility amongst many utilities which can be used to
process man-pages.
Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How does one deal with obsoleted updates from updates-testing
On Mon, 2010-03-08 at 18:54 +, Quentin Armitage wrote: > On Mon, 2010-03-08 at 10:26 -0500, Seth Vidal wrote: > > > > On Mon, 8 Mar 2010, Quentin Armitage wrote: > > > > > The glibc packages (including nscd) were in updates-testing, but have > > > been obsoleted, and so 2.11.90-12 is now the current version again. What > > > is the mechanism for becoming aware that a package that has been > > > installed through updates-testing has been obsoleted (especially since > > > the standard install of F-13 rc has updates-testing enabled)? > > > > They've not been obsoleted, they've just been updated. Obsoleted has a > > different special meaning in rpm-parlance. > > > Sorry, I should have been clearer. glibc-2.11.90.14 is showing in Bodhi > as being Status: obsolete. Bodhi shows that version was pushed to > testing, and it was installed on my system when I installed F-13 on 1st > March. That version appears is now no longer in updates-testing, and the > current version is the earlier version, glibc-2.11.90-12. So far as I > can see, there is no automatic mechanism to become aware of when a > package has been in updates-testing and has subsequently been removed > (?due to obsoleting in Bodhi), and the package needs reverting to an > earlier version. I assume you know about yum downgrade, and yum list extras (and/or using the color indications in yum list) with updates-testing enabled. So I assume you want something else, I guess a push kind of notification? If you've commented to the update doesn't bodhi email you if the update is removed? If not I'd say create a bodhi RFE ... but apart from that I'm not sure how a push notification could occur. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: selinux-policy-targeted update failure
On 03/08/2010 02:47 PM, Adam Williamson wrote: > On Sun, 2010-03-07 at 09:48 -0500, Neal Becker wrote: > >> Updating : selinux-policy-targeted-3.6.32-92.fc12.noarch >> 64/215 >> libsepol.scope_copy_callback: audioentropy: Duplicate declaration in module: >> type/attribute entropyd_var_ru\ >> n_t (No such file or directory). >> libsemanage.semanage_link_sandbox: Link packages failed (No such file or >> directory). >> semodule: Failed! >> > Heh, this is fun. I gave that update a +1 because it seems to _work_ > fine. I didn't see that error because I've started doing my updates with > gnome-packagekit (we in QA decided to have more of us use PackageKit, > because almost everyone uses yum, so no-one notices when PK is broken). > But PK apparently just throws away such console output, so I didn't see > it. > > Is there a sekrit PK mode you can use to get such output, does anyone > know? Maybe if I just launch it from a console... > I have a feeling this update does work fine for most users. Only for people updating from very old policy packages would have the audio_entropy package installed. This should be taken care of in the post install. I am just wondering if this is only happening on disabled machines? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to install software without root password (PolicyKit?)
On Mon, 2010-03-08 at 20:51 +0100, Valent Turkovic wrote: > Hi, Fedora 12 was planned to have installation of packages without > users needing to enter root password. > > How do I enable this feature via PolicyKit? > > I read this article: > http://skvidal.wordpress.com/2009/11/18/polkit-and-package-kit-and-changing-settings/ > but even after doing that it is still the same and "yum install > package" asks for root password. The feature was added to PackageKit not yum ... so you need to use pkcon, not yum. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Karma threshold for kernel
On Mon, 08 Mar 2010 13:29:23 -0600, Michael Cronenworth wrote: > u...@radiopresenter.me.uk (unauthenticated) - 2010-03-08 13:36:44 (karma: 0) > Error Type: Error Value: Error getting > repository data for installed, repository not foundFile : > /usr/share/PackageKit/helpers/yum/yumBackend.py, line 3125, in > main()File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line > 3122, in You've modified the email address. The correct one is visible in bodhi. It could be that it really is Paul West who runs radiopresenter.me.uk I've mailed to his address to ask about these messages. Has anyone else tried that before? -- 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))
Michael Schwendt wrote: > There are just too many -devel packages and their dependencies to be ever > relevant to someone for multi-arch installs. Far more users install i686 on > 64-bit CPUs, and I have doubts that x86_64 installation users do much > development with i686 packages. At most they install 32-bit apps where > 64-bit builds aren't available or "less good". You forget people developing proprietary software... or even just multilib apps. Multilib is useful if you want to build the 32-bit version of something on an x86_64 box (and don't want to set up a full chroot / VM). (Doubly so for proprietary stuff that may need to build both 32- and 64-bit in the same build tree.) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Lions and tigers and HIPPOS! Everyone needs a hippo! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update question: some user data
On Mon, 2010-03-08 at 12:14 -0500, Doug Ledford wrote: > On 03/08/2010 11:05 AM, Adam Williamson wrote: > > On Mon, 2010-03-08 at 10:27 +0100, Nicolas Mailhot wrote: > >> > >> Le Sam 6 mars 2010 20:04, Adam Williamson a écrit : > >> > >>> The numbers do surprise me, to be honest. As I write this, it's 34-8 - > >>> that's over 80% - in favour of 'adventurous' updates. > >> > >> Advanced users (those most likely to want a more stable rawhide to use it > >> as > >> primary system) use irc, mailing lists, bugzilla, etc. Normal users (those > >> that need a stable Fedora so they can spend their time writing apps, doing > >> i18n, etc) do not read Fedora forums (if they had this kind of time they > >> would > >> not object to adventurous time-wasting updates). > > > > I don't think that's an assertion you have any kind of evidence to > > support. > > Well, I stand as a data point that matches this assertion (although you Just the one data point, then? Yet people are complaining about a poll with over a hundred responses not having sufficient data points? > could leave out the rhetoric about advanced users and all, the data > point of "people that use Fedora to get work done" versus "people that > user Fedora to tinker" I think is probably a fairly accurate assessment > of what people might or might not be found on Fedora Forums). > > > It's really quite sad that half the people who've responded to > > the poll have done so by attempting to poke holes in it, as it happens > > not to line up with what they think. > > That's not fair. Yes, many have poked holes in the poll, but to be > fair, as you said, it's unscientific and it *does* have holes in its > methodology. > > > If you think the poll is wrong - provide some data to disprove it. > > I'm sorry, but that's a scientifically specious argument. Invalid data > doesn't become valid because there is no valid counter data. It is > valid or invalid all on its own. To date, no one has run a > scientifically valid poll, but that doesn't make your poll any better or > worse, it just makes it all by itself. My basic point here is that the poll, while imperfect, is the best indication we have available so far. My second important point is that complaining about a poll being problematic and backing up your complaint with nothing but utterly unsupported assertions is entirely hypocritical. If my data is invalid, their assertions are...well, even *more* invalid (although validity isn't an analog concept, I accept). > > Counteracting it with yet more assertions built on precisely no evidence > > is not convincing. > > Well, one of the questions to be asked before going any further on this > is what audience do we care about? I've heard it over and over again > that Fedora is supposed to be a developer's platform, and not a user's > platform. If that's true, then the people that should be voting on this > is the people that make Fedora, not the people that consume it. If the > reverse is true, then it really doesn't matter what the users vote > anyway because then it's up to us to decide *which* user segment we wish > to target and build the OS to satisfy them. I agree, and I'm one of the people who's been saying this for months. On a practical level, though, it doesn't look like it's going to happen any time soon, whereas by some of the comments in this thread, some people seem happy to claim that FESco has sufficient authority to decide an updates policy on its own, and also seem as if they have some inclination towards doing so. So it seems like there may be efforts to make changes in the update policy situation _before_ the target audience issue is settled (which, like you, I do not think is a good idea). As I said right back at the start, I primarily did the poll because more than one person in the thread happily asserted that 'users don't want adventurous updates', without bothering to provide any kind of support for that claim. It's a lot harder to make that claim now, I think. Even if you want to argue that the poll isn't sufficiently rigorous to 'prove' that users want adventurous updates, I think it's sufficient data to make it clear that barely asserting that users don't want such updates isn't admissible. > Now, as for the wording. It was both subjective and vague. Neither of > those leads to a good poll without at a minimum putting in additional > questions to narrow down responses. As an example of why I call it > subjective and vague, I could have worded the same "adventurous" and > "conservative" options as "gratuitous" and "reasonable", That's not a very good example, because you're taking the wording that I claim is good and replacing it with bad wording and saying 'this proves the wording is bad'. Huh? By that token you could take any well-worded poll, replace it with bad wording, and say 'the fact that I can plug bad wording into this poll question means the original wording must also be bad!' It's a non-sequitur. The whol
[389-devel] Please review: [Bug 199923] subtree search fails to find items under a db containing special characters
Subject: subtree search fails to find items under a db containing
special characters
https://bugzilla.redhat.com/show_bug.cgi?id=199923
This bug had been reopened due to the regression.
[Proposed Fix]
https://bugzilla.redhat.com/attachment.cgi?id=398612&action=diff
https://bugzilla.redhat.com/attachment.cgi?id=398612&action=edit
Files:
ldap/servers/plugins/syntaxes/validate.c
ldap/servers/slapd/dn.c
Problem Description:
A simple failed case observed before applying the patch:
$ /usr/lib64/mozldap/ldapmodify -p 10389 -D 'cn=directory manager' -w pw<< EOF
dn: ou=\#\<,dc=example,dc=com
objectClass: organizationalUnit
objectClass: top
ou: \#\<
EOF
ldap_add: Invalid DN syntax
ldap_add: additional info: DN value invalid per syntax
Fix Description:
dn.c: Based upon RFC 4514, '#', '+', ';', '<','>', and '=' need to be escaped
in addition to '\\' and '"' if it appears in the DN string.
validate.c: Using the above example, if an escaped character (\<) followed by
an escaped character (\#), the pointer was moved twice skipping '\' before '<'
and it makes the validation fail.
==
Breakpoint 2, rdn_validate (
begin=0x7fd090001ed0 "ou=\\#\\<,dc=example,dc=com",
end=0x7fd090001ee8 "m", last=0x7fd0a9bedac0)
at ldap/servers/plugins/syntaxes/validate.c:430
430int rc = 0; /* Assume RDN is valid */
(gdb) p p
$35 = 0x7fd090001ed3 "\\#\\<,dc=example,dc=com"
(gdb) p end
$36 = 0x7fd090001ee8 "m"
(gdb) p *p
$37 = 92 '\\'
(gdb) n
472if (numericform) {
(gdb) n
498if (IS_UTF1(*p)&& !IS_ESC(*p)&& !IS_LUTF1(*p)) {
(gdb) n
507if (numericform) {
(gdb) n
517if (IS_UTF1(*p)) {
(gdb) n
520if ((p == end)&& !IS_TUTF1(*p)) {
(gdb) n
524} else if (IS_ESC(*p)) {
(gdb) n
528p++;<== *p is '#'
(gdb) n
529if (!IS_ESC(*p)&& !IS_SPECIAL(*p)) {
(gdb) n
538p++;<== move the pointer to the next char '\\'
(gdb) p *p
$40 = 92 '\\'
(gdb) n
545p++;<== another move to '<', which needs to be escaped
(gdb) n
517if (IS_UTF1(*p)) {
(gdb) n
520if ((p == end)&& !IS_TUTF1(*p)) {
(gdb) n
524} else if (IS_ESC(*p)) {
(gdb) n
540} else if (!IS_SUTF1(*p)) {
(gdb) n
541rc = 1;<== failed.
smime.p7s
Description: S/MIME Cryptographic Signature
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: usb_modeswitch by default
On Fri, 05 Mar 2010 22:27:48 -0800 Dan Williams wrote: > > > I have taken over the maintainership from Robert, and the new > > > usb_modeswitch rpms are in rawhide now. > > > > And F-13? > > I'm pushing for F13 and F12 at least :) I usually end up getting the > bugs when modems don't switch, I just never had the time to give > usb_modeswitch any love. One last thing: Dan, is it your page at this URL: http://live.gnome.org/NetworkManager/MobileBroadband It says: Huawei Most Huawei devices are handled automatically by the kernel. If the 'option' driver which handles Huawei devices lacks the USB IDs of your device, the correct solution is to add those IDs to the kernel driver by submitting a patch to your distribution's bugzilla or Linux Kernel Mailing List. If your device is not yet recognized, you can eject the fake driver CD with usb_modeswitch, and bind the generic usbserial driver manually to the device (see below). Someone filed a bug about this today: https://bugzilla.redhat.com/show_bug.cgi?id=571542 -- Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: selinux-policy-targeted update failure
On 8 March 2010 19:47, Adam Williamson wrote: > Is there a sekrit PK mode you can use to get such output, does anyone > know? Maybe if I just launch it from a console... No, but I could do such a thing if you file an enhancement bug. Richard. -- 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 Mon, 08 Mar 2010 14:29:42 -0600, Matthew wrote: > > There are just too many -devel packages and their dependencies to be ever > > relevant to someone for multi-arch installs. Far more users install i686 on > > 64-bit CPUs, and I have doubts that x86_64 installation users do much > > development with i686 packages. At most they install 32-bit apps where > > 64-bit builds aren't available or "less good". > > You forget people developing proprietary software... Why would development of proprietary software have different requirements with regard to multilib installations? When I wrote "...I have doubts that x86_64 installation users do much development with i686 packages", I didn't exclude developers of proprietary software either. There may be some who do it actually, but I don't have any numbers. I only see more users who run into problems because of the multiarch repos. > or even just > multilib apps. Multilib is useful if you want to build the 32-bit > version of something on an x86_64 box (and don't want to set up a full > chroot / VM). The "don't want to" is questionable. Development of the 32-bit version would still need a full 32-bit test installation. It need not be the x86_64 box to do full multi-booting instead of VM, but even multi-booting would be convenient enough, considering how quickly something like Fedora can be installed. Typical development is not trial-and-error compilation of both 64-bit and 32-bit and alternating, but rather development on either arch till something is ready to be built for and to be tested on a different arch. Same for multiple target distributions. > (Doubly so for proprietary stuff that may need to build both 32- and > 64-bit in the same build tree.) Again, what special requirements come with the "proprietary" part? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
On Sun, 2010-03-07 at 11:33 -0500, Toshio Kuratomi wrote: > I can't find the wiki page documenting buildroot overrides so I can't > confirm this. I thought that releng was asking for the overrides to be > removed when the package was pushed to stable but I could be wrong. > https://fedoraproject.org/wiki/Buildroot_override_SOP -- 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: Update question: some user data
On Sat, 2010-03-06 at 11:04 -0800, Adam Williamson wrote: > I thought to myself yesterday, 'what this long and fractious thread > about update policy *really* needs is some unscientific and > controversial numbers'. =) So, I ran a forum poll! Everyone loves those, > right? > > Here it is: http://forums.fedoraforum.org/showthread.php?t=241710 > No, the voting numbers aren't huge, but it's still some kind of data. I > can promote the poll to the forum front page to try and get more input, > if desired. It seems people are getting confused, so let me state it more clearly. Here's the specific conclusion I draw from this data: Those who asserted in these threads that 'users don't want adventurous updates' shouldn't do so. The poll clearly indicates that some users do want these updates. If someone does a more comprehensive poll which demonstrates that these users are actually a tiny minority; fine. It would then be appropriate to assert that the majority of users do not want these updates, and use that in an argument that Fedora should restrict them. At present, however, it is not sustainable to do so. That's all. I'm not presenting this as some kind of proof that all Fedora users definitely want all updates all the time, I'm just plugging it in to show that what users want may not be what some people _think_ they want, and if you want to rely on 'what users want' as a part of your argument, you should provide some decent evidential basis for that. If, on the other hand, you want to argue that it's not important what users want, you don't need to, and this part of the discussion becomes a no-op. There, I hope that's clear. -- 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: Another great update
On Mon, Mar 08, 2010 at 01:24:24PM -0800, Jesse Keating wrote: > On Sun, 2010-03-07 at 11:33 -0500, Toshio Kuratomi wrote: > > I can't find the wiki page documenting buildroot overrides so I can't > > confirm this. I thought that releng was asking for the overrides to be > > removed when the package was pushed to stable but I could be wrong. > > > > https://fedoraproject.org/wiki/Buildroot_override_SOP > That's the page for releng's actions in response to a buildroot override request. I'm looking for where it's documented when to ask for a buildroot override, when to request the override go away, (and how to request the override but that's a tangent to the question I needed answering). -Toshio pgpNOXG4UJBli.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 Branched report: 20100306 changes
On Mon, 2010-03-08 at 14:54 +, Quentin Armitage wrote: > The report lists 3 fc12 packages as updates for F-13. Doing a yum update > of avrdude shows the new version as 5.10-2.fc13 and not 5.10-1.fc12 as > listed. For man-pages-it, yum update lists 2.80-5.fc13 and not > 2.80-5.fc12 as listed. > > For sos, yum attempts to update to the listed version, i.e. 1.9-1.fc12 > but then produces the following error: > warning: rpmts_HdrFromFdno: Header V3 RSA/SA256 Signature, key ID > 57bbccba: NOKEY > > Public key for sos-1.9-1.fc12.noarch.rpm is not installed Urgh. These are F12 updates that are being inherited into dist-f13. I briefly thought about this problem and then forgot it when I was setting up the tags. I'll have to think on this some more. -- 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: selinux-policy-targeted update failure
On Mon, 2010-03-08 at 21:18 +, Richard Hughes wrote: > On 8 March 2010 19:47, Adam Williamson wrote: > > Is there a sekrit PK mode you can use to get such output, does anyone > > know? Maybe if I just launch it from a console... > > No, but I could do such a thing if you file an enhancement bug. OK, I'll put it on my to-do list. thanks. -- 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: Update question: some user data
On Mon, Mar 08, 2010 at 12:34:03PM -0500, Will Woods wrote: > Adam's poll results are valid *only* for Fedora users who: > > a) Are members of the Fedora forum, > b) Enthusiasts/power-users to the degree that they would notice a new > threads/poll within a day of its posting, and > c) Hold a strong enough opinion to feel the need to answer the poll. > > It seems obvious that this group would lean more towards the > adventurous, power-user side of things. I would never associated forums with power users, because advanced users typically use mailing lists or newsgroups instead of a forum, if there are multiple options. Regards Till pgpag5UnQ7QGh.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F13 Release Slogan - Rock it.
For the 13th Release of Fedora, "Goddard," the Fedora Marketing team ran an open, community based process of slogan submissions, found at https://fedoraproject.org/wiki/Release_slogan_SOP. That process included guidelines for producing great slogans, and as a result of our call, we received a large number of slogan contributions, which are recorded at https://fedoraproject.org/wiki/F13_release_slogan. After an exciting and enjoyable Marketing Team meeting, the release slogan for Fedora 13 "Goddard" has been chosen and approved: "Rock it!" We would like to thank all the contributors who have participated in this process. Cheers! -Robyn ___ 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
Proposed udpates policy change
This is the policy that I expect to be discussed during the Fesco meeting tomorrow. This is entirely orthogonal to the ongoing discussions regarding whether updates in stable releases should be expected to provide features or purely bugfixes, and I don't see any conflict in introducing it before those discussions have concluded. Introduction We assume the following axioms: 1) Updates to stable that result in any reduction of functionality to the user are unacceptable. 2) It is impossible to ensure that functionality will not be reduced without sufficient testing. 3) Sufficient testing of software inherently requires manual intervention by more than one individual. Proposal The ability for maintainers to flag an update directly into the updates repository will be disabled. Before being added to updates, the package must receive a net karma of +3 in Bodhi. It should be noted that this does not require that packages pass through updates-testing. The package will appear in Bodhi as soon as the update is available. If sufficient karma is added before a push occurs, and the update is flagged for automatic pushing when the karma threshold is reached, the update will be pushed directly to updates. It is the expectation of Fesco that the majority of updates should easily be able to garner the necessary karma in a minimal space of time. Updates in response to functional regressions should be coordinated with those who have observed these regressions in order to confirm that the update fixes them correctly. At present, this policy will not apply to updates that are flagged as security updates. The future -- Defining the purpose of Fedora updates is outside the scope of Fesco. However, we note that updates intended to add new functionality are more likely to result in user-visible regressions, and updates that alter ABI or API are likely to break local customisations even if all Fedora packages are updated to match. We encourage the development of mechanisms that ensure that users who wish to obtain the latest version of software remain able to do so, while not tending to introduce functional, UI or interface bugs for users who wish to be able to maintain a stable platform. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
On Mon, 2010-03-08 at 16:32 -0500, Toshio Kuratomi wrote: > On Mon, Mar 08, 2010 at 01:24:24PM -0800, Jesse Keating wrote: > > On Sun, 2010-03-07 at 11:33 -0500, Toshio Kuratomi wrote: > > > I can't find the wiki page documenting buildroot overrides so I can't > > > confirm this. I thought that releng was asking for the overrides to be > > > removed when the package was pushed to stable but I could be wrong. > > > > > > > https://fedoraproject.org/wiki/Buildroot_override_SOP > > > That's the page for releng's actions in response to a buildroot override > request. I'm looking for where it's documented when to ask for a buildroot > override, when to request the override go away, (and how to request the > override but that's a tangent to the question I needed answering). > I don't know if such a page exists. If anybody would like to create one, that would be awesome. -- 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
