Re: Ubuntu 10.10's installer looks rather nice
On 10/12/10 18:39, Jos Vos wrote: On Tue, Oct 12, 2010 at 09:30:45AM -0700, Adam Williamson wrote: 2) it creates a confusing decision point for *everyone*: how do you know if you need the 'advanced' options? You can't really know without looking at them, so you have to look at them to decide if you need them, so essentially we're presenting the advanced options to everyone... 100% agreed. You do not know in advance what options will not be shown in non-advanced mode (e.g. custom filesystem layout, MBR at a different partition, etc.). As a CLI expert I'm considering myself all but a GUI expert, but I never understood how people can guess the corect answer to this kind of undefined questions (like do you want basic or advanced install mode?). advanced install mode is a non-started as discussed elsewhere in this thread. It must be more fine-grained, i.e. each installation step (where it make sense) should offer some button to see the advanced options. And it probably shouldn't be labeled Advanced ... but say what kind of advanced stuff is hidden there, i.e. the advanced storage button should be labeled Add SAN storage ... because this is what it actually is about. Now you can figure whenever you need that or not without klicking and looking, see? cheers, Gerd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On Mon, 2010-10-11 at 11:41 +0100, Richard W.M. Jones wrote: I installed and played with Ubuntu 10.10 over the weekend (in a VM), and I have to say that their installer is very smooth indeed. snip As a full-time Ubuntu user, I just want to point out that I don't really like the Ubuntu installer and its whole process. Although I do prefer to use to distro itself. When I do use Fedora, I really enjoy the whole live-image-copy process as its super fast and efficient and it does the job well. It's much faster than the installer of Ubuntu. So again, as a full-time Ubuntu user, the Fedora Development Team should be very proud of what they've achieved with the Fedora and Anaconda Installer. Regards Chris Jones -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
2010/10/12 Jesse Keating jkeat...@redhat.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/12/10 7:20 AM, Rudolf Kastl wrote: I am doing the same setup, nice to see someone else with those requirements. actually without kickstart setting up softraid in anaconda was broken (try it manually without precreated partitions... it will drive you insane). out of the box booting didnt work when /boot was on a mirror raid and the mbr wasnt cloned either. not that great of an out of the box experience. i had those issues in f11 f12 and f13. but hey... instead of redundancy having some colored automatically selected flags and languages is probably more important after all. Have you been participating in the test days and filing bugs? We've done many raid setups, it's part of our release criteria, and we haven't ran into the issues you seem to be describing above. Let me clarify. On the criteria page i read (have to dig out the link) it said that bugs regarding having /boot on softraid are ignored at this point, so no i didnt bother filing a report. sounded like a known issue. As for the test day. Really, i always try to help out on test days but i guess i was too busy/on the road when this one happened. Manually setting up softraids with mdadm works like a charm btw. What is problematic is setting up the correct partition layout manually with 2 drives because anaconda moves around and reenumberates the partitions when you add new ones. (that drove me to insanity.) also note that using kickstart works like a charm aswell. in the notes i only found: http://fedoraproject.org/wiki/Common_F13_bugs#Booting_from_an_mdraid_mirror_without_a_separate_.2Fboot_fails Atleast on the f12 install this also failed with a seperate boot. I am going to keep my eyes open for f14 and doing an install with the current f14 state soon to see which of those issues is still left and file appropriate reports regarding the open issues. I am really curious also if it will automatically make both disks of the mirror setup bootable (writing grub to both mbrs). kind regards, Rudolf Kastl kind regards, Rudolf Kastl - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky0eG4ACgkQ4v2HLvE71NV3hACgq6Wuii5Vue4Kg7ZI4hkfFJ5J qGMAoJ3/hd/jzljK+OUlgE/SbR9l1iaz =lxeC -END PGP SIGNATURE- -- 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
Packaging dwm
Hey, I've been thinking about packaging dwm [1] since we already ship dmenu and dzen2. I wonder if anybody would be interested in this fine window manager (except for me). The problem here: dwm is configured solely in C and has to be recompiled every time a user wants to change their settings (appearance, behavior, shortcuts, etc). In my opinion, we could do it like this: - install a Fedora preconfigured version along with dwm sources - copy its configuration (C header file) to some fixed location for user to customize - provide a script to recompile dwm locally using the local configuration file Would this be acceptable for a window manager in Fedora? Would anybody be interested in this? :) Thanks, Petr [1] http://dwm.suckless.org/ -- Petr 'contyk' Sabata, Red Hat, Brno () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments pgpMGfC7oUTVZ.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OpenLayers update?
On Tue, 2010-10-12 at 16:01 -0700, Jesse Keating wrote: That's a pretty broad and unhelpful and untrue statement. I know of plenty of people who use rawhide for development. Continuing to perpetuate that rawhide is unusable for development only makes things worse, by spreading the idea that it's OK to break rawhide. Hello, No one *that I know* uses rawhide for development. It's not worth risking the time to save your box/work when it does break. Even when we test rawhide, it's generally on a different test box. However, it is wrong for me to generalise. It's a choice. IMO rawhide is not to be used for day to day work. My reply did not perpetuate that it is OK to break rawhide. If people think that way, it really is their fault. The thread served it's purpose, we wouldn't want it straying into another flame war. :) Have a good day! -- Thanks! Regards, Ankur https://fedoraproject.org/wiki/User:Ankursinha FranciscoD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/13/10 2:04 AM, Rudolf Kastl wrote: Let me clarify. On the criteria page i read (have to dig out the link) it said that bugs regarding having /boot on softraid are ignored at this point, so no i didnt bother filing a report. sounded like a known issue. As for the test day. Really, i always try to help out on test days but i guess i was too busy/on the road when this one happened. Manually setting up softraids with mdadm works like a charm btw. What is problematic is setting up the correct partition layout manually with 2 drives because anaconda moves around and reenumberates the partitions when you add new ones. (that drove me to insanity.) also note that using kickstart works like a charm aswell. in the notes i only found: http://fedoraproject.org/wiki/Common_F13_bugs#Booting_from_an_mdraid_mirror_without_a_separate_.2Fboot_fails Atleast on the f12 install this also failed with a seperate boot. I am going to keep my eyes open for f14 and doing an install with the current f14 state soon to see which of those issues is still left and file appropriate reports regarding the open issues. I am really curious also if it will automatically make both disks of the mirror setup bootable (writing grub to both mbrs). Ok, so what you're saying is, that the specific case of having /boot on softraid didn't work for you. I may have missed that clarification in your first email. I do find it odd because I constantly test scenarios where /boot is a small mirror and / is a large stripe and it seems to work every time for me, often starting from blank disks. I'll test that scenario again soon, maybe there is something I'm doing that you're not, or vice versa? - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky1e6IACgkQ4v2HLvE71NWecQCfYDJpbd3O69EMAKUGJZ6nM2dh 56QAn1uSq+WNs9NzspcWU1zV/EGGwIXf =MPSn -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging dwm
2010/10/13 Petr Sabata psab...@redhat.com: Hey, I've been thinking about packaging dwm [1] since we already ship dmenu and dzen2. I wonder if anybody would be interested in this fine window manager (except for me). The problem here: dwm is configured solely in C and has to be recompiled every time a user wants to change their settings (appearance, behavior, shortcuts, etc). In my opinion, we could do it like this: - install a Fedora preconfigured version along with dwm sources - copy its configuration (C header file) to some fixed location for user to customize - provide a script to recompile dwm locally using the local configuration file Would this be acceptable for a window manager in Fedora? Would anybody be interested in this? :) Well i have packages here of dwm and wmii. Personally i like both of them but the default configuration has the problem that the default key for triggering functionality doesent work in all keyboard mappings. wmii is probably easier to package. if you need help with that drop me an email. kind regards, Rudolf Kastl -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
* Chris Jones [13/10/2010 11:35] : As a full-time Ubuntu user, I just want to point out that I don't really like the Ubuntu installer and its whole process. Although I do prefer to use to distro itself. Amen, I've lost count of the amount of times installing Ubuntu has involved installing Fedora to partition the drive correctly then installing Ubuntu telling it to use the existing partition. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On Wed, Oct 13, 2010 at 02:28:05AM -0700, Jesse Keating wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/13/10 2:04 AM, Rudolf Kastl wrote: Let me clarify. On the criteria page i read (have to dig out the link) it said that bugs regarding having /boot on softraid are ignored at this point, so no i didnt bother filing a report. sounded like a known issue. Ok, so what you're saying is, that the specific case of having /boot on softraid didn't work for you. I may have missed that clarification in your first email. I do find it odd because I constantly test scenarios where /boot is a small mirror and / is a large stripe and it seems to work every time for me, often starting from blank disks. I'll test that scenario again soon, maybe there is something I'm doing that you're not, or vice versa? I encountered this problem when using preupgrade. This is already filled in bugzilla, ate least those two: - preupgrade doesn't work with software raided /boot https://bugzilla.redhat.com/show_bug.cgi?id=97 - preupgrade/anaconda can't use install.img (stage2) on RAID https://bugzilla.redhat.com/show_bug.cgi?id=54 -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
2010/10/13 Jesse Keating jkeat...@redhat.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/13/10 2:04 AM, Rudolf Kastl wrote: Let me clarify. On the criteria page i read (have to dig out the link) it said that bugs regarding having /boot on softraid are ignored at this point, so no i didnt bother filing a report. sounded like a known issue. As for the test day. Really, i always try to help out on test days but i guess i was too busy/on the road when this one happened. Manually setting up softraids with mdadm works like a charm btw. What is problematic is setting up the correct partition layout manually with 2 drives because anaconda moves around and reenumberates the partitions when you add new ones. (that drove me to insanity.) also note that using kickstart works like a charm aswell. in the notes i only found: http://fedoraproject.org/wiki/Common_F13_bugs#Booting_from_an_mdraid_mirror_without_a_separate_.2Fboot_fails Atleast on the f12 install this also failed with a seperate boot. I am going to keep my eyes open for f14 and doing an install with the current f14 state soon to see which of those issues is still left and file appropriate reports regarding the open issues. I am really curious also if it will automatically make both disks of the mirror setup bootable (writing grub to both mbrs). Ok, so what you're saying is, that the specific case of having /boot on softraid didn't work for you. I may have missed that clarification in your first email. I do find it odd because I constantly test scenarios where /boot is a small mirror and / is a large stripe and it seems to work every time for me, often starting from blank disks. I'll test that scenario again soon, maybe there is something I'm doing that you're not, or vice versa? hmm could be. actually what i do is i create 2 partitions on each disk ( for /boot and the rest) and then i softraid each pair and put lvm on top of the non /boot md of course due to the limitations of legacy grub (raid 10 would be faster but... i like the lvm functionality). All raid setups are simple mirrors with 2 disks. I already had the trouble that the partition enumberation would change numbers and order during creating the partitions (to workaround that i precreated the partitions before starting the installer). after completing an install like that the system refused to boot (as far as i remember when it was supposed to read and handle the initrd.) i was assuming that it maybe doesent have the raid modules loaded or not available in the initramfs, but this is just a guess, i cannot remember really. what succeeded was... installing the os on one disk using lvm (/boot / /home swap). creating the mdraid with missing instead the first disk on the second physical hds partitions. then adding the md devices to the vg and pvmoving the first physical disk out... later adding the disk in the missing slot of the md and also mirror raiding the /boot partition followed by an update of the initramfs. kind regards, Rudolf Kastl - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky1e6IACgkQ4v2HLvE71NWecQCfYDJpbd3O69EMAKUGJZ6nM2dh 56QAn1uSq+WNs9NzspcWU1zV/EGGwIXf =MPSn -END PGP SIGNATURE- -- 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: Ubuntu 10.10's installer looks rather nice
On Tue, 2010-10-12 at 00:29 +0800, Liang Suilong wrote: Anaconda does not easily support upgrading from internet. It is quite regretful. Did you mean to say 'Ubuntu installer' here too? Anaconda certainly does support upgrading from the Internet. And it's *too* easy -- I often find it's using an Internet repository without even offering me the choice of using my local NFS mirror. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On Wed, Oct 13, 2010 at 10:16:00AM +0200, Gerd Hoffmann wrote: advanced install mode is a non-started as discussed elsewhere in this thread. It must be more fine-grained, i.e. each installation step (where it make sense) should offer some button to see the advanced options. The Show a screenful of sane defaults for lots of stuff with a Change button next to each sounds good to me, and probably could just be a front for the current dialogs (which might not be perfect, but they are quite good) If the keyboard, timezone etc. are correct (based on autodetection/GeoIP when available) then why make the user even press Next? If Nuke everything and use LVM on my 1TB Seagate is ok, same there. If Standard desktop is fine, then so be it. If not, press Change, select Server and if that's not good either, fiddle with the packages while you're over there. Personally I would probably like a cmd line option to anaconda for it to fetch some file through http (kickstart :) ), and that would have my favourite packages listed, and I could pretty much just press Install after anaconda starts up (after verifying that everything got detected correctly). Pretty much the current situation, except I wouldn't have to go through all of those dialogs. I'm no UX person, though. Maybe people want to think about one thing at a time and then press Next :D -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20101013 changes
Compose started at Wed Oct 13 08:15:45 UTC 2010 Broken deps for x86_64 -- antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 clutter-gst-devel-1.2.0-1.fc15.i686 requires pkgconfig(clutter-1.0) 0:1.3.0 clutter-gst-devel-1.2.0-1.fc15.x86_64 requires pkgconfig(clutter-1.0) 0:1.3.0 dreampie-python3-1.1-5.fc14.noarch requires python(abi) = 0:3.1 empathy-2.32.0-1.fc15.x86_64 requires libcamel-1.2.so.19()(64bit) evolution-couchdb-0.5.0-1.fc15.x86_64 requires libcamel-provider-1.2.so.19()(64bit) evolution-couchdb-0.5.0-1.fc15.x86_64 requires libcamel-1.2.so.19()(64bit) 1:gedit-devel-2.91.0-4.fc15.i686 requires gtksourceview2-devel = 0:2.91 1:gedit-devel-2.91.0-4.fc15.x86_64 requires gtksourceview2-devel = 0:2.91 1:gnome-games-extra-2.31.91.1-1.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gnome-pilot-eds-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-burn.so.1()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-media.so.1()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevdocument.so.3()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevview.so.3()(64bit) gnome-python2-evolution-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-totem-2.32.0-1.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-gtk-0.6.so.0()(64bit) hornsey-1.5.2-0.3.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) jana-0.4.5-0.10.20100520gitacd72f2.fc15.i686 requires libcamel-1.2.so.19 jana-0.4.5-0.10.20100520gitacd72f2.fc15.x86_64 requires libcamel-1.2.so.19()(64bit) moblin-panel-people-0.1.14-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) moblin-panel-status-0.1.21-6.fc14.x86_64 requires libsocialweb-client.so.1()(64bit) moblin-panel-status-0.1.21-6.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit) moblin-panel-status-0.1.21-6.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit) rakudo-0.0.2010.08_2.7.0-1.fc14.x86_64 requires libparrot.so.2.7.0()(64bit) stardict-3.0.1-21.fc13.x86_64 requires libgucharmap.so.7()(64bit) 1:syncevolution-libs-1.0.99.7-1.fc15.i686 requires libcamel-1.2.so.19 1:syncevolution-libs-1.0.99.7-1.fc15.x86_64 requires libcamel-1.2.so.19()(64bit) totem-2.90.5-5.fc15.i686 requires libpeasui-1.0.so.0 totem-2.90.5-5.fc15.x86_64 requires libpeasui-1.0.so.0()(64bit) Broken deps for i386 -- antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 clutter-gst-devel-1.2.0-1.fc15.i686 requires pkgconfig(clutter-1.0) 0:1.3.0 dreampie-python3-1.1-5.fc14.noarch requires python(abi) = 0:3.1 empathy-2.32.0-1.fc15.i686 requires libcamel-1.2.so.19 evolution-couchdb-0.5.0-1.fc15.i686 requires libcamel-1.2.so.19 evolution-couchdb-0.5.0-1.fc15.i686 requires libcamel-provider-1.2.so.19 1:gedit-devel-2.91.0-4.fc15.i686 requires gtksourceview2-devel = 0:2.91 1:gnome-games-extra-2.31.91.1-1.fc15.i686 requires libclutter-gtk-0.10.so.0 gnome-pilot-eds-2.32.0-1.fc14.i686 requires libcamel-1.2.so.19 gnome-python2-brasero-2.32.0-1.fc14.i686 requires libbrasero-burn.so.1 gnome-python2-brasero-2.32.0-1.fc14.i686 requires libbrasero-media.so.1 gnome-python2-evince-2.32.0-1.fc14.i686 requires libevdocument.so.3 gnome-python2-evince-2.32.0-1.fc14.i686 requires libevview.so.3 gnome-python2-evolution-2.32.0-1.fc14.i686 requires libcamel-1.2.so.19 gnome-python2-totem-2.32.0-1.fc14.i686 requires libgnome-media-profiles.so.0 gpx-viewer-0.2.0-3.fc14.i686 requires libclutter-gtk-0.10.so.0 gpx-viewer-0.2.0-3.fc14.i686 requires libchamplain-0.6.so.0 gpx-viewer-0.2.0-3.fc14.i686 requires libchamplain-gtk-0.6.so.0 hornsey-1.5.2-0.3.fc15.i686 requires libclutter-gtk-0.10.so.0 jana-0.4.5-0.10.20100520gitacd72f2.fc15.i686 requires libcamel-1.2.so.19 moblin-panel-people-0.1.14-1.fc14.i686 requires libcamel-1.2.so.19 moblin-panel-status-0.1.21-6.fc14.i686 requires libsocialweb-client.so.1 moblin-panel-status-0.1.21-6.fc14.i686 requires libclutter-gtk-0.10.so.0 moblin-panel-status-0.1.21-6.fc14.i686 requires libchamplain-0.6.so.0 qtgpsc-0.2.3-6.fc12.i686 requires libgps.so.18 rakudo-0.0.2010.08_2.7.0-1.fc14.i686 requires
Re: libgpod 0.8.0 in F13
Nathaniel McCallum wrote: I've just tagged libgpod 0.8.0 for F13 updates-testing. This is the first step to an updated Banshee (1.8.0) in F13 as well as better iPhone/iPad support in the existing Rhythmbox. I'd really like to get some testing on this, so please, if you are using updates-testing and have any Apple-brand device, please check to see that your device will successfully sync with Rhythmbox with the new libgpod. Do you expect other libgpod-using apps need to be rebuilt too? (I can test amarok against my ipod touch, which currently doesn't work as-is). -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On Tue, 2010-10-12 at 18:18 +0100, Evan Dandrea wrote: The Ubuntu installer does let you use a NFS root for your installation source. On the point of needing something more complex, such as LVM or full disk encryption, that's what we offer our alternate CD installer (debian-installer) for. I'm not challenging your point that the Fedora installer offers more complex options. I just wanted to clarify our approach, as our users are not screwed in these circumstances, we just clearly separate their use cases to different CDs. Thanks for the head's up, I considered suicide when I recently tested 10.10/DVD/amd64 and tried doing some standard partitioning using the default DVD tool. (Unless I missed something, once you create a partition is stays put, you cannot edit or move it. Nothing beats creating 5 partitions, just to find out that the first partition [/boot] is 20MB instead of 200MB - forcing you to delete and restart... Pure joy) - Gilboa -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ethtool not in default system anymore?
On 10/13/2010 02:38 AM, Chris Adams wrote: Once upon a time, Michael Cronenworthm...@cchtml.com said: Chris Adams wrote: Maybe ethtool should be added to @Base? Or patch initscripts to use ethtool instead of deprecated cruft. You cut out the part of my email where I quoted the changelog showing that had already been done. The net-tools package should be included anyway (although maybe without mii-tool), as it includes commonly used tools like ifconfig, arp, route, hostname, netstat, etc. Even if some of those commands are obsoleted by ip, they are pretty much required for compatiblity. net-tools also has ether-wake for sending wake-on-LAN packets. I'm not sure. We are trying to eventually get net-tools out of the default install. Most of the scripts (initscripts/networking) has been using iproute commands now and we're trying to navigate people to switch to ip as well. All tools (don't know about ether-wake, mii-diag, plipconfig) already have it's better (net-tools uses obsoleted kernel interface) successor. ifconfig - ip addr, ip link, ip -s link route - ip route netstat - ss, ip route, ip -s link, ip maddr hostname - has been separate package since F13 mii-tool - ethtool arp - ip neigh ipmaddr - ip maddr iptunnel - ip tunnel nameif - udev e.g. Debian si going to leave it and is migrating towards iproute. see http://lists.debian.org/debian-devel/2009/03/msg00780.html hostname package is now pulled in with net-tools but it should probably be in @Base. Can I (maintainer of hostname) add it to comps or do I need to ping somebody else ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Selinux: SSH broken after F-13 -- F-14 upgrade
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/12/2010 05:51 PM, yersinia wrote:
On Tue, Oct 12, 2010 at 8:02 PM, Daniel J Walsh dwa...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/12/2010 01:49 PM, Michal Hlavinka wrote:
Hi all,
I've recently upgraded my system, but after that I was not able to connect
through ssh. More things are wrong (from my POV):
1)SELinux blocks all nondefault ports for ssh
I have ssh confugured to use different port than 22 for security reasons
and I think there is a lot of people doing that.
You need to tell SELinux which port to use for sshd.
semanage port -a -t sshd_port_t -p tcp 6520
Question: Is it worth blocking all ports for ssh?
2)SELinux did not show any sealert warning about this. Running sealert -b
shows no problem. There is one message in /var/log/messages:
kernel: [90346.301108] type=1400 audit(1286901219.350:29): avc: denied {
name_bind } for pid=6830 comm=sshd src=6520
scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket
Question: This should be reported afaik, so it's a bug, right?
No. Hacker gets some control over ssh and is able to make it bind to
port 80, now he can read apache content.
Hmmm, it is enough that sshd bind to port 80 to access the files of
apache? it seems strange. am i missing something in the TE rule?
No but it could interecept traffic intended for the apache server on the
machine. The problem here is the ability to impersonate other apps.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAky1vrcACgkQrlYvE4MpobN1tACgsEoiIXJjBxIYAGb+bIdIE9C9
QT0An3wn9ulywqjGJmQdFyyk5uUeP0tb
=+8Gv
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libgpod 0.8.0 in F13
On 10/13/2010 09:37 AM, Rex Dieter wrote: Nathaniel McCallum wrote: I've just tagged libgpod 0.8.0 for F13 updates-testing. This is the first step to an updated Banshee (1.8.0) in F13 as well as better iPhone/iPad support in the existing Rhythmbox. I'd really like to get some testing on this, so please, if you are using updates-testing and have any Apple-brand device, please check to see that your device will successfully sync with Rhythmbox with the new libgpod. Do you expect other libgpod-using apps need to be rebuilt too? (I can test amarok against my ipod touch, which currently doesn't work as-is). No apps should need to be rebuilt. So you can upgrade libgpod and amarok *should* just work, as long as nothing is broken. Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Maven 3 srpm binary rpms for testing
Hi everyone, Quite a few people from Java SIG are responsible for this early version of maven3 rawhide rpms. Please try them out if you can for building your projects. This release is installable parallel to current maven2 so if any problems with maven2 appear after installing this version let me know. One caveat: there is no mvn3-jpp yet. I'll be working on it over the course of next few days. The command to run is mvn3. SRPM: http://sochotni.fedorapeople.org/maven-3.0-1.fc13.src.rpm RPM: http://sochotni.fedorapeople.org/maven-3.0-1.fc15.noarch.rpm You will need several dependencies that are currently under review. aether: https://bugzilla.redhat.com/show_bug.cgi?id=641967 (review done) sisu: https://bugzilla.redhat.com/show_bug.cgi?id=641390 (waiting) google-guice: https://bugzilla.redhat.com/show_bug.cgi?id=640992 (review done) -- Stanislav Ochotnicky sochotni...@redhat.com Associate Software Engineer - Base Operating Systems Brno PGP: 71A1677C Red Hat Inc. http://cz.redhat.com signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
Hello, I am doing the same setup, nice to see someone else with those requirements. actually without kickstart setting up softraid in anaconda was broken (try it manually without precreated partitions... it will drive you insane). out of the box booting didnt work when /boot was on a mirror raid and the mbr wasnt cloned either. not that great of an out of the box experience. i had those issues in f11 f12 and f13. but hey... instead of redundancy having some colored automatically selected flags and languages is probably more important after all. kind regards, Rudolf Kastl When installing Fedora on machine with -large- amount of drives (8-16), I simply use a single sfdisk script to create the same partition table on all drives. When dealing with smaller configurations (3-4 drives), Anaconda is OK. (At least to me) As for MBR: I assume that like me, you create a small RAID1 for /boot and RAIDX for the rest, hoping the first disk won't die on a DVD-less machine :) In-order to solve it (when I remember to do it :)), I simply dd 446 bytes from the first drive to every other drive. - Gilboa -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OpenLayers update?
On 10/13/2010 02:37 PM, Ankur Sinha wrote: On Tue, 2010-10-12 at 16:01 -0700, Jesse Keating wrote: That's a pretty broad and unhelpful and untrue statement. I know of plenty of people who use rawhide for development. Continuing to perpetuate that rawhide is unusable for development only makes things worse, by spreading the idea that it's OK to break rawhide. Hello, No one *that I know* uses rawhide for development. It's not worth risking the time to save your box/work when it does break. Allow me to introduce myself :-) I use a Rawhide box quite often for testing. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-14 Branched report: 20101013 changes
Compose started at Wed Oct 13 13:15:37 UTC 2010 Broken deps for x86_64 -- antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 gnome-pilot-conduits-2.0.17-4.fc13.x86_64 requires libgpilotdconduit.so.2()(64bit) gnome-pilot-conduits-2.0.17-4.fc13.x86_64 requires libgpilotd.so.2()(64bit) gnome-pilot-conduits-2.0.17-4.fc13.x86_64 requires libgpilotdcm.so.2()(64bit) intellij-idea-9.0.1.94.399-11.fc14.x86_64 requires jna-examples qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit) spacewalk-certs-tools-1.1.1-2.1.fc14.noarch requires spacewalk-backend-libs = 0:0.8.28 valide-0.6.1-0.22.20103003svn511.fc14.i686 requires libvala.so.0 valide-0.6.1-0.22.20103003svn511.fc14.x86_64 requires libvala.so.0()(64bit) Broken deps for i386 -- antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 gnome-pilot-conduits-2.0.17-4.fc13.i686 requires libgpilotdcm.so.2 gnome-pilot-conduits-2.0.17-4.fc13.i686 requires libgpilotd.so.2 gnome-pilot-conduits-2.0.17-4.fc13.i686 requires libgpilotdconduit.so.2 intellij-idea-9.0.1.94.399-11.fc14.i686 requires jna-examples qtgpsc-0.2.3-6.fc12.i686 requires libgps.so.18 spacewalk-certs-tools-1.1.1-2.1.fc14.noarch requires spacewalk-backend-libs = 0:0.8.28 valide-0.6.1-0.22.20103003svn511.fc14.i686 requires libvala.so.0 New package: erlang-gen_leader-0-0.2.fc14 A leader election behavior modeled after gen_server New package: motoya-lmaru-fonts-1.00-0.1.20100928git.fc14 Japanese Round Gothic-typeface TrueType fonts by MOTOYA Co,LTD Updated Packages: archimedes-0.9.1-1.fc14 --- * Sat Oct 02 2010 Chitlesh Goorah chitlesh [AT] fedoraproject DOT org - 0.9.1-1 - new upstream release drupal-cck-6.x.2.8-1.fc14 - * Mon Oct 04 2010 Jon Ciesla l...@jcomserv.net - 6.x.2.8-1 - New upstream, DRUPAL-SA-CONTRIB-2010-088. erlang-mochiweb-1.3-0.8.20100929git47fe37b.fc14 --- * Wed Sep 29 2010 Peter Lemenkov lemen...@gmail.com - 1.3-0.8.20100929git9687b40 - Narrowed BuildRequires - Restricted explicit requirement for obsoleted fd_server module (rhbz #601152) - Dropped upstreamed patch6 freetype-2.4.2-3.fc14 - * Wed Oct 06 2010 Marek Kasik mka...@redhat.com 2.4.2-3 - Add freetype-2.4.2-CVE-2010-3311.patch (Don't seek behind end of stream.) - Resolves: #638522 gnome-power-manager-2.32.0-3.fc14 - * Tue Oct 05 2010 Richard Hughes rich...@hughsie.com 2.32.0-3 - Rebuild for msgmerge floating point exception bug. Gah. * Tue Oct 05 2010 Richard Hughes rich...@hughsie.com 2.32.0-2 - Rebuild after glibc breakage. * Mon Sep 27 2010 Richard Hughes rich...@hughsie.com 2.32.0-1 - New upstream release. - Lots of translation updates. gnu-free-fonts-20100919-1.fc14 -- * Tue Oct 05 2010 Jon Ciesla l...@jcomserv.net 20100919-1 - New upstream. gplcver-2.12a-1.fc14 * Tue Oct 05 2010 Shakthi Kannan shakthimaan [AT] fedoraproject DOT org 2.12a-1 - Updated to upstream 2.12a version. - Remove dinotrace.dir entry as it is not available in this release. libimobiledevice-1.0.3-1.fc14 - * Mon Oct 04 2010 Peter Robinson pbrobin...@gmail.com 1.0.3-1 - New 1.0.3 release mash-0.5.20-1.fc14 -- * Tue Sep 28 2010 Bill Nottingham nott...@redhat.com 0.5.20-1 - solve multilib against parent repos if configured (#633136) - fix traceback when only binary RPMS exist (modified from #636697, tguthm...@iseek.com.au) - disable sigchecking on deltas in source, not via patch (#512454) - mark LSB-providing packages as multilib (#585858) - fix libmunge to catch more cases (#637172, mschwe...@gmail.com) - add krb5 plugin dir to multilib list (#632611) - add libstdc++-static as a multilib whitelist (#630581) - add dri as a multilib dir - arm arch compatiblitiy den...@ausil.us * Fri Jul 30 2010 Bill Nottingham nott...@redhat.com 0.5.19-1 - retarget branched.mash at f14 * Mon Jul 26 2010 Bill Nottingham nott...@redhat.com 0.5.18-1 - add F14 key (jkeat...@redhat.com) maven2-2.2.1-13.fc14 * Mon Sep 20 2010 Stanislav Ochotnicky sochotni...@redhat.com - 2.2.1-13 - Create dangling symlinks during install (Resolves rhbz#613866) * Fri Sep 17 2010 Stanislav Ochotnicky sochotni...@redhat.com - 2.2.1-12 - Update JPackageRepositoryLayout to handle signature packaging * Mon Sep 13 2010 Yong Yang yy...@redhat.com 2.2.1-11 - Add -P all-models to generate maven model v3 * Wed Sep 01 2010 Alexander Kurtakov akurt...@redhat.com 2.2.1-10 - Remove buildnumber-maven-plugins deps now that is fixed. - Use new package names in BR/R. - Use global instead of define. * Fri Aug 27 2010 Stanislav
Re: Ubuntu 10.10's installer looks rather nice
On Wed, 13 Oct 2010 08:23:23 -0700 Adam Williamson awill...@redhat.com wrote: On Wed, 2010-10-13 at 02:28 -0700, Jesse Keating wrote: Ok, so what you're saying is, that the specific case of having /boot on softraid didn't work for you. I may have missed that clarification in your first email. I do find it odd because I constantly test scenarios where /boot is a small mirror and / is a large stripe and it seems to work every time for me, often starting from blank disks. I'll test that scenario again soon, maybe there is something I'm doing that you're not, or vice versa? As I recall it, Jesse, Rudolf's right - there are known issues with having /boot on a soft RAID and that's why it's explicitly excluded from the release criteria. Unfortunately it's sufficiently long since FUDCon Toronto that I can't recall what the known issues were exactly, but anaconda team may. pre-upgrade doesn't work if boot is on raid. I don't remember other issues when you install from disk. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On 10/13/2010 05:21 PM, Adam Williamson wrote: On Wed, 2010-10-13 at 10:16 +0200, Gerd Hoffmann wrote: And it probably shouldn't be labeled Advanced ... but say what kind of advanced stuff is hidden there, i.e. the advanced storage button should be labeled Add SAN storage ... because this is what it actually is about. Now you can figure whenever you need that or not without klicking and looking, see? Nope, because that's not all it does. You also need the 'advanced' storage mode if you want to explicitly exclude disks from being considered during installation at all, which was previously part of the normal installation flow; now you're only shown that screen if you pick the 'advanced' mode. A button saying 'SAN storage and explicit device selection...' is rapidly getting uglier, and I'm sure there's other stuff that's in that path which that description still doesn't cover. This discussion is what you get when you try to make both groups happy with a single solution and in the end this usually kills any progress because not only do they not come to an agreement initially but even if they do any future changes now have to be agreed upon by both sides. This sort of tight coupling is exactly what should be avoided if you want to make both groups of users happy. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On 10/13/2010 10:53 AM, Gilboa Davara wrote: When installing Fedora on machine with -large- amount of drives (8-16), I simply use a single sfdisk script to create the same partition table on all drives. When dealing with smaller configurations (3-4 drives), Anaconda is OK. (At least to me) As for MBR: I assume that like me, you create a small RAID1 for /boot and RAIDX for the rest, hoping the first disk won't die on a DVD-less machine :) In-order to solve it (when I remember to do it :)), I simply dd 446 bytes from the first drive to every other drive. Just curious: you script the creation of an identical partition table, and then you copy 446 bytes which specifically copies the MBR without the partition table which is in bytes 447-512. Why not just copy the entire 512 bytes to all the disks from the first one? I guess one reason might be if the disks did not have identical CHS geometry, which can happen for the identically sized disks. I have heard rumors that even a single model drives had been seen with different geometries in different firmware revisions. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: A comps group for the Design Suite
Nicu Buculei (nicu_fed...@nicubunu.ro) said: There appears to be a lot of overlap here with the graphics group (and some with other groups). Perhaps it's best to just expand that group into a more full-fledged design suite? They are different things: the graphics group is the sum of all packages about graphics, a design suite group would be a way for people to install the Design Suite Spin (a collection of best of breed apps) if they already have Fedora installed. Right, but I'm saying that the Design Suite group might be more appropriate in all cases. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ethtool not in default system anymore?
Matthew Miller (mat...@mattdm.org) said: On Tue, Oct 12, 2010 at 07:06:50PM -0500, Chris Adams wrote: It looks like up through F12, initscripts required ethtool (so it was definately installed by default). I see this in the RPM changelog: Still the case in RHEL5, FWIW. I'm assuming you mean RHEL 6; it just seemed too big of a change to debut in RHEL at the time we branched. However, it has worked pretty well in Fedora so far to just rely on the carrier attribute in sysfs. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
THREE Days Remain to Fix Fedora 14 Blocker Bugs
Hello Fedora 14 Blocker Bug Owners (all copied on this message), The list of bugs below are currently blocking the final release of Fedora 14. Updates fixing these bugs MUST be ready on Monday, 2010-10-18 (Final Change Deadline) or Release Engineering will be unable to create the Final Release Candidate on time, resulting in the possibility of a delayed release. We need your help *NOW*. As a maintainer, here is how you can help ... 639146 :: NEW :: xorg-x11-drv-intel :: a...@redhat.com :: Blank display (backlight on) after KMS initialization :: https://bugzilla.redhat.com/show_bug.cgi?id=639146 * next steps ... 1) We still really really need feedback from maintainer (no feedback yet) 2) Request additional help from FESCo 642358 :: NEW :: anaconda :: akozu...@redhat.com :: Up arrow tries to run gnome-screenshot :: https://bugzilla.redhat.com/show_bug.cgi?id=642358 * next steps ... 1) Maintainer and reporter work to identify scope and root cause 2) Please update comments with plan of attack and ETA for resolution 641846 :: NEW :: gnome-panel :: rstr...@redhat.com :: Panel applets (clock, workspace switcher, window selector, ...) randomly disappear :: https://bugzilla.redhat.com/show_bug.cgi?id=641846 * next steps ... 1) Still awaiting maintainer feedback 2) If we don't hear a response in the comments by tomorrow we will remove as a blocker bug 641474 :: ASSIGNED :: lvm2 :: a...@redhat.com :: libdm does not present method to assign UUID after map creation :: https://bugzilla.redhat.com/show_bug.cgi?id=641474 * next steps ... 1) Waiting for new build from maintainer 641476 :: ASSIGNED :: kernel :: a...@redhat.com :: devicemapper UUID field cannot be assigned after map creation :: https://bugzilla.redhat.com/show_bug.cgi?id=641476 * next steps ... 1) Waiting for new build from maintainer 635778 :: ASSIGNED :: anaconda :: b...@redhat.com :: IndexError: list index out of range :: https://bugzilla.redhat.com/show_bug.cgi?id=635778 * next steps ... 1) Need feedback from maintainer 584328 :: ASSIGNED :: python-pyblock :: dleh...@redhat.com :: AttributeError: 'NoneType' object has no attribute 'name' :: https://bugzilla.redhat.com/show_bug.cgi?id=584328 * next steps ... 1) Patches under review, build and submit update (dependent on bug#641476 and bug#641474) 641338 :: ASSIGNED :: qemu :: jfor...@redhat.com :: f14 qemu-kvm KDE guests boot very slowly :: https://bugzilla.redhat.com/show_bug.cgi?id=641338 * next steps ... 1) Feedback in bug comments indicate the bug occurs in a non-default configuration, need confirmation from KDE-SIG before removing from list 642557 :: ASSIGNED :: pungi :: jkeat...@redhat.com :: after a split-media install, system fails to boot :: https://bugzilla.redhat.com/show_bug.cgi?id=642557 * next steps ... 1) Needs feedback from pungi maintainer 640766 :: ASSIGNED :: kernel :: linvi...@redhat.com :: b43legacy wlan0 fails DHCP requests :: https://bugzilla.redhat.com/show_bug.cgi?id=640766 * next steps ... 1) Maintainer and reporter work to resolve issue and submit update as soon as possible--no feedback to previous request 620635 :: ASSIGNED :: antlr3 :: xja...@fi.muni.cz :: antlr3 needs to be rebuilt against python 2.7 in F14 and devel :: https://bugzilla.redhat.com/show_bug.cgi?id=620635 * next steps ... 1) Verify proposed fix 2) Maintainer submits bodhi update(s) to correct issue 625894 :: ASSIGNED :: mesa :: airl...@redhat.com :: kwin freezes when changing related settings in systemsettings while compositing is active :: https://bugzilla.redhat.com/show_bug.cgi?id=625894 * next steps ... 1) Waiting on new mesa build and status update from airlied 642483 :: MODIFIED :: anaconda :: dleh...@redhat.com :: Remove the 'Pre-release Software' Warning Screen :: https://bugzilla.redhat.com/show_bug.cgi?id=642483 * next steps ... 1) Waiting on new anaconda build 642617 :: MODIFIED :: dracut :: har...@redhat.com :: Add cryptsetup-luks to dracut requirements again :: https://bugzilla.redhat.com/show_bug.cgi?id=642617 * next steps ... 1) Verify issue is fixed by proposed bodhi update (https://admin.fedoraproject.org/updates/dracut-006-3.fc14) ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: THREE Days Remain to Fix Fedora 14 Blocker Bugs
On Wed, Oct 13, 2010 at 09:57:48AM -0700, John Poelstra wrote: 640766 :: ASSIGNED :: kernel :: linvi...@redhat.com :: b43legacy wlan0 fails DHCP requests :: https://bugzilla.redhat.com/show_bug.cgi?id=640766 * next steps ... 1) Maintainer and reporter work to resolve issue and submit update as soon as possible--no feedback to previous request Added a comment already, probably as you were composing your message. In short, I don't think this should qualify as a blocker -- the problem he is reporting is intermittent and has existed for a long time and the hardware he is using is increasingly uncommon. John -- John W. LinvilleThe truth will set you free, but first it will linvi...@redhat.com make you miserable. -- James A. Garfield ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: A comps group for the Design Suite
On Wed, Oct 13, 2010 at 11:50:09AM -0400, Bill Nottingham wrote: They are different things: the graphics group is the sum of all packages about graphics, a design suite group would be a way for people to install the Design Suite Spin (a collection of best of breed apps) if they already have Fedora installed. Right, but I'm saying that the Design Suite group might be more appropriate in all cases. Yeah. I've *never* found the graphics group to be useful. I almost always only want specific applications, and the categorization isn't as useful as searching. Making a group with thoughtfully-picked choices sounds great. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ethtool not in default system anymore?
On Wed, Oct 13, 2010 at 11:54:43AM -0400, Bill Nottingham wrote: It looks like up through F12, initscripts required ethtool (so it was definately installed by default). I see this in the RPM changelog: Still the case in RHEL5, FWIW. I'm assuming you mean RHEL 6; it just seemed too big of a change to debut in RHEL at the time we branched. However, it has worked pretty well in Fedora so far to just rely on the carrier attribute in sysfs. No, I mean in current RHEL5, ethtool is required by initscripts. Maybe that happened somewhere in one of the point releases? -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ethtool not in default system anymore?
Matthew Miller (mat...@mattdm.org) said: On Wed, Oct 13, 2010 at 11:54:43AM -0400, Bill Nottingham wrote: It looks like up through F12, initscripts required ethtool (so it was definately installed by default). I see this in the RPM changelog: Still the case in RHEL5, FWIW. I'm assuming you mean RHEL 6; it just seemed too big of a change to debut in RHEL at the time we branched. However, it has worked pretty well in Fedora so far to just rely on the carrier attribute in sysfs. No, I mean in current RHEL5, ethtool is required by initscripts. Maybe that happened somewhere in one of the point releases? The change to drop the required ethtool use in initscripts was in F-13... it's not something that would be backported to RHEL 5 ever (and almost certainly won't be backported to RHEL 6.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: THREE Days Remain to Fix Fedora 14 Blocker Bugs
On Wed, Oct 13, 2010 at 09:57:48 -0700, John Poelstrapoels...@redhat.com wrote: 641476 :: ASSIGNED :: kernel :: a...@redhat.com :: devicemapper UUID field cannot be assigned after map creation :: https://bugzilla.redhat.com/show_bug.cgi?id=641476 * next steps ... 1) Waiting for new build from maintainer 2.6.35.6-42.fc14 has the follopwing in its changelog: Changelog * Tue Oct 12 2010 Kyle McMartink...@redhat.com 2.6.35.6-42 - Fix devicemapper UUID field cannot be assigned after map creation (rhbz#641476) thanks pjo...@. I haven't tested for that particular issue, but am running that kernel on three machines right now and am not seeing any regressions versus other 2.6.35 kernels. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please review (take 2): [Bug 602456] Allow to add any cn=config attributes; allow to delete some cn=config attributes
https://bugzilla.redhat.com/show_bug.cgi?id=602456
https://bugzilla.redhat.com/attachment.cgi?id=453261action=diff
https://bugzilla.redhat.com/attachment.cgi?id=453261action=edit
Thanks to Nathan for his review on the first proposal. I'm adding this
change following Rich's suggestion.
Following the suggestion by Rich, adding nsslapd-securelistenhost to the
default nsslapd-allowed-to-delete-attrs list.
diff --git a/ldap/servers/slapd/libglobs.c b/ldap/servers/slapd/libglobs.c
index 6b58dde..a7cc1bc 100644
--- a/ldap/servers/slapd/libglobs.c
+++ b/ldap/servers/slapd/libglobs.c
@@ -1013,6 +1013,8 @@ FrontendConfig_init () {
cfg-entryusn_global = LDAP_OFF;
slapi_ch_array_add((cfg-allowed_to_delete_attrs),
slapi_ch_strdup(nsslapd-listenhost));
+ slapi_ch_array_add((cfg-allowed_to_delete_attrs),
+ slapi_ch_strdup(nsslapd-securelistenhost));
#ifdef MEMPOOL_EXPERIMENTAL
cfg-mempool_switch = LDAP_ON;
Description:
1. Originally, configuration attributes are designed not to allow
adding or deleting, but to allow just replacing. Due to a defect
in checking the add operation, adding (LDAP_MOD_ADD) is not rejected.
Instead of fixing the add checking to disallow adding, this patch
logs the operation in the error log.
2. On the other hand, deleting configuration attributes is rejected
by LDAP_UNWILLING_TO_PERFORM. We have a request that some attributes
need to allow to delete. This patch introduces a config attribute
nsslapd-allowed-to-delete-attrs, which value is configuration
attributes separated by a space ' '. If an attribute is in the list,
the attribute is allowed to delete. The delete operation is also
logged in the error log.
By default, the list contains nsslapd-listenhost and
nsslapd-securelistenhost.
Files:
ldap/servers/slapd/configdse.c
ldap/servers/slapd/libglobs.c
ldap/servers/slapd/proto-slap.h
ldap/servers/slapd/slap.h
Thanks,
--noriko
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
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: Need help for Gimp 2.7.1
On Sat, Jul 3, 2010 at 12:10 PM, Luya Tshimbalanga l...@fedoraproject.org wrote: Hello, I attempted to build a new version of Gimp 2.7.1 using Koji scratch method but ended up with that result[1]. Here is attached spec file borrowed from Nils as I wanted to experiment that version along with Design. Can anyone check what went wrong. Thanks [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=2291828 Anybody tried making GIMP 2.7/2.8 packages and making them available via http://repos.fedorapeople.org/ ? I would love to test out GIMP 2.7/2.8 on Fedora but haven't seen any RPM packages made for Fedora. If anybody knows of them please send me the link. Thank you, Valent. -- 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
[perl-GTop/f14/master] - exclude the threads test also on s390
commit 74d77efc9d53f72d4a8a141f039b186c589e686e
Author: Dan Horák d...@danny.cz
Date: Wed Oct 13 21:04:45 2010 +0200
- exclude the threads test also on s390
perl-GTop.spec |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
---
diff --git a/perl-GTop.spec b/perl-GTop.spec
index 0210180..10ab40a 100644
--- a/perl-GTop.spec
+++ b/perl-GTop.spec
@@ -1,6 +1,6 @@
Name: perl-GTop
Version:0.16
-Release:11%{?dist}
+Release:12%{?dist}
Summary:Perl interface to libgtop
License:GPL+ or Artistic
Group: Development/Libraries
@@ -33,8 +33,8 @@ real-time performance and other system statistics.
find . -type f -exec chmod -c -x {} \;
perl -pi -e 's|^#!perl|#!/usr/bin/perl|' examples/*
-# thread funkiness on ppc
-%ifarch ppc ppc64
+# thread funkiness on ppc/s390
+%ifarch ppc ppc64 s390
mv t/threads.t t/threads.t.disable
%endif
@@ -68,6 +68,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/*
%changelog
+* Wed Oct 13 2010 Dan Horák dan[at]danny.cz - 0.16-12
+- exclude the threads test also on s390
+
* Sun May 02 2010 Marcela Maslanova mmasl...@redhat.com - 0.16-11
- Mass rebuild with perl-5.12.0
--
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
[perl-GTop] - exclude the threads test also on s390
Summary of changes: 74d77ef... - exclude the threads test also on s390 (*) (*) This commit already existed in another branch; no separate mail sent -- 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: Any comments about the latest version of mono on my site?
Hi Paul, On 10/06/2010 04:26 PM, Paul F. Johnson wrote: A couple of days back I uploaded preview 8 of mono-2.8 for comments but have heard nothing back. The move to 2.8 will require a good number of rebuilds as 2.8 has had all the .NET 1.1 stuff removed. Do all mono packages have to be recompiled or only the ones which use .NET 1.1 stuff? Is there an easy way (besides recompiling against 2.8) to determine whether a package uses .NET 1.1? Best regards, Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On Wed, 2010-10-13 at 11:50 -0400, Przemek Klosowski wrote: Just curious: you script the creation of an identical partition table, and then you copy 446 bytes which specifically copies the MBR without the partition table which is in bytes 447-512. Why not just copy the entire 512 bytes to all the disks from the first one? I guess one reason might be if the disks did not have identical CHS geometry, which can happen for the identically sized disks. I have heard rumors that even a single model drives had been seen with different geometries in different firmware revisions. I'm paranoid, that why :) While in most machines, I have identical drives from the same manufacturer, in others, I specifically buy drive of the same size, but from different manufacturers and even different dates to reduce the risk of simultaneous death of multiple drives. (Same drive, same manufacturer, same batch, same day, etc) As you pointed out, different drives, can have more-or-less identical partition size, with different CHS in the partition table. As I don't trust myself to use the -right- size every time (446 vs 512), I simply assume the worse. -- Gilboa Davara http://www.wirex-systems.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Building mono-2.8 for 64 bit - possible solution to the problem
Hi,
In the wee small hours (UK time), I submitted mono-2.8 to koji.
Unfortunately, it failed to build for 64 bit systems and gave the
following error
In file included from sgen-gc.c:784:0:
sgen-los.c: In function 'los_scan_card_table':
sgen-los.c:482:21: warning: initialization from incompatible pointer
type
sgen-los.c:501:15: warning: comparison of distinct pointer types lacks a
cast
sgen-gc.c: At top level:
sgen-cardtable.c:229:1: warning: 'collect_faulted_cards' defined but not
used
{standard input}: Assembler messages:
{standard input}:24487: Error: @TLSLDM reloc is not supported with
64-bit output format
{standard input}:24487: Error: junk `...@tlsld' after expression
make[3]: *** [libmonoruntimesgen_la-sgen-gc.lo] Error 1
After Googling around, I think I've hit the cause - it's down to the
cross compiler used on koji (or could be). I found this...
http://www.mail-archive.com/unattended-de...@lists.sourceforge.net/msg02316.html
which seems to point to the cross compilation being the problem for
building mono on the 64 bit buildsys.
Could someone please confirm this is the problem before I bung it into
the big red lizard for fixing? If it is the problem, what component to I
file it against?
Thanks
Paul
--
Vertraue mir, ich weiss, was ich mache...
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
Peter Lemenkov wrote: 2010/10/4 Martin Stransky stran...@redhat.com: FIXED UPSTREAM is a correct resolution for the bug, and it has been fixed by upstream and came to F13 in firefox 3.6.x. That's an absolutely great tactics to deal with bug reports! And that's why I call proprietary Mozilla software as unmaintainable - you doesn't and you can't fix issues (in this case you did close two tickets but both issues are still remains unresolved). Well, normally it's the s390 arch team's job to fix the build on s390, and they should have commit access to all packages, even Firefox. If that's not the case, talk to the infrastructure team to get the required access. But I agree that closing it as fixed in a more recent Fedora release is completely unacceptable for a build fix which prevents shipping the package at all on that architecture. This MUST be fixed in the F12 branch. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: docbook and glibc breakage [STILL BREAKING EVERYTHING]
Richard Hughes wrote: Set POSIXLY_CORRECT to default in F14, and leave it like upstream in F15. It's totally the wrong time for this kind of change. POSIXLY_CORRECT has a lot of other effects which will break tons of packages, e.g. it disables all bash extensions! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: THREE Days Remain to Fix Fedora 14 Blocker Bugs
On Wed, 2010-10-13 at 13:15 -0500, Bruno Wolff III wrote: On Wed, Oct 13, 2010 at 09:57:48 -0700, John Poelstrapoels...@redhat.com wrote: 641476 :: ASSIGNED :: kernel :: a...@redhat.com :: devicemapper UUID field cannot be assigned after map creation :: https://bugzilla.redhat.com/show_bug.cgi?id=641476 * next steps ... 1) Waiting for new build from maintainer 2.6.35.6-42.fc14 has the follopwing in its changelog: Changelog * Tue Oct 12 2010 Kyle McMartink...@redhat.com 2.6.35.6-42 - Fix devicemapper UUID field cannot be assigned after map creation (rhbz#641476) thanks pjo...@. I haven't tested for that particular issue, but am running that kernel on three machines right now and am not seeing any regressions versus other 2.6.35 kernels. If we're going to need a post-39 kernel for final anyway could I possibly get you to pull in the patch for https://bugzilla.redhat.com/show_bug.cgi?id=641468 ? It makes the touchpad work on my laptop, which is a reasonably popular model, and it's a pretty safe change which has already been taken upstream. I proposed the bug as NTH but it hasn't been reviewed yet. -- 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: Building mono-2.8 for 64 bit - possible solution to the problem
{standard input}: Assembler messages:
{standard input}:24487: Error: @TLSLDM reloc is not supported with
64-bit output format
{standard input}:24487: Error: junk `...@tlsld' after expression
make[3]: *** [libmonoruntimesgen_la-sgen-gc.lo] Error 1
This is certainly a case of compiling i386 code and then trying to link it
as x86-64 (or with other code compiled for x86-64).
After Googling around, I think I've hit the cause - it's down to the
cross compiler used on koji (or could be). I found this...
http://www.mail-archive.com/unattended-de...@lists.sourceforge.net/msg02316.html
which seems to point to the cross compilation being the problem for
building mono on the 64 bit buildsys.
If what you really intend is to compile i[3-6]86 code in an x86_64 rpm,
then indeed you need to make sure that you are passing -m32 for all
the compiler invocations any compilation or linking of the 32-bit code.
Thanks,
Roland
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Building mono-2.8 for 64 bit - possible solution to the problem
Hi, After Googling around, I think I've hit the cause - it's down to the cross compiler used on koji (or could be). I found this... koji doesn't cross compile at all. In that case, it looks like TLS support is not in the 64 bit version of glibc... TTFN Paul -- Vertraue mir, ich weiss, was ich mache... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2010-10-05)
Bruno Wolff III wrote: There was also talk about whether or not it would be allowed for there to be a separate Iceweasel package in Fedora. This might be done to test the feasibility of maintaining it. There were mixed feelings about this amoung FESCO. This is essentially not feasible because most of the disputed patches are in xulrunner, and a hypothetical separate Iceweasel package would share xulrunner with Firefox, unless we have even more bundled libraries. I also don't see what we have to gain from shipping both. So it's really an either-or situation. IMHO, the version which is not compliant with our guidelines needs to go away, period. We need to stop treating Mozilla specially, it needs to be held by the same rules as any other upstream. If they don't cooperate, it's the maintainer's job to fix things or orphan it. If nobody picks it up when orphaned, it should be retired like any other package. Firefox is NOT an essential package, the GNOME spin could just ship Epiphany (GNOME's default browser) instead, and other desktop spins ALREADY ship the respective desktop's default instead of Firefox! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Building mono-2.8 for 64 bit - possible solution to the problem
Hi,
{standard input}: Assembler messages:
{standard input}:24487: Error: @TLSLDM reloc is not supported with
64-bit output format
{standard input}:24487: Error: junk `...@tlsld' after expression
make[3]: *** [libmonoruntimesgen_la-sgen-gc.lo] Error 1
This is certainly a case of compiling i386 code and then trying to link it
as x86-64 (or with other code compiled for x86-64).
In previous incarnations of mono, this has worked without a hitch
After Googling around, I think I've hit the cause - it's down to the
cross compiler used on koji (or could be). I found this...
http://www.mail-archive.com/unattended-de...@lists.sourceforge.net/msg02316.html
which seems to point to the cross compilation being the problem for
building mono on the 64 bit buildsys.
If what you really intend is to compile i[3-6]86 code in an x86_64 rpm,
then indeed you need to make sure that you are passing -m32 for all
the compiler invocations any compilation or linking of the 32-bit code.
I'm not sure in this case. As I've said, the last version (2.6.7-3)
build fine on the 64 bit boxes without the need to pass any flags to the
compiler so either Novell has messed with something or the buildsys is
not being nice to me. Can't decide which...
TTFN
Paul
--
Vertraue mir, ich weiss, was ich mache...
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
Hi. On Wed, 13 Oct 2010 22:26:18 +0200, Gilboa Davara wrote As you pointed out, different drives, can have more-or-less identical partition size, with different CHS in the partition table. I my experience the hard disk vendors have been astonishingly coordinated in how much sectors a drive of a given size should have. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
Matej Cepl wrote: No need to call it “political reasons” (on the side of MoFo) ... nowhere in the definition of free software is written, that upstream has to accept your patches. It may happen upstream (any upstream) disagrees with your patch, you may not agree with them, but in the end it is their decision and if you don't agree you can either suck it up or fork. Both alternatives are still freely open for you (and Fedora as whole) in MoFo case as well (just to make this clear). With any other upstream, we can just patch it in Fedora if upstream rejects the patch. Mozilla is abusing trademark law to prevent us from doing that, making the package effectively unmaintainable in the distribution, and leaving a rename as the only reasonable solution. If there is any political reason, then it is Fedora/RH policy to oblige with upstream trademark terms and to keep our Firefox/Thunderbird/ XULRunner as close to the upstream as possible to save us work maintaining our patches and not go Iceweasel way. No. It is Fedora's policy for all packages to follow Fedora guidelines, even where they conflict with upstream. Staying close to upstream is only one of the SHOULD guidelines and as such NEVER trumps MUST guidelines such as no bundled libs. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Building mono-2.8 for 64 bit - possible solution to the problem
Hi, It seems nearly certain that the Mono code broke to do something dumb. Quite possibly... Have you built it by hand on any x86-64 system? I would if I had a 64 bit box... TTFN Paul -- Vertraue mir, ich weiss, was ich mache... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: trademarks [was: xulrunner 2.0 in rawhide (F15) bundles several system libs]
Tomas Mraz wrote: The problem here really is that some not so important? projects are forced to accept all the restrictions and requirements and other more important? projects get a free pass from them. This is unfortunate and it does not improve the spirit of the package maintainers. Yes, this is the outrageous part! Mozilla should be held by the same guidelines as all the other packages in Fedora. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: trademarks [was: xulrunner 2.0 in rawhide (F15) bundles several system libs]
Nathaniel McCallum wrote: I don't see any conflict between Fedora's policy and Mozilla's policy. Both say that if you redistribute and change code you have to re-trademark. Those policies are fair and sensible. We can either patch and re-trademark Firefox or ship upstream. One of the values of Fedora is stay close to upstream. Another value is the Firefox brand. This is a no-brainer choice for Fedora: ship upstream Firefox. I really can't believe this thread is as long as it is. It's not a no-brainer at all, because, as you say: The only possible room for debate that I see is that there is, in Firefox, a potential conflict between our ship upstream and don't bundle libs values. We have FESco to sort that out. and because that's a MUST policy whereas staying close to upstream is a SHOULD. So IMHO the no-brainer is that the MUST policy has to be followed and that Firefox must be rebranded if that's the only way to follow it. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
drago01 wrote: On Tue, Oct 5, 2010 at 2:34 PM, Brandon Lozza bran...@pwnage.ca wrote: That's not free. It is, as you are _free_ to change the name and artwork anytime you want. But it's not free FOR US as long as we don't actually do that, because we're bound by the trademark policies, which is preventing us from shipping a package complying to our guidelines. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: trademarks [was: xulrunner 2.0 in rawhide (F15) bundles several system libs]
Brandon Lozza wrote: I think an exception should be made for Chromium too. No. Just no. The exceptions for Firefox need to stop NOW, i.e. no new ones should be granted and the ones that have already been granted repealed/discontinued. Giving yet another package a free pass is going in the entirely wrong direction. (That said, I really don't see why Firefox gets a free pass while Chromium doesn't.) Having a more secure browser would benefit the main repositories. We already have Konqueror which is more secure than either Firefox or Chromium. (There have been much fewer security vulnerabilities in KHTML than either Gecko or WebKit. All the WebKit issues have been checked for reproducibility in KHTML and most weren't reproducible.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
Adam Williamson wrote: I think you're unnecessarily muddying up a simple practical discussion (how do we go about getting these bundled libs removed) with overheated ideological rhetoric, and it really isn't helping anyone get anything done. Bullsh*t! He's explaining very precisely and factually why it is completely reasonable to expect the Mozilla maintainers to unbundle the libs. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
Peter Jones wrote: On 10/06/2010 10:08 AM, Brandon Lozza wrote: On 10/6/10, Matej Cepl mc...@redhat.com wrote: I won't comment on the trademark issue (because that's just pure lunacy), but let me comment here they don't accept my patches, so they are non- free. That's just nonsense ... Yes it is, that's not the issue. They aren't letting us distribute it ourselves, unless its brand is removed or we don't make those changes. On the contrary, distribution is the thing they *are* allowing. He's talking about distribution WITH THE PATCHES THEY REJECTED (something pretty much ANY other upstream allows, even if they often frown upon it to some extent). So you're missing the point. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
On Thu, 2010-10-14 at 00:17 +0200, Kevin Kofler wrote: Adam Williamson wrote: I think you're unnecessarily muddying up a simple practical discussion (how do we go about getting these bundled libs removed) with overheated ideological rhetoric, and it really isn't helping anyone get anything done. Bullsh*t! He's explaining very precisely and factually why it is completely reasonable to expect the Mozilla maintainers to unbundle the libs. You appear to have just arrived in your time machine. It's the year 2010, and the President is Barack Obama. Sorry, no flying cars yet. Bummer, I know. -- 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: xulrunner 2.0 in rawhide (F15) bundles several system libs
Adam Williamson wrote: Practically speaking, it would add an extra burden to the maintainers, who already do not have enough resources to deal with all the issues. Again, the reason we don't carry non-upstream patches in Firefox has nothing to do with the branding issue. It's because we don't have the resources to maintain non-upstream patches in Firefox. Nonsense. * Whenever somebody complains about the Firefox maintainers rejecting non- upstream patches, they give the trademarks as the reason. * Whenever somebody complains about the branding, they claim it doesn't matter because we aren't carrying non-upstream patches anyway. That's a very circular argument. Please don't fall for it. There are some very concrete practical reasons for shipping some non- upstream patches, unbundling libraries is one of those. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: THREE Days Remain to Fix Fedora 14 Blocker Bugs
On Wed, Oct 13, 2010 at 14:37:22 -0700, Adam Williamson awill...@redhat.com wrote: If we're going to need a post-39 kernel for final anyway could I possibly get you to pull in the patch for If by you, you mean me, I don't have any commit access to kernels, I just like to try out new koji kernel builds right away. I commented on that bug because I noticed the description of the blocker bug matched a kernel rpm changelog entry I had read the day before. But the status didn't seem to take into account the latest kernel build. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/13/2010 03:21 PM, Kevin Kofler wrote: * Whenever somebody complains about the Firefox maintainers rejecting non- upstream patches, they give the trademarks as the reason. Actually what I've seen from the maintainers is that they wouldn't take the patch if upstream wouldn't take it, regardless of trademarks. They feel that if it's not acceptable for upstream, it's not acceptable for Fedora. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAky2M+YACgkQ4v2HLvE71NWgHQCgg3WNbNpPC6C9LPM/DLkQINbG KssAoJUPqKeU54NW0AoThHgJ+ekPVQ0x =8eGS -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
Thorsten Leemhuis wrote: * Why haven't those that want iceweasel and icedove in Fedora not simply invested some time and got them integrated into the repository?(¹) Because having both Iceweasel and Firefox in the repository, in addition to being stupid by itself, would also mean shipping 2 different versions of xulrunner (because there's where most of the offending patches live). And besides, it's not that we want Iceweasel, it's that we DO NOT WANT Firefox since it does not follow Fedora policies. Having both would not actually solve any problem. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
On Wed, 2010-10-13 at 15:32 -0700, Jesse Keating wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/13/2010 03:26 PM, Adam Williamson wrote: On Thu, 2010-10-14 at 00:17 +0200, Kevin Kofler wrote: Adam Williamson wrote: I think you're unnecessarily muddying up a simple practical discussion (how do we go about getting these bundled libs removed) with overheated ideological rhetoric, and it really isn't helping anyone get anything done. Bullsh*t! He's explaining very precisely and factually why it is completely reasonable to expect the Mozilla maintainers to unbundle the libs. You appear to have just arrived in your time machine. It's the year 2010, and the President is Barack Obama. Sorry, no flying cars yet. Bummer, I know. Neither of the last two replies here are examples of being excellent to each other. Please either take it off list, or be more civil. Er, really? I don't see where I offered any insult or un-excellent-ness. I just meant it as a vaguely humorous way of wondering why Kevin was replying to an email I sent over a week ago in a discussion which I thought had pretty much finished already. -- 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: xulrunner 2.0 in rawhide (F15) bundles several system libs
On Thu, 2010-10-14 at 00:36 +0200, Kevin Kofler wrote: Thorsten Leemhuis wrote: * Why haven't those that want iceweasel and icedove in Fedora not simply invested some time and got them integrated into the repository?(¹) Because having both Iceweasel and Firefox in the repository, in addition to being stupid by itself, would also mean shipping 2 different versions of xulrunner (because there's where most of the offending patches live). And besides, it's not that we want Iceweasel, it's that we DO NOT WANT Firefox since it does not follow Fedora policies. Having both would not actually solve any problem. Proving that we can package Iceweasel and Icedove into Fedora and wind up with workable software is a big step on that road, though. I think making Iceweasel and Icedove packages and then floating the proposal switch from these guideline-infringing Firefox and Thunderbird packages to these non-guideline-infringing Iceweasel and Icedove packages that already exist and are tested would get much more momentum than just complaining that the Firefox and Thunderbird packages are infringing. -- 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: xulrunner 2.0 in rawhide (F15) bundles several system libs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/13/2010 03:37 PM, Adam Williamson wrote: Er, really? I don't see where I offered any insult or un-excellent-ness. I just meant it as a vaguely humorous way of wondering why Kevin was replying to an email I sent over a week ago in a discussion which I thought had pretty much finished already. Sarcasm, particularly snide sarcasm, doesn't always translate well across language barriers. Also it's rather difficult to tell tone and intention from raw text. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAky2N1oACgkQ4v2HLvE71NUsewCePeA5zLVah4SC+a2BPA4U31f4 RTQAnicAVmxfxsXSeZY+X/QnoqHUgvC3 =plrg -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
On Wed, Oct 13, 2010 at 6:46 PM, Adam Williamson awill...@redhat.com wrote: On Thu, 2010-10-14 at 00:36 +0200, Kevin Kofler wrote: Thorsten Leemhuis wrote: * Why haven't those that want iceweasel and icedove in Fedora not simply invested some time and got them integrated into the repository?(¹) Because having both Iceweasel and Firefox in the repository, in addition to being stupid by itself, would also mean shipping 2 different versions of xulrunner (because there's where most of the offending patches live). And besides, it's not that we want Iceweasel, it's that we DO NOT WANT Firefox since it does not follow Fedora policies. Having both would not actually solve any problem. Proving that we can package Iceweasel and Icedove into Fedora and wind up with workable software is a big step on that road, though. I think making Iceweasel and Icedove packages and then floating the proposal switch from these guideline-infringing Firefox and Thunderbird packages to these non-guideline-infringing Iceweasel and Icedove packages that already exist and are tested would get much more momentum than just complaining that the Firefox and Thunderbird packages are infringing. Iceweasel as it currently exists in debian currently bundles exactly the same media libraries. (http://packages.debian.org/source/experimental/iceweasel — notice the lack of dependency on libvorbis,libtheora,libvpx,libogg,etc) It's facts like these that put the lie to the ridiculous claim that the media library bundling has much of anything to do with trademarks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
Hello Kevin, On Wednesday, October 13, 2010, 5:30:52 PM, you wrote: Well, normally it's the s390 arch team's job to fix the build on s390, and they should have commit access to all packages, even Firefox. If that's not the case, talk to the infrastructure team to get the required access. But I agree that closing it as fixed in a more recent Fedora release is completely unacceptable for a build fix which prevents shipping the package at all on that architecture. This MUST be fixed in the F12 branch. Kevin Kofler Kevin, Reality checks: 1) Do you _really_ think that there is much use of desktops (let alone desktop applications such as Firefox) on zSeries? Most folks doing it are likely using emulation (Hercules), for the usual educational and developmental purposes. These folks will use the native browser, not the slower emulated system one. Unless you have a dedicated LPAR or VM, running desktop apps is quite rare on real zSeries hardware. It is mostly for bragging rights. Every now and then folks with z10 or later hardware (which finally is leading edge CPU performance) will experiment with bringing up a desktop environment like Gnome. Older hardware requires significant patience. It isn't something that one would do on a production server, where you pay for CPU consumed. In reality those servers would be almost exclusively RHEL. 2) For several releases, s390x secondary architecture was not very active. That has changed with F14, which is causing significant excitement on mailing lists such as linux-...@vm.marist.edu. The s390x team decides where they invest their limited resources. F14 is where they made the wise decision to focus - that equine is not deceased, but chomping at the bit. F14 on zSeries is a very viable release for application porting and development, whether on real hardware or emulation. Mostly using non-GUI means. I would expect nearly all downstream production systems would be RHEL systems. 3) If there is anything that fits in the do not touch category, it would be a core package on a secondary architecture on a release no one is using that is nearing EOL. It might be best to find a better target to rant and rave on both Firefox and the stable release vision. Or just let it go. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
Gregory Maxwell wrote: Iceweasel as it currently exists in debian currently bundles exactly the same media libraries. CURRENTLY. The Debian Iceweasel maintainer has attached a patch to the upstream bug which makes it use the system libvpx, we'd just need to apply that patch. And besides, how Debian enforces or not their guideline to not bundle libraries is not really our problem. What matters is that a patch exists and should be applied. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Building mono-2.8 for 64 bit - possible solution to the problem
Paul F. Johnson wrote:
In file included from sgen-gc.c:784:0:
sgen-los.c: In function 'los_scan_card_table':
sgen-los.c:482:21: warning: initialization from incompatible pointer
type
sgen-los.c:501:15: warning: comparison of distinct pointer types lacks a
cast
Those might be 64-bit-safety issues, depending on what the 2 offending
pointer types are.
sgen-gc.c: At top level:
sgen-cardtable.c:229:1: warning: 'collect_faulted_cards' defined but not
used
This is harmless.
{standard input}: Assembler messages:
{standard input}:24487: Error: @TLSLDM reloc is not supported with
64-bit output format
{standard input}:24487: Error: junk `...@tlsld' after expression
make[3]: *** [libmonoruntimesgen_la-sgen-gc.lo] Error 1
This is the error. Is there any inline assembly being used? I suspect that
there's 32-bit-only inline assembly involved here (unless it's C code being
compiled to assembly with -m32 and then assembled as 64-bit or some other
completely stupid thing like that, but inline assembly is my #1 suspect).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Building mono-2.8 for 64 bit - possible solution to the problem
Roland McGrath wrote: If what you really intend is to compile i[3-6]86 code in an x86_64 rpm, then indeed you need to make sure that you are passing -m32 for all the compiler invocations any compilation or linking of the 32-bit code. Uh, -m32 is not supposed to get used in Fedora builds, in fact it will normally not work because there are no 32-bit libraries in the buildroot. And the problem at hand might even be caused by -m32 (ab)use in the first place. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging dwm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/13/2010 02:04 AM, Petr Sabata wrote: The problem here: dwm is configured solely in C and has to be recompiled every time a user wants to change their settings (appearance, behavior, shortcuts, etc). Am i the only one that finds it hilarious that this thing is named Dynamic Window Manager? So dynamic, you gotta recompile to change anything - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAky2SzcACgkQ4v2HLvE71NXNjQCgtXXtb7KulAONn8VLTsYxF7Am fPcAn1MsS8BYrIcnd1ffKqkLwUUstsNd =aRwf -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ethtool not in default system anymore?
On Wed, 13.10.10 16:03, Jiri Popelka (jpope...@redhat.com) wrote: hostname package is now pulled in with net-tools but it should probably be in @Base. Can I (maintainer of hostname) add it to comps or do I need to ping somebody else ? Instead of carrying around a seperate package for one the most trivial programs we have in our distribution I'd just go for using the coreutils hostname implementation. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging dwm
On Thu, 2010-10-14 at 01:48 +0200, Kevin Kofler wrote: Petr Sabata wrote: I've been thinking about packaging dwm [1] since we already ship dmenu and dzen2. I wonder if anybody would be interested in this fine window manager (except for me). I think it's completely unreasonable to package that software, because of this: The problem here: dwm is configured solely in C and has to be recompiled every time a user wants to change their settings (appearance, behavior, shortcuts, etc). In my opinion, we could do it like this: - install a Fedora preconfigured version along with dwm sources - copy its configuration (C header file) to some fixed location for user to customize - provide a script to recompile dwm locally using the local configuration file Such a program is basically not packagable. It can't be packaged in the sense of shipping binaries. But if a wrapper script is provided that automatically recompiles dwm for the individual user whenever necessary, the software could be packaged in the sense that it could be installed and updated with yum and would be functional without user intervention. The latter is my definition of packageable. Compare to the akmods offered by RPM Fusion. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Building mono-2.8 for 64 bit - possible solution to the problem
Hmm. I did a build with: mock -r fedora-rawhide-x86_64 mono-2.8-1.1.fc15.src.rpm on an f13/x86-64 host and it finished without complaint. All the resultant binaries are 64-bit, not 32-bit. So any hacks with -m32 are surely quite wrong. Perhaps something is indeed wonky in koji, or maybe some prerequisite just got broken and fixed since. You should try just resubmitting the package build. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging dwm
Matt McCutchen m...@mattmccutchen.net wrote: It can't be packaged in the sense of shipping binaries. But if a wrapper script is provided that automatically recompiles dwm for the individual user whenever necessary, the software could be packaged in the sense that it could be installed and updated with yum and would be functional without user intervention. The latter is my definition of packageable. Compare to the akmods offered by RPM Fusion. This is something like XMonad. XMonad, the code, is really just a library for writing your own window manager. A default is provided and a tool to manage the building of the actual window manager executable is offered. Whether upstream will accept such a tool is the question. If not, it can probably be maintained in a separate repository (dwm-manager which Requires: dwm-devel, dwm Requires: dwm-manager to get out-of-the-box support). We do something similar for uzbl which is also in a similar boat (though without the compilation step). uzbl - default settings (uzbl-tabbed and uzbl-defaults) uzbl-core- main program uzbl-browser - default tools to get a basic browser (what I use with custom configuration) uzbl-tabbed - tabbed browsing uzbl-defaults- default configuration and scripts (Requires: on tools used go here) Hope this helps. --Ben -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 627192] Padre-0.32 requires newer Thread::Queue
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=627192 --- Comment #2 from Fedora Update System upda...@fedoraproject.org 2010-10-13 02:15:19 EDT --- perl-5.10.0-96.fc12 has been submitted as an update for Fedora 12. https://admin.fedoraproject.org/updates/perl-5.10.0-96.fc12 -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 627192] Padre-0.32 requires newer Thread::Queue
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=627192 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|CLOSED |ASSIGNED Resolution|CURRENTRELEASE | Keywords||Reopened -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
