Re: systemd not in critpath
On Wed, Aug 24, 2011 at 10:13:48PM -0700, Garrett Holmstrom wrote: Neither bodhi nor mash appears to consider systemd to be in the critical path. Why is this? Is that the way we want it to be? We should get that corrected. notting has ben promising to get a script that integrates with mash and pushes the information into pkgdb where bodhi can then pull the information out. Maybe he'll be able to give us an update on that or see if someone else familiar with mash can work on it. -Toshio pgpo5yVO6AH8V.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gimp
Kevin Kofler kevin.kof...@chello.at writes: It's not the Firefox maintainers, it is Mozilla who have decided that release numbers are irrelevant and that the bug fix release for Firefox 5 is Firefox 6. If Firefox were following the update policy, they'd backport the security fixes, not push the new versions. Is that actually possible? I seem to recall that the reason why Firefox can be called Firefox in Fedora, and not, say, Iceweasel or whatever, is that we ship vanilla upstream. PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
NetworkManager, openswan and l2tp
Hello, I need to connect to a site via l2tp/openswan. I can set up openswan and xl2tpd manually and this works fine. However, bringing up the connection is not very comfortable and it would be much nicer to be able to use the networkmanager-openswan plugin. Unfortunately, l2tp and other 'advanced settings' cannot be selected from networkmanager-connection-editor. A quick look at the source code of NetworkManager-openswan-1.7.0 shows that these options are programmed, but seem not to be available in Fedora 15. Will these options eventually be set-able in Fedora? Would converting the glade file in NetworkManager-openswan-1.7.0 to gtkbuilder and a recompile of networkmanager-openswan suffice? Thanks. Best wishes Eberhard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning dnsmasq
On Wed, 24 Aug 2011, Ian Pilcher wrote: On 08/22/2011 06:35 PM, Paul Wouters wrote: If it could also not grab port 0.0.0.0:53 in the future, that would be great. I'd like to work with whichever libvirt developer takes this package on. Are you talking about dnsmasq or the way that libvirt uses dnsmasq? I am talking about livirtd's usage. It's confusing and bad for various reasons, but most importantly: 1) Prevents other DNS resolvers from listening (eg DNSSEC aware ones) 2) service dnsmasq stop fails because it is not started as a regular service When libvirt starts dnsmasq, it tells it to ignore the configuration file and passes all of the parameters on the command line. If you want dnsmasq to not listen on 0.0.0.0:53 when it's started by libvirt, you'll have to take that up with the libvirt developers. Here the issue is: 3) I mostly don't need/want any DNS/DHCP in my bridged setup, but it still configures and starts dnsmasq (at least on F14 using virt-manager) (eg I have a /28 bridges to eth1 with static IPs, I don't want it) The biggest problem for me is wanting to run a DNSSEC aware resolver, and the libvirtd/dnsmasq is preventing me from doing a simple yum install unbound|bind by stealing port 53. Especially on my laptop with libvirtd Again, this is based on f14, not f15/f16. I am not sure how much this has been addressed. But if we want DNSSEC validation on the endnode, at the very least 127.0.0.1:53 needs to be left free. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning dnsmasq
On Thu, 2011-08-25 at 10:24 -0400, Paul Wouters wrote: On Wed, 24 Aug 2011, Ian Pilcher wrote: On 08/22/2011 06:35 PM, Paul Wouters wrote: If it could also not grab port 0.0.0.0:53 in the future, that would be great. I'd like to work with whichever libvirt developer takes this package on. Are you talking about dnsmasq or the way that libvirt uses dnsmasq? I am talking about livirtd's usage. It's confusing and bad for various reasons, but most importantly: 1) Prevents other DNS resolvers from listening (eg DNSSEC aware ones) 2) service dnsmasq stop fails because it is not started as a regular service When libvirt starts dnsmasq, it tells it to ignore the configuration file and passes all of the parameters on the command line. If you want dnsmasq to not listen on 0.0.0.0:53 when it's started by libvirt, you'll have to take that up with the libvirt developers. Here the issue is: 3) I mostly don't need/want any DNS/DHCP in my bridged setup, but it still configures and starts dnsmasq (at least on F14 using virt-manager) (eg I have a /28 bridges to eth1 with static IPs, I don't want it) On a non-bridged setup it listens just on the virbr private interface address so at least in such setups it does not conflict with bind running as a local caching nameserver. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning dnsmasq
2011/8/25 Paul Wouters p...@xelerance.com: Again, this is based on f14, not f15/f16. I am not sure how much this has been addressed. But if we want DNSSEC validation on the endnode, at the very least 127.0.0.1:53 needs to be left free. Are you sure the dnsmasq instance started by libvirt is really grabbing 127.0.0.1:53? In my experiments it did not, and the issue instead was that the other DNS server [1] wanted to grab port 53 on *all* interfaces. - Thomas [1] In my case that was a second instance of dnsmasq, and I had to set --interface=lo and --bind-interfaces. -- Thomas Moschny thomas.mosc...@gmail.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning dnsmasq
On 25/08/11 15:24, Paul Wouters wrote: Here the issue is: 3) I mostly don't need/want any DNS/DHCP in my bridged setup, but it still configures and starts dnsmasq (at least on F14 using virt-manager) (eg I have a /28 bridges to eth1 with static IPs, I don't want it) The biggest problem for me is wanting to run a DNSSEC aware resolver, and the libvirtd/dnsmasq is preventing me from doing a simple yum install unbound|bind by stealing port 53. Especially on my laptop with libvirtd I think you've got something odd going on I'm using a bridged setup with libvirt and although I do have a dnsmasq running it is for the private network defined in libvirt (which I'm not using) and it is only listing on that private network's address. So when I list networks I just have the default one: virsh # net-list Name State Autostart - default active yes and it is defined over a private address range: virsh # net-dumpxml default network namedefault/name uuid6229892b-486a-4c48-961a-20298d585e47/uuid forward mode='nat'/ bridge name='virbr0' stp='on' delay='0' / mac address='52:54:00:37:0B:C2'/ ip address='192.168.122.1' netmask='255.255.255.0' dhcp range start='192.168.122.2' end='192.168.122.254' / /dhcp /ip /network and that is what lsof shows dnsmasq as listening on: dnsmasq 2229 nobody6u IPv4 23692 0t0 TCP 192.168.122.1:domain (LISTEN) Though like I say, I don't actually use that as I have br0 setup as a bridge to my ethernet card and use bridged networking with that instead. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd not in critpath
On Thu, Aug 25, 2011 at 7:32 AM, Toshio Kuratomi a.bad...@gmail.com wrote: On Wed, Aug 24, 2011 at 10:13:48PM -0700, Garrett Holmstrom wrote: Neither bodhi nor mash appears to consider systemd to be in the critical path. Why is this? Is that the way we want it to be? We should get that corrected. notting has ben promising to get a script that integrates with mash and pushes the information into pkgdb where bodhi can then pull the information out. Maybe he'll be able to give us an update on that or see if someone else familiar with mash can work on it. Its not the only one that's missing what should likely be classed as critpath, clutter should likely be added too because gnome-shell's dependency on it. I think the review of the crit path packages should be part of the release process. There's likely things that are no longer crit path and new things that are with each release. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning dnsmasq
On Thu, 25 Aug 2011, Tomas Mraz wrote: 3) I mostly don't need/want any DNS/DHCP in my bridged setup, but it still configures and starts dnsmasq (at least on F14 using virt-manager) (eg I have a /28 bridges to eth1 with static IPs, I don't want it) On a non-bridged setup it listens just on the virbr private interface address so at least in such setups it does not conflict with bind running as a local caching nameserver. Okay, good to know. Though I'd guess most people (esp on laptops) would bridge their VMs to the local ethX/wlanX to provide connectivity. If the NATed setup, those VM's could go out but would not be reachable by a local IP. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning dnsmasq
On Thu, 25 Aug 2011, Thomas Moschny wrote: 2011/8/25 Paul Wouters p...@xelerance.com: Again, this is based on f14, not f15/f16. I am not sure how much this has been addressed. But if we want DNSSEC validation on the endnode, at the very least 127.0.0.1:53 needs to be left free. Are you sure the dnsmasq instance started by libvirt is really grabbing 127.0.0.1:53? In my experiments it did not, and the issue instead was that the other DNS server [1] wanted to grab port 53 on *all* interfaces. - Thomas [1] In my case that was a second instance of dnsmasq, and I had to set --interface=lo and --bind-interfaces. I'll double check with f16 alpha on some iron and if it is still a problem, get back and file a bug to formalise talking about this. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning dnsmasq
On Thu, Aug 25, 2011 at 04:37:26PM +0200, Thomas Moschny wrote: 2011/8/25 Paul Wouters p...@xelerance.com: Again, this is based on f14, not f15/f16. I am not sure how much this has been addressed. But if we want DNSSEC validation on the endnode, at the very least 127.0.0.1:53 needs to be left free. Are you sure the dnsmasq instance started by libvirt is really grabbing 127.0.0.1:53? libvirt's dnsmasq will never be grabbing any 127.0.0.1 address. It is configured to only bind to the IP addresses directly associated with the bridge of the virtual network. # netstat -a -n -p | grep dnsmasq tcp0 0 192.168.123.1:530.0.0.0:* LISTEN 14230/dnsmasq tcp0 0 192.168.124.1:530.0.0.0:* LISTEN 14208/dnsmasq tcp0 0 192.168.122.1:530.0.0.0:* LISTEN 14007/dnsmasq udp0 0 192.168.123.1:530.0.0.0:* 14230/dnsmasq udp0 0 192.168.124.1:530.0.0.0:* 14208/dnsmasq udp0 0 192.168.122.1:530.0.0.0:* 14007/dnsmasq udp0 0 0.0.0.0:67 0.0.0.0:* 14230/dnsmasq udp0 0 0.0.0.0:67 0.0.0.0:* 14208/dnsmasq udp0 0 0.0.0.0:67 0.0.0.0:* 14007/dnsmasq # ip addr | grep 192 inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 inet 192.168.124.1/24 brd 192.168.124.255 scope global virbr2 inet 192.168.123.1/24 brd 192.168.123.255 scope global virbr1 The wildcard bind on the UDP port number 67 there is not a problem because dnsmasq will only reply to requests coming in on the interface that it is configured to use. In my experiments it did not, and the issue instead was that the other DNS server [1] wanted to grab port 53 on *all* interfaces. Yeah, that is the normal problem people see. The default dnsmasq configuration is to bind to all interfaces, which obviously blocks libvirt. other DNS local servers may also exhibit the same problem of binding to all interfaces, and need to be configured to only bind to specific ones. [1] In my case that was a second instance of dnsmasq, and I had to set --interface=lo and --bind-interfaces. For interoperability with libvirt, any dnsmasq instance *must* use the --bind-interfaces argumement, in combination with either '--interface=XXX' or '--listen-address=XX.XX.XX.XX' Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning referencer, file-browser-applet and gnome-scan
Hi all, Please be notified that I intend to orphan the following packages immediately; * referencer * file-browser-applet * gnome-scan Upstream development on both referencer and gnome-scan has stagnated for a while now; also one of the packages referencer requires (libgnomemm) has been dropped recently. Because of the transition to GNOME3, file-browser-applet have become redundant, I am planning to mark it as a dead package. Deji -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning dnsmasq
On Thu, 25 Aug 2011, Daniel P. Berrange wrote: libvirt's dnsmasq will never be grabbing any 127.0.0.1 address. It is In my experiments it did not, and the issue instead was that the other DNS server [1] wanted to grab port 53 on *all* interfaces. Yeah, that is the normal problem people see. The default dnsmasq configuration is to bind to all interfaces, which obviously blocks libvirt. other DNS local servers may also exhibit the same problem of binding to all interfaces, and need to be configured to only bind to specific ones. [1] In my case that was a second instance of dnsmasq, and I had to set --interface=lo and --bind-interfaces. unbound and bind both only grab 127.0.0.1:53 and ::1:53 on their default installs. So it looks like this problem has been solved or went away. Thanks for the answers everyone! Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd not in critpath
On Thu, 2011-08-25 at 15:43 +0100, Peter Robinson wrote: On Thu, Aug 25, 2011 at 7:32 AM, Toshio Kuratomi a.bad...@gmail.com wrote: On Wed, Aug 24, 2011 at 10:13:48PM -0700, Garrett Holmstrom wrote: Neither bodhi nor mash appears to consider systemd to be in the critical path. Why is this? Is that the way we want it to be? We should get that corrected. notting has ben promising to get a script that integrates with mash and pushes the information into pkgdb where bodhi can then pull the information out. Maybe he'll be able to give us an update on that or see if someone else familiar with mash can work on it. Its not the only one that's missing what should likely be classed as critpath, clutter should likely be added too because gnome-shell's dependency on it. I think the review of the crit path packages should be part of the release process. There's likely things that are no longer crit path and new things that are with each release. I'm not sure that's the intent of CRITPATH. I think the original definition was something on the order of packages whose breakage can prevent the system from booting to a command prompt. If gnome-shell is broken, an admin can still get in on a virtual terminal or other window manager. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: perl-Pugs-Compiler-Rule
perl-Pugs-Compiler-Rule has broken dependencies in the F-16 tree: On x86_64: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-NOCpulse-Gritch
perl-NOCpulse-Gritch has broken dependencies in the F-16 tree: On x86_64: perl-NOCpulse-Gritch-1.27.9-1.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-NOCpulse-Gritch-1.27.9-1.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) Please resolve this as soon as possible. -- 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: systemd not in critpath
On Thu, Aug 25, 2011 at 4:36 PM, Stephen Gallagher sgall...@redhat.com wrote: On Thu, 2011-08-25 at 15:43 +0100, Peter Robinson wrote: On Thu, Aug 25, 2011 at 7:32 AM, Toshio Kuratomi a.bad...@gmail.com wrote: On Wed, Aug 24, 2011 at 10:13:48PM -0700, Garrett Holmstrom wrote: Neither bodhi nor mash appears to consider systemd to be in the critical path. Why is this? Is that the way we want it to be? We should get that corrected. notting has ben promising to get a script that integrates with mash and pushes the information into pkgdb where bodhi can then pull the information out. Maybe he'll be able to give us an update on that or see if someone else familiar with mash can work on it. Its not the only one that's missing what should likely be classed as critpath, clutter should likely be added too because gnome-shell's dependency on it. I think the review of the crit path packages should be part of the release process. There's likely things that are no longer crit path and new things that are with each release. I'm not sure that's the intent of CRITPATH. I think the original definition was something on the order of packages whose breakage can prevent the system from booting to a command prompt. If gnome-shell is broken, an admin can still get in on a virtual terminal or other window manager. I believe it was for the primary desktop as well. Otherwise I doubt that things like libimobiledevice would be on that list :) Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd not in critpath
On Thu, Aug 25, 2011 at 09:36, Stephen Gallagher sgall...@redhat.com wrote: On Thu, 2011-08-25 at 15:43 +0100, Peter Robinson wrote: On Thu, Aug 25, 2011 at 7:32 AM, Toshio Kuratomi a.bad...@gmail.com wrote: On Wed, Aug 24, 2011 at 10:13:48PM -0700, Garrett Holmstrom wrote: Neither bodhi nor mash appears to consider systemd to be in the critical path. Why is this? Is that the way we want it to be? We should get that corrected. notting has ben promising to get a script that integrates with mash and pushes the information into pkgdb where bodhi can then pull the information out. Maybe he'll be able to give us an update on that or see if someone else familiar with mash can work on it. Its not the only one that's missing what should likely be classed as critpath, clutter should likely be added too because gnome-shell's dependency on it. I think the review of the crit path packages should be part of the release process. There's likely things that are no longer crit path and new things that are with each release. I'm not sure that's the intent of CRITPATH. I think the original definition was something on the order of packages whose breakage can prevent the system from booting to a command prompt. If gnome-shell is broken, an admin can still get in on a virtual terminal or other window manager. This can be more difficult than you think. 1) There is no other window manager on most systems 2) I have run into multiple GDM issues where it went into respawning mode making going into a virtual terminal hard to impossible as you get switched back to whatever one X is on. Most of those GDM issues were NOT with GDM itself but with the shell chain in some way. 3) GRUB is set to no prompt on many systems meaning choosing runlevel 3 is not easy. I have had to boot my test system several times into rescue mode to manually 'yum update' or fix something because of the above. If we can define outside of Critical Path as being can be fixed by booting into rescue mode. I think a critical path could become a lot lot smaller :). -- Stephen J Smoogen. The core skill of innovators is error recovery, not failure avoidance. Randy Nelson, President of Pixar University. Let us be kind, one to another, for most of us are fighting a hard battle. -- Ian MacLaren -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
Am 24.08.2011 20:40, schrieb Adam Williamson: On Wed, 2011-08-24 at 19:59 +0200, Lennart Poettering wrote: On Wed, 24.08.11 10:05, Adam Williamson (awill...@redhat.com) wrote: FWIW, I do think that there may be use-cases for socket activation of a database. I'd like to support the option ... the problem is to do so without breaking existing, expected behaviors. It was noted up-thread that systemd can tell you whether the underlying daemon is running or not, though I guess that doesn't tell you whether it's entirely in a functional state. You could do a two-stage thing: check with systemd whether the daemon is running, and ping it if so? systemd will put services only in running state if they are fully up and told systemd so. They'll be in starting until that time. All we need for this is that services either use Type=forking and double fork+exit in parent, or use Type=notify and sd_notify(READY=1) as soon as they are fully up. Sure, but it would be possibly for mysql to be 'fully up' under systemd's definition (i.e. the mysqld process has successfully executed and is running happily) while not actually being properly configured to serve external requests, right? Bad mysql config, firewall in the way, whatever...point is that systemd can't really know for sure that the underlying process is 100% working, only that it's _running_ and that is why you need only socket-activation for the unix-socket to provide relieable system-boot with activation and you nagios will check over TCP and so has NOTHING really NOTHING to do with systemd signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gimp
On 08/25/2011 10:28 AM, Nils Philippsen wrote: As well, installing both stable versions side-by-side isn't an option as you can't install them into the same prefix: the libraries have the same SONAME, the new ones are expected to be ABI compatible. Therefore I don't see a real alternative to rebasing to 2.8 in stable Fedora releases when it finally is available, after thoroughly testing it of course I really wish developers would not do that - every app should be installable in path/app-name-version - and then we use something like the alternates system (soft links) to get the version we want to run ... we should require this of every app in my view ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gimp
On Thu, Aug 25, 2011 at 5:58 PM, Genes MailLists li...@sapience.com wrote: On 08/25/2011 10:28 AM, Nils Philippsen wrote: As well, installing both stable versions side-by-side isn't an option as you can't install them into the same prefix: the libraries have the same SONAME, the new ones are expected to be ABI compatible. Therefore I don't see a real alternative to rebasing to 2.8 in stable Fedora releases when it finally is available, after thoroughly testing it of course I really wish developers would not do that - every app should be installable in path/app-name-version - and then we use something like the alternates system (soft links) to get the version we want to run ... we should require this of every app in my view ... That only helps if you are the system administrator of the system and if you know about alternatives. Ordinary users are at mercy of either their system administrator, or the distribution author. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-16 Branched report: 20110825 changes
Compose started at Thu Aug 25 13:15:36 UTC 2011 Broken deps for x86_64 -- 389-ds-base-1.2.9.0-1.fc16.2.x86_64 requires libnetsnmpagent.so.25()(64bit) 389-ds-base-1.2.9.0-1.fc16.2.x86_64 requires libnetsnmpmibs.so.25()(64bit) 389-ds-base-1.2.9.0-1.fc16.2.x86_64 requires libnetsnmp.so.25()(64bit) OpenImageIO-0.10.1-2.fc15.i686 requires libboost_program_options-mt.so.1.46.0 OpenImageIO-0.10.1-2.fc15.i686 requires libboost_thread-mt.so.1.46.0 OpenImageIO-0.10.1-2.fc15.i686 requires libboost_python-mt.so.1.46.0 OpenImageIO-0.10.1-2.fc15.i686 requires libboost_system-mt.so.1.46.0 OpenImageIO-0.10.1-2.fc15.i686 requires libGLEW.so.1.5 OpenImageIO-0.10.1-2.fc15.i686 requires libboost_regex-mt.so.1.46.0 OpenImageIO-0.10.1-2.fc15.i686 requires libboost_filesystem-mt.so.1.46.0 OpenImageIO-0.10.1-2.fc15.x86_64 requires libboost_regex-mt.so.1.46.0()(64bit) OpenImageIO-0.10.1-2.fc15.x86_64 requires libboost_filesystem-mt.so.1.46.0()(64bit) OpenImageIO-0.10.1-2.fc15.x86_64 requires libboost_program_options-mt.so.1.46.0()(64bit) OpenImageIO-0.10.1-2.fc15.x86_64 requires libboost_system-mt.so.1.46.0()(64bit) OpenImageIO-0.10.1-2.fc15.x86_64 requires libGLEW.so.1.5()(64bit) OpenImageIO-0.10.1-2.fc15.x86_64 requires libboost_python-mt.so.1.46.0()(64bit) OpenImageIO-0.10.1-2.fc15.x86_64 requires libboost_thread-mt.so.1.46.0()(64bit) acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell) almanah-0.7.3-12.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libedataserverui-3.0.so.0()(64bit) assogiate-0.2.1-5.fc15.x86_64 requires libgnomevfsmm-2.6.so.1()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit) cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires rvm-tools coda-server-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) comoonics-cdsl-py-0.2-18.noarch requires comoonics-base-py comoonics-cluster-py-0.1-24.noarch requires comoonics-base-py contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1 contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libebook-1.2.so.10()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires gnome-python2-applet deskbar-applet-2.32.0-4.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) dh-make-0.55-3.fc15.noarch requires debhelper emacs-spice-mode-1.2.25-5.fc15.noarch requires gwave emerillon-0.1.2-17.fc16.x86_64 requires libethos-ui-1.0.so.0()(64bit) emerillon-0.1.2-17.fc16.x86_64 requires libethos-1.0.so.0()(64bit) evolution-mapi-3.1.3-1.fc16.i686 requires libcamel-1.2.so.27 evolution-mapi-3.1.3-1.fc16.i686 requires libcamel-provider-1.2.so.27 evolution-mapi-3.1.3-1.fc16.x86_64 requires libcamel-provider-1.2.so.27()(64bit) evolution-mapi-3.1.3-1.fc16.x86_64 requires libcamel-1.2.so.27()(64bit) exaile-0.3.2.1-1.fc16.noarch requires hal fawkes-guis-0.4.2-4.fc16.i686 requires libgvc.so.5 fawkes-guis-0.4.2-4.fc16.i686 requires libcdt.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libgraph.so.4 fawkes-guis-0.4.2-4.fc16.x86_64 requires libgvc.so.5()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libcdt.so.4()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libgraph.so.4()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libboost_signals-mt.so.1.46.1()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libboost_thread-mt.so.1.46.1()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libgeos-3.2.1.so()(64bit) file-browser-applet-0.6.6-1.fc15.x86_64 requires
Re: gimp
On 08/25/2011 12:00 PM, Miloslav Trmač wrote: On Thu, Aug 25, 2011 at 5:58 PM, Genes MailLists li...@sapience.com wrote: On 08/25/2011 10:28 AM, Nils Philippsen wrote: As well, installing both stable versions side-by-side isn't an option as you can't install them into the same prefix: the libraries have the same SONAME, the new ones are expected to be ABI compatible. Therefore I don't see a real alternative to rebasing to 2.8 in stable Fedora releases when it finally is available, after thoroughly testing it of course I really wish developers would not do that - every app should be installable in path/app-name-version - and then we use something like the alternates system (soft links) to get the version we want to run ... we should require this of every app in my view ... That only helps if you are the system administrator of the system and if you know about alternatives. Ordinary users are at mercy of either their system administrator, or the distribution author. Mirek If an app is installable in its own area - it can just as well be /home/foo/ ... just put link (or script or whatever is needed) to have the app know where its base is). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
Actually there is another reason for socket activation to use AF_INET as well as AF_UNIX: doing so prevents e.g. rpc.statd from port-squatting. In fact, this is why CUPS no longer ships to ship a portreserve file. Tim. */ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gimp
On Thu, Aug 25, 2011 at 11:58:29AM -0400, Genes MailLists wrote: On 08/25/2011 10:28 AM, Nils Philippsen wrote: As well, installing both stable versions side-by-side isn't an option as you can't install them into the same prefix: the libraries have the same SONAME, the new ones are expected to be ABI compatible. Therefore I don't see a real alternative to rebasing to 2.8 in stable Fedora releases when it finally is available, after thoroughly testing it of course I really wish developers would not do that - every app should be installable in path/app-name-version - and then we use something like the alternates system (soft links) to get the version we want to run ... we should require this of every app in my view ... The GIMP developers do not prevent that. You can easily install multiple versions of GIMP in their own path/$appname-$version. GIMP is acutally better than most, because it also uses a versioned directory in $HOME/.gimp-X.Y for preferences, so a new install does not fubar the preferences of an old install vica-verca. It is simply that the Fedora policy is to always install apps into a fixed /usr location, and not /opt/$appname-$version or anything like that. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd not in critpath
Toshio Kuratomi (a.bad...@gmail.com) said: On Wed, Aug 24, 2011 at 10:13:48PM -0700, Garrett Holmstrom wrote: Neither bodhi nor mash appears to consider systemd to be in the critical path. Why is this? Is that the way we want it to be? We should get that corrected. notting has ben promising to get a script that integrates with mash and pushes the information into pkgdb where bodhi can then pull the information out. Maybe he'll be able to give us an update on that or see if someone else familiar with mash can work on it. Honestly, it was low enough on the todo list that I completely forgot about it. If someone wants to grab the idea and run with it, that's fine with me. Note that critpath list generation is currently broken as well. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 728667] Please build for EPEL-6
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=728667 --- Comment #2 from Remi Collet fed...@famillecollet.com 2011-08-25 13:27:36 EDT --- Package Change Request == Package Name: perl-POE-Component-Client-DNS New Branches: el6 Owners: remi -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 728667] Please build for EPEL-6
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=728667 Remi Collet fed...@famillecollet.com changed: What|Removed |Added Flag||fedora-cvs? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 728668] Please build for EPEL-6
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=728668 Remi Collet fed...@famillecollet.com changed: What|Removed |Added Flag||fedora-cvs? --- Comment #2 from Remi Collet fed...@famillecollet.com 2011-08-25 13:28:15 EDT --- Package Change Request == Package Name: perl-POE-Component-Client-HTTP New Branches: el6 Owners: remi -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 728669] Please build for EPEL-6
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=728669 Remi Collet fed...@famillecollet.com changed: What|Removed |Added Flag||fedora-cvs? --- Comment #2 from Remi Collet fed...@famillecollet.com 2011-08-25 13:28:48 EDT --- Package Change Request == Package Name: perl-POE-Component-Client-Keepalive New Branches: el6 Owners: remi -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 728667] Please build for EPEL-6
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=728667 --- Comment #3 from Jon Ciesla l...@jcomserv.net 2011-08-25 13:34:47 EDT --- Git done (by process-git-requests). -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 728668] Please build for EPEL-6
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=728668 --- Comment #3 from Jon Ciesla l...@jcomserv.net 2011-08-25 13:39:09 EDT --- Git done (by process-git-requests). -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 728669] Please build for EPEL-6
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=728669 --- Comment #3 from Jon Ciesla l...@jcomserv.net 2011-08-25 13:39:44 EDT --- Git done (by process-git-requests). -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: NetworkManager, openswan and l2tp
On Thu, 2011-08-25 at 11:00 +0200, Eberhard Schruefer wrote: Hello, I need to connect to a site via l2tp/openswan. I can set up openswan and xl2tpd manually and this works fine. However, bringing up the connection is not very comfortable and it would be much nicer to be able to use the networkmanager-openswan plugin. Unfortunately, l2tp and other 'advanced settings' cannot be selected from networkmanager-connection-editor. A quick look at the source code of NetworkManager-openswan-1.7.0 shows that these options are programmed, but seem not to be available in Fedora 15. Which openswan sources are you looking at? Will these options eventually be set-able in Fedora? It's probable they will be but it might take some work. AFAIK there isn't yet an L2TP VPN plugin for NM though I've heard of people working on one. Would converting the glade file in NetworkManager-openswan-1.7.0 to gtkbuilder and a recompile of networkmanager-openswan suffice? As part of the NM 0.9 push we moved the existing NM-openvpn plugin to git.gnome.org and cleaned it up, including converting to GtkBuilder. But that alone wouldn't magically make L2TP work unless the right options were added to the UI. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: NetworkManager, openswan and l2tp
2011/8/25 Dan Williams d...@redhat.com: On Thu, 2011-08-25 at 11:00 +0200, Eberhard Schruefer wrote: Hello, It's probable they will be but it might take some work. AFAIK there isn't yet an L2TP VPN plugin for NM though I've heard of people working on one. https://github.com/atorkhov/NetworkManager-l2tp I've even heard some positive feedback. -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gimp
On Wed, Aug 24, 2011 at 1:17 PM, Richard Shaw hobbes1...@gmail.com wrote: On Wed, Aug 24, 2011 at 11:48 AM, Jeffrey Ollie j...@ocjtech.us wrote: On Wed, Aug 24, 2011 at 9:36 AM, Richard Shaw hobbes1...@gmail.com wrote: The other option is for someone to build packages and host them on fedorapeople.org as a personal repository. I certainly wouldn't mind trying 2.7+ but I would like the ability to easily revert if I run into problems. You mean something like this? http://repos.fedorapeople.org/repos/luya/gimp/ Yup! It's at 2.7.2, but I'm downloading the SRPM to updated it to 2.7.3... I've got builds of 2.7.3 based on the SRPM from the above link. http://hobbes1069.fedorapeople.org/gimp/ Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning techtalk-pse
On Wed, Aug 24, 2011 at 10:29:54AM -0500, Ian Weller wrote: I am orphaning the techtalk-pse package because the Gtk2::MozEmbed perl module will no longer be maintained in Fedora because gtkmozembed support has been removed from xulrunner. If upstream (or anybody) has the time to work on techtalk-pse and get it working with something like Gtk2::WebKit, I'm glad to pick up package maintenance again. (I would, but my perl skills go as far as running programs.) I agreed with Ian that this is the right thing to do at this time. Until I get time to rewrite it to use webkit ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gimp
On 08/25/2011 01:18 PM, Nils Philippsen wrote: Side-by-side means into the same prefix. You can only have one gimp version installed into the /usr prefix, you're free to install a different one into /opt/gimp-x.y or somewhere into your home if you're an ordinary user. Nils Ah thats better .. thanks :-) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
GPT in Fedora 16
While installing Fedora 16 Alpha, I ran into some problems that turned out to be caused by the installer formatting with a GPT rather than an MBR partition table. I would like to understand the change and its implications, and I have unsuccessfully tried to track down more information. I haven't been able to find anything in the Fedora 16 Alpha Release Notes or the Grub2 feature page. The only definitive reference I've been able to find is the comment x86 uses GPT disklabels by default on all machines, even non-EFI on the Anaconda/Changes wiki page. There seem to be some complications associated with the change. For example, Windows can only support GPT on UEFI machines, so dual-booting appears to be unsupported (I could not find an option for MBR partition tables in the installer). Where should I look for more information? Thanks. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
License
I am looking at http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#License_Text . It sounds to me that upstream must provide the COPYING file. I am reviewing pipebench at https://bugzilla.redhat.com/show_bug.cgi?id=731219 The issue with the one the upstream author provided contained some problems in it according to rpmlint. The fix I read about the error was to replace it with one from GNU's site. I currently told the submitter to include it from GNU's site and also notified upstream of the problem with the COPYING file. Should we wait for the upstream to provide the COPYING file or have this as a temporary fix? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: License
On 08/26/2011 12:17 AM, Nathan O. wrote: I am looking at http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#License_Text . It sounds to me that upstream must provide the COPYING file. No, this is a misinterpretation and overinterpretation Upstreams need to license their works properly. How to do this is largely up to their discretion. Nothing obliges the to ship a COPYING file. I am reviewing pipebench at https://bugzilla.redhat.com/show_bug.cgi?id=731219 The issue with the one the upstream author provided contained some problems in it according to rpmlint. Well, don't take rpmlint's output too seriously. Read it's output as hints but not as mandatory. The fact rpmlint treats packages using an older FSF's address as error, to me is nothing but one of the many defects rpmlint suffers from. The fix I read about the error was to replace it with one from GNU's site. I currently told the submitter to include it from GNU's site and also notified upstream of the problem with the COPYING file. Should we wait for the upstream to provide the COPYING file or have this as a temporary fix? As long as upstreams express their licensing clearly, you shouldn't do anything nor try to force anybody to do anything. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: License
On 08/26/2011 03:47 AM, Nathan O. wrote: I am looking at http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#License_Text . It sounds to me that upstream must provide the COPYING file. I am reviewing pipebench at https://bugzilla.redhat.com/show_bug.cgi?id=731219 The issue with the one the upstream author provided contained some problems in it according to rpmlint. The fix I read about the error was to replace it with one from GNU's site. I currently told the submitter to include it from GNU's site and also notified upstream of the problem with the COPYING file. Should we wait for the upstream to provide the COPYING file or have this as a temporary fix? Ask the submitter to notify upstream. Patching COPYING file is upto to discretion of the submitter and shouldn't be a blocker. Spot answered a similar question https://lists.fedoraproject.org/pipermail/legal/2011-August/001701.html Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd not in critpath
On Thu, 2011-08-25 at 15:43 +0100, Peter Robinson wrote: On Thu, Aug 25, 2011 at 7:32 AM, Toshio Kuratomi a.bad...@gmail.com wrote: On Wed, Aug 24, 2011 at 10:13:48PM -0700, Garrett Holmstrom wrote: Neither bodhi nor mash appears to consider systemd to be in the critical path. Why is this? Is that the way we want it to be? We should get that corrected. notting has ben promising to get a script that integrates with mash and pushes the information into pkgdb where bodhi can then pull the information out. Maybe he'll be able to give us an update on that or see if someone else familiar with mash can work on it. Its not the only one that's missing what should likely be classed as critpath, clutter should likely be added too because gnome-shell's dependency on it. I think the review of the crit path packages should be part of the release process. There's likely things that are no longer crit path and new things that are with each release. If it isn't, there's a bug somewhere, as critpath generation should take dependencies into account - if gnome-shell actually depends on clutter, then clutter should be pulled into critpath automatically. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd not in critpath
On Thu, 2011-08-25 at 16:42 +0100, Peter Robinson wrote: On Thu, Aug 25, 2011 at 4:36 PM, Stephen Gallagher sgall...@redhat.com wrote: On Thu, 2011-08-25 at 15:43 +0100, Peter Robinson wrote: On Thu, Aug 25, 2011 at 7:32 AM, Toshio Kuratomi a.bad...@gmail.com wrote: On Wed, Aug 24, 2011 at 10:13:48PM -0700, Garrett Holmstrom wrote: Neither bodhi nor mash appears to consider systemd to be in the critical path. Why is this? Is that the way we want it to be? We should get that corrected. notting has ben promising to get a script that integrates with mash and pushes the information into pkgdb where bodhi can then pull the information out. Maybe he'll be able to give us an update on that or see if someone else familiar with mash can work on it. Its not the only one that's missing what should likely be classed as critpath, clutter should likely be added too because gnome-shell's dependency on it. I think the review of the crit path packages should be part of the release process. There's likely things that are no longer crit path and new things that are with each release. I'm not sure that's the intent of CRITPATH. I think the original definition was something on the order of packages whose breakage can prevent the system from booting to a command prompt. If gnome-shell is broken, an admin can still get in on a virtual terminal or other window manager. I believe it was for the primary desktop as well. Otherwise I doubt that things like libimobiledevice would be on that list :) Yes, critpath includes default desktop. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT in Fedora 16
On Thu, 2011-08-25 at 16:17 -0600, Andrew McNabb wrote: While installing Fedora 16 Alpha, I ran into some problems that turned out to be caused by the installer formatting with a GPT rather than an MBR partition table. I would like to understand the change and its implications, and I have unsuccessfully tried to track down more information. I haven't been able to find anything in the Fedora 16 Alpha Release Notes or the Grub2 feature page. The only definitive reference I've been able to find is the comment x86 uses GPT disklabels by default on all machines, even non-EFI on the Anaconda/Changes wiki page. There seem to be some complications associated with the change. For example, Windows can only support GPT on UEFI machines, so dual-booting appears to be unsupported (I could not find an option for MBR partition tables in the installer). Where should I look for more information? Thanks. To boot to a GPT disk from BIOS (rather than EFI) you need a BIOS boot partition. If you use one of the automatic partitioning methods, rather than manual partitioning, F16's installer will create one for you. If you choose manual partitioning on a BIOS system and don't create a BIOS boot partition, anaconda will pop up a (somewhat cryptic) warning. If you're installing alongside an existing copy of Windows I believe anaconda ought to leave the disk label alone (MSDOS) anyway, though I'm not sure we've tested that. It should only write a new one if you're blowing away any existing partitions on the disk, I think. (IMBW on this one). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT in Fedora 16
On Thu, 2011-08-25 at 17:11 -0700, Adam Williamson wrote: On Thu, 2011-08-25 at 16:17 -0600, Andrew McNabb wrote: While installing Fedora 16 Alpha, I ran into some problems that turned out to be caused by the installer formatting with a GPT rather than an MBR partition table. I would like to understand the change and its implications, and I have unsuccessfully tried to track down more information. I haven't been able to find anything in the Fedora 16 Alpha Release Notes or the Grub2 feature page. The only definitive reference I've been able to find is the comment x86 uses GPT disklabels by default on all machines, even non-EFI on the Anaconda/Changes wiki page. There seem to be some complications associated with the change. For example, Windows can only support GPT on UEFI machines, so dual-booting appears to be unsupported (I could not find an option for MBR partition tables in the installer). Where should I look for more information? Thanks. To boot to a GPT disk from BIOS (rather than EFI) you need a BIOS boot partition. If you use one of the automatic partitioning methods, rather than manual partitioning, F16's installer will create one for you. If you choose manual partitioning on a BIOS system and don't create a BIOS boot partition, anaconda will pop up a (somewhat cryptic) warning. This is changing from a suggestion to a requirement, based on the fact that grub2 will not even try to install itself without the bios boot partition. If you're installing alongside an existing copy of Windows I believe anaconda ought to leave the disk label alone (MSDOS) anyway, though I'm not sure we've tested that. It should only write a new one if you're blowing away any existing partitions on the disk, I think. (IMBW on this one). This is correct. It's also true that if you create an msdos/mbr partition table on your disk prior to installation and then choose any option except for Use All Space (or clearpart --all in kickstart) anaconda will not destroy your existing partition table. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gimp
Petr Machata wrote: Is that actually possible? I seem to recall that the reason why Firefox can be called Firefox in Fedora, and not, say, Iceweasel or whatever, is that we ship vanilla upstream. I have always said that if we can't ship Firefox with that name while following the Fedora policies, the right thing to do is to just rename it, not give it exceptions to our policies. In particular, I find it unacceptable that the packages in the Mozilla stack are the ONLY packages to which provenpackagers can't commit. And that Firefox repeatedly gets permission to bundle some libraries only because upstream refuses to support using the system version, even though it would work just fine. And so on… Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT in Fedora 16
On Thu, Aug 25, 2011 at 07:17:58PM -0500, David Lehman wrote: It's also true that if you create an msdos/mbr partition table on your disk prior to installation and then choose any option except for Use All Space (or clearpart --all in kickstart) anaconda will not destroy your existing partition table. But if you first install Fedora to a clean disk, then it will never be possible to later install Windows, right? -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review swap: GNOME Schedule
Hi Graphical interface to crontab and at https://bugzilla.redhat.com/show_bug.cgi?id=733572 Was retired in Fedora earlier due to dependency on applet. Latest upstream disables applet by default. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: perl-NOCpulse-Gritch
perl-NOCpulse-Gritch has broken dependencies in the rawhide tree: On x86_64: perl-NOCpulse-Gritch-1.27.9-1.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-NOCpulse-Gritch-1.27.9-1.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Pugs-Compiler-Rule
perl-Pugs-Compiler-Rule has broken dependencies in the rawhide tree: On x86_64: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Mojolicious-1.92.tar.gz uploaded to lookaside cache by cheeselee
A file has been added to the lookaside cache for perl-Mojolicious: da0907ceec551506cf206b358f13bd14 Mojolicious-1.92.tar.gz -- 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
[perl-Mojolicious] Upstream update 1.92
commit d047ed80aa45c5c7561b41a54249f4422b5a3c70
Author: Robin Lee cheese...@fedoraproject.org
Date: Fri Aug 26 10:25:02 2011 +0800
Upstream update 1.92
.gitignore|1 +
perl-Mojolicious.spec |7 ---
sources |2 +-
3 files changed, 6 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 91e2a39..2795557 100644
--- a/.gitignore
+++ b/.gitignore
@@ -24,3 +24,4 @@ Mojolicious-0.26.tar.gz
/Mojolicious-1.43.tar.gz
/Mojolicious-1.46.tar.gz
/Mojolicious-1.65.tar.gz
+/Mojolicious-1.92.tar.gz
diff --git a/perl-Mojolicious.spec b/perl-Mojolicious.spec
index 224ec10..07ae2f4 100644
--- a/perl-Mojolicious.spec
+++ b/perl-Mojolicious.spec
@@ -1,5 +1,5 @@
Name: perl-Mojolicious
-Version:1.65
+Version:1.92
Release:1%{?dist}
Summary:A next generation web framework for Perl
License:Artistic 2.0
@@ -25,7 +25,6 @@ a new attempt at implementing this idea using state of the
art technology.
%prep
%setup -q -n Mojolicious-%{version}
mv README.pod lib/Mojolicious/
-chmod -x lib/Mojo/Exception.pm
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
@@ -43,7 +42,6 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
make test
%files
-%defattr(-,root,root,-)
%doc Changes LICENSE examples
%{_bindir}/mojo
%{_bindir}/hypnotoad
@@ -53,6 +51,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Fri Aug 26 2011 Robin Lee cheese...@fedoraproject.org - 1.92-1
+- Upstream update 1.92
+
* Tue Jul 26 2011 Yanko Kaneti yan...@declera.com - 1.65-1
- Upstream update 1.65
diff --git a/sources b/sources
index 4e05b17..d00d415 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-b9cff0ff045d1ca5cb55d41ce90c1f5b Mojolicious-1.65.tar.gz
+da0907ceec551506cf206b358f13bd14 Mojolicious-1.92.tar.gz
--
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
[perl-POE-Component-Client-DNS/el6] import into EPEL-6 from rawhide
commit 8e765acca6eaf7759ea073bc275ff7009428001c
Author: remi fed...@famillecollet.com
Date: Fri Aug 26 07:58:04 2011 +0200
import into EPEL-6 from rawhide
perl-POE-Component-Client-DNS.spec | 12 +++-
1 files changed, 3 insertions(+), 9 deletions(-)
---
diff --git a/perl-POE-Component-Client-DNS.spec
b/perl-POE-Component-Client-DNS.spec
index a65d39f..bef7445 100644
--- a/perl-POE-Component-Client-DNS.spec
+++ b/perl-POE-Component-Client-DNS.spec
@@ -1,6 +1,6 @@
Name: perl-POE-Component-Client-DNS
Version:1.051
-Release:4%{?dist}
+Release:1%{?dist}
Summary:Non-blocking/concurrent DNS queries using Net::DNS and POE
Group: Development/Libraries
@@ -70,14 +70,8 @@ rm -rf %{buildroot}
%changelog
-* Tue Jul 19 2011 Petr Sabata con...@redhat.com - 1.051-4
-- Perl mass rebuild
-
-* Tue Feb 08 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.051-3
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
-
-* Tue Dec 21 2010 Marcela Maslanova mmasl...@redhat.com - 1.051-2
-- 661697 rebuild for fixing problems with vendorach/lib
+* Fri Aug 26 2011 Remi Collet r...@fedoraproject.org - 1.051-1
+- first EPEL-6 build
* Tue Jun 8 2010 Petr Pisar ppi...@redhat.com - 1.051-1
- 1.051 bump
--
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
