Bodhi issues
I just got: 500 Internal error The server encountered an unexpected condition which prevented it from fulfilling the request. Powered by CherryPy 2.3.0 submitting a karma update to an update. It did take something because I got email(s) of my comments -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Doesn’t LDD break no-content rule?
According to https://admin.fedoraproject.org/pkgdb/acls/name/ldd-pdf is Linux Device Drivers, Third Edition Book in PDF format Isn't it breaking https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content ? Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DisplayManagerRework: how to handle upgrades?
Rex Dieter wrote: Rex Dieter wrote: OK, so we have https://fedoraproject.org/wiki/Features/DisplayManagerRework#How_To_Test that tells one how to enable the display manager of your choice, via systemctl enable --force xyzdm.service But, how to handle upgrades? (or is this case already handled somehow?) Off the top of my head, perhaps create some sort of scriptlet (probably to live in initscripts, since that's what owned prefdm) to parse /etc/sysconfig/desktop to make some educated guess about which dm service to enable. nucleo mentioned to me on irc the case also of the simple case of a machine with no DM. If the expactation that yum install gdm (or any DM, with no DM currently enabled) should 'just work', then perhaps also consider doing something like this in gdm's %post scriptlet: systemctl is-enabled display-manager.service || \ systemctl enable gdm.service ok, ignore this, looks like presets are the way to go here. -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Doesn’t LDD break no-content rule?
MC == Matej Cepl mc...@redhat.com writes: MC Isn't it breaking MC https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content MC ? Maybe you should tell us why you believe it is. I don't see how it violates any of the rules for content. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing boost 1.50 issues while branching issues
On Sat, 11 Aug 2012 16:27:28 -0500 Richard Shaw hobbes1...@gmail.com wrote: Ok, I'm sure I did something wrong but I'm not exactly sure what I was supposed to do... Due to Boost 1.50 I had a chain of libraries that needed rebuilding: blender - OpenImageIO - Field3D I've been able to rebuild the rawhide ones (except for a separate boost issue with blender) but I'm not having any luck with f18. I built Field3D but it was tagged into f18-candidate and I can neither add it to an update or to a buildroot override, so I can't build OpenImageIO... It was? It shouldn't have been and I don't show it being so. It's in f18. It will appear in tomorrow's branched compose and it will be in the buildroot as of the next one that is generated. Since this is my first time having a library issue in the middle of branching I don't know what I was supposed to do. Is it currently possible to tag directly into f18? If so that means I'll have to rebuild for rawhide so NEVR won't be in f18 than rawhide... Until tuesday, branched is exactly like rawhide. On tuesday, bodhi is added, and you have to do updates, etc. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing boost 1.50 issues while branching issues
On Sat, Aug 11, 2012 at 4:56 PM, Kevin Fenzi ke...@scrye.com wrote: On Sat, 11 Aug 2012 16:27:28 -0500 Richard Shaw hobbes1...@gmail.com wrote: Ok, I'm sure I did something wrong but I'm not exactly sure what I was supposed to do... Due to Boost 1.50 I had a chain of libraries that needed rebuilding: blender - OpenImageIO - Field3D I've been able to rebuild the rawhide ones (except for a separate boost issue with blender) but I'm not having any luck with f18. I built Field3D but it was tagged into f18-candidate and I can neither add it to an update or to a buildroot override, so I can't build OpenImageIO... It was? It shouldn't have been and I don't show it being so. It's in f18. What!?!?! Ok, I know I wasn't seeing things yesterday. I KNOW it was in f18-candidate otherwise OpenImageIO wouldn't have failed to build. Must have gotten moved somehow? It will appear in tomorrow's branched compose and it will be in the buildroot as of the next one that is generated. Since this is my first time having a library issue in the middle of branching I don't know what I was supposed to do. Is it currently possible to tag directly into f18? If so that means I'll have to rebuild for rawhide so NEVR won't be in f18 than rawhide... Until tuesday, branched is exactly like rawhide. Well I had already done another build using the --target f18 and it seemed to do the job but maybe it would have gone into f18 anyway :) Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DisplayManagerRework: how to handle upgrades?
On Sat, 11.08.12 11:23, Rex Dieter (rdie...@math.unl.edu) wrote: OK, so we have https://fedoraproject.org/wiki/Features/DisplayManagerRework#How_To_Test that tells one how to enable the display manager of your choice, via systemctl enable --force xyzdm.service But, how to handle upgrades? (or is this case already handled somehow?) This should be handled already bei the postinst scriptlet in the systemd RPM. I must admit though that I gave that bit only minimal testing. But it should work, and the core of it is just copied out of the old prefdm script, so that we closely convert the old settings into new settings. Off the top of my head, perhaps create some sort of scriptlet (probably to live in initscripts, since that's what owned prefdm) to parse /etc/sysconfig/desktop to make some educated guess about which dm service to enable. That's pretty much exactly what we have, except that this actually resides in systemd.rpm. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DisplayManagerRework: how to handle upgrades?
On Sat, 11.08.12 21:54, alekc...@googlemail.com (alekc...@googlemail.com) wrote: Rex Dieter wrote: OK, so we have https://fedoraproject.org/wiki/Features/DisplayManagerRework#How_To_Test that tells one how to enable the display manager of your choice, via systemctl enable --force xyzdm.service But, how to handle upgrades? (or is this case already handled somehow?) Off the top of my head, perhaps create some sort of scriptlet (probably to live in initscripts, since that's what owned prefdm) to parse /etc/sysconfig/desktop to make some educated guess about which dm service to enable. thoughts? -- rex This is marked as DONE: 8. (Optionally) Patch systemd to parse /etc/sysconfig/desktop at upgrade time and generate a symlink from it that is stored in /etc/systemd/system/display-manager.service and ensures that the original display manager choice is kept. I have DISPLAYMANAGER=KDE in /etc/sysconfig/desktop but symlink was not generated after Rawhide update. Hmm, that would suggest that this bit is borked: http://pkgs.fedoraproject.org/cgit/systemd.git/tree/systemd.spec#n300 If you execute that by hand in a shell, does it work for you then? Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing boost 1.50 issues while branching issues
On Sat, 11 Aug 2012 17:36:45 -0500 Richard Shaw hobbes1...@gmail.com wrote: What!?!?! Ok, I know I wasn't seeing things yesterday. I KNOW it was in f18-candidate otherwise OpenImageIO wouldn't have failed to build. Must have gotten moved somehow? I can't think of any reason it would have... Well I had already done another build using the --target f18 and it seemed to do the job but maybe it would have gone into f18 anyway :) yes, it should have. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Sat, 11 Aug 2012 18:20:35 +0200 Kevin Kofler kevin.kof...@chello.at wrote: Luke Macken wrote: - The submitter of an update can no longer effect the karma (Till Maas) Uh, last I checked, FESCo had agreed that this should NOT be enforced by the software because it is legitimate for the submitter to give karma by proxy when an anonymous tester has done the required testing. Can you find a cite for that? Last I looked it was not allowed (but not enforced by software) by policy. We can reopen the issue and discuss it again of course... kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DisplayManagerRework: how to handle upgrades?
Lennart Poettering wrote: On Sat, 11.08.12 21:54, alekc...@googlemail.com (alekc...@googlemail.com) wrote: Rex Dieter wrote: OK, so we have https://fedoraproject.org/wiki/Features/DisplayManagerRework#How_To_Test that tells one how to enable the display manager of your choice, via systemctl enable --force xyzdm.service But, how to handle upgrades? (or is this case already handled somehow?) Off the top of my head, perhaps create some sort of scriptlet (probably to live in initscripts, since that's what owned prefdm) to parse /etc/sysconfig/desktop to make some educated guess about which dm service to enable. thoughts? -- rex This is marked as DONE: 8. (Optionally) Patch systemd to parse /etc/sysconfig/desktop at upgrade time and generate a symlink from it that is stored in /etc/systemd/system/display-manager.service and ensures that the original display manager choice is kept. I have DISPLAYMANAGER=KDE in /etc/sysconfig/desktop but symlink was not generated after Rawhide update. Hmm, that would suggest that this bit is borked: http://pkgs.fedoraproject.org/cgit/systemd.git/tree/systemd.spec#n300 If you execute that by hand in a shell, does it work for you then? Lennart This part of code creates symlink (after installing all updates including systemd and kde-settings-kdm). But as I commented in bug 847472, symlink also created after updating systemd if kde-settings-kdm was previously updated to version which adds kdm.servise. If systemd and kde-settings both updated at once then symlink not created. https://bugzilla.redhat.com/show_bug.cgi?id=847472#c5 -- Alexey Kurov nuc...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Doesn’t LDD break no-content rule?
(sorry, once more, this time to the correct address) On 11/08/12 23:03, Jason L Tibbitts III wrote: Maybe you should tell us why you believe it is. I don't see how it violates any of the rules for content. I thought that the rule is that Fedora packages shouldn't contain just a pure content. What's there in PDF document other than content? Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Doesn’t LDD break no-content rule?
MC == Matěj Cepl mc...@redhat.com writes: MC (sorry, once more, this time to the correct address) And now a public reply MC I thought that the rule is that Fedora packages shouldn't contain MC just a pure content. That is incorrect, pretty obviously if you think about it. I mean, how is man-pages really any different? Since you included the URL in your original message I assume you were familiar with the section, but just in case, do read http://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content Specifically: If the content enhances the OS user experience, then the content is OK to be packaged in Fedora There's a set of restrictions; I don't see how the content in the package you reference violates any of them. Documentation certainly qualifies, whether it's packaged along with the software it documents or separately. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: perl-PDL
perl-PDL has broken dependencies in the F-18 tree: On x86_64: perl-PDL-2.4.10-1.fc17.x86_64 requires perl(:MODULE_COMPAT_5.14.2) On i386: perl-PDL-2.4.10-1.fc17.i686 requires perl(:MODULE_COMPAT_5.14.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-OpenOffice-UNO
perl-OpenOffice-UNO has broken dependencies in the F-18 tree: On x86_64: perl-OpenOffice-UNO-0.07-3.fc17.x86_64 requires perl(:MODULE_COMPAT_5.14.2) On i386: perl-OpenOffice-UNO-0.07-3.fc17.i686 requires perl(:MODULE_COMPAT_5.14.2) perl-OpenOffice-UNO-0.07-3.fc17.i686 requires libsal_textenc.so Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Alien-SeleniumRC
perl-Alien-SeleniumRC has broken dependencies in the F-18 tree: On x86_64: perl-Alien-SeleniumRC-2.92-1.fc18.noarch requires selenium-server On i386: perl-Alien-SeleniumRC-2.92-1.fc18.noarch requires selenium-server Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Authen-Simple
perl-Authen-Simple has broken dependencies in the epel-6 tree: On ppc64: perl-Authen-Simple-0.4-5.el6.noarch requires perl(Crypt::PasswdMD5) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: cpanspec
cpanspec has broken dependencies in the epel-6 tree: On x86_64: cpanspec-1.78-6.el6.noarch requires perl(Parse::CPAN::Packages) On i386: cpanspec-1.78-6.el6.noarch requires perl(Parse::CPAN::Packages) On ppc64: cpanspec-1.78-6.el6.noarch requires perl(Parse::CPAN::Packages) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-WWW-GoodData
perl-WWW-GoodData has broken dependencies in the epel-5 tree: On ppc: perl-WWW-GoodData-1.6-1.el5.noarch requires perl(Getopt::Long) = 0:2.36 On i386: perl-WWW-GoodData-1.6-1.el5.noarch requires perl(Getopt::Long) = 0:2.36 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-WWW-GoodData
perl-WWW-GoodData has broken dependencies in the epel-5 tree: On ppc: perl-WWW-GoodData-1.6-1.el5.noarch requires perl(Getopt::Long) = 0:2.36 On i386: perl-WWW-GoodData-1.6-1.el5.noarch requires perl(Getopt::Long) = 0:2.36 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
