Seeking for package review - Berusky 2 game
Hi, Berusky2 is a 3D sequel of Berusky and former commercial project: https://bugzilla.redhat.com/show_bug.cgi?id=732200 project homepage: http://anakreon.cz/en/Berusky2.htm I promise the spec file is tinny and reviewer friendly :) Thnaks, ma. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
2011-08-26 @ 17:00 UTC - F16 Beta Blocker Bug Review #1
# F16 Beta Blocker Review meeting #1 # Date: 2011-08-26 # Time: 17:00 UTC [1] (13:00 EDT, 10:00 PDT, 10:00 MST) # Location: #fedora-bugzappers on irc.freenode.net The first Beta blocker review meeting starts at 17:00 UTC in #fedora-bugzappers. We'll do a first run through the proposed Beta blockers and nice-to-haves. An updated list of blocker bugs is available at https://fedoraproject.org/wiki/Current_Release_Blockers. We'll be reviewing the bugs to determine ... 1. Whether they meet the Beta release criteria [2] and should stay on the list 2. Whether they are getting the attention they need For guidance on Blocker and Nice-to-have (NTH) bugs, refer to https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process and https://fedoraproject.org/wiki/QA:SOP_nth_bug_process . For the blocker review meeting protocol, see https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting . Thanks, Adam [1] https://fedoraproject.org/wiki/Infrastructure/UTCHowto [2] https://fedoraproject.org/wiki/Fedora_16_Beta_Release_Criteria -- 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
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
Re: GPT in Fedora 16
On Thu, 2011-08-25 at 21:13 -0500, Andrew McNabb wrote: > 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? One thing I didn't answer - intentionally, as I don't know the answer - is whether Windows will boot if you have a BIOS boot partition on a GPT-labelled drive. It may do. -- 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, 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
Re: gimp
On Tue, Aug 23, 2011 at 05:34:00PM -0300, Itamar Reis Peixoto wrote: > is this a good reason ? > http://tech.slashdot.org/story/11/08/23/1355225/The-GIMP-Now-Has-a-Working-Single-Window-Mode That's a great example of what shouldn't happen _inside_ a release. New releases come out twice a year -- we shouldn't release updates with huge UI changes to the already-out versions. It might be time to start working on getting the update into rawhide, targetted for F16 or F17. -- Matthew Miller 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: 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, 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: 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: 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 > wrote: > > On Thu, 2011-08-25 at 15:43 +0100, Peter Robinson wrote: > >> On Thu, Aug 25, 2011 at 7:32 AM, Toshio Kuratomi > >> 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: 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 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: 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: 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
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
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
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
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 Wed, Aug 24, 2011 at 1:17 PM, Richard Shaw wrote: > On Wed, Aug 24, 2011 at 11:48 AM, Jeffrey Ollie wrote: >> On Wed, Aug 24, 2011 at 9:36 AM, Richard Shaw 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: NetworkManager, openswan and l2tp
2011/8/25 Dan Williams : > 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: 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
[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 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
[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 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 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 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 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 changed: What|Removed |Added Flag||fedora-cvs? --- Comment #2 from Remi Collet 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 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 changed: What|Removed |Added Flag||fedora-cvs? --- Comment #2 from Remi Collet 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 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 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 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 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
Re: gimp
On Thu, 2011-08-25 at 11:58 -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 /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 ... 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 -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- 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
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 /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 /$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: 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 08/25/2011 12:00 PM, Miloslav Trmač wrote: > On Thu, Aug 25, 2011 at 5:58 PM, 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 /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
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 libpanel-applet-2.so.0(
Re: gimp
On Thu, Aug 25, 2011 at 5:58 PM, 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 /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
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 /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: 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: Default services enabled -> there is no problem with mysqld
Am 24.08.2011 19:36, schrieb Lennart Poettering: > On Wed, 24.08.11 10:45, Tom Lane (t...@redhat.com) wrote: > >> >> Reindl Harald writes: >>> Am 23.08.2011 23:28, schrieb Tom Lane: there's no other way for "mysqladmin ping" to work, for example >> >>> and where is the problem? >> >> I'm not planning on repeating myself either, but: a database >> *monitoring* tool, as opposed to a vanilla client, needs to know whether >> the database is in fact up. Autostarting the DB in response to a >> monitoring probe is the wrong behavior for that. > > Are you sure it is? The thing is that when using socket activation it is > merely an implementation detail when a service is actually really > started. If you get a response you get a response and that's what you > probably want to monitor. and what he does not understand is that the socket is only needed LOCAL nagios as brought example normally runs on a monitoring host and checks the TCP port, sad enough that we have to explain this the mysql-maintainer where will a monitoring over the network trigger the socket below? TCP port is directly mysqld in this case [root@srv-rhsoft:~]$ cat /lib/systemd/system/mysqld.socket [Unit] Description=MySQL Database activation socket [Socket] ListenStream=/var/lib/mysql/mysql.sock [Install] WantedBy=sockets.target signature.asc Description: OpenPGP digital signature -- 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 wrote: > On Thu, 2011-08-25 at 15:43 +0100, Peter Robinson wrote: >> On Thu, Aug 25, 2011 at 7:32 AM, Toshio Kuratomi 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: systemd not in critpath
On Thu, Aug 25, 2011 at 4:36 PM, Stephen Gallagher wrote: > On Thu, 2011-08-25 at 15:43 +0100, Peter Robinson wrote: >> On Thu, Aug 25, 2011 at 7:32 AM, Toshio Kuratomi 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
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
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
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 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
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
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, Aug 25, 2011 at 04:37:26PM +0200, Thomas Moschny wrote: > 2011/8/25 Paul Wouters : > > 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
Re: Orphaning dnsmasq
On Thu, 25 Aug 2011, Thomas Moschny wrote: > 2011/8/25 Paul Wouters : >> 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, 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: systemd not in critpath
On Thu, Aug 25, 2011 at 7:32 AM, Toshio Kuratomi 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 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 default 6229892b-486a-4c48-961a-20298d585e47 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: Orphaning dnsmasq
2011/8/25 Paul Wouters : > 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 -- 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: gimp
On Wed, 2011-08-24 at 10:15 +0300, Nicu Buculei wrote: > On 08/23/2011 11:34 PM, Itamar Reis Peixoto wrote: > > On Tue, Aug 23, 2011 at 5:24 PM, Richard Shaw wrote: > >> On Tue, Aug 23, 2011 at 11:50 AM, Genes MailLists wrote: > >>> > >>> Are there any plans to bring gimp 2.7.x -> 2.8 into F16 ? > >> > >> Is there a specific reason to? The home page states that the whole > >> 2.7.x series should be considered unstable. > > > > is this a good reason ? > > > > http://tech.slashdot.org/story/11/08/23/1355225/The-GIMP-Now-Has-a-Working-Single-Window-Mode > > No, that single window mode is not such a good reason, the feature is... > cute but not excessively useful, the real reason is the 2.8 release is > long overdue (expected since last December) and quite a few features > were added: more gegl integration, better usability, linked layers etc. > And we the people using it for real work still remember the times when > Fedora used to be a bleeding edge distro and had such GIMP updated... > happy old times... You're probably referring to the updates 2.2->2.4 in '07 and 2.4->2.6 in '08 but please keep in mind that we're stuck with 2.6.x as the stable branch since then, so there's no reason to be gloomy about the Fedora side just yet. While we mightn't have had an explicit update policy for Fedora in the time, these packages only went in after thorough testing on top of that upstream managed to keep things as backwards-compatible as could be expected -- the built-in scheme interpreter became a bit more strict in 2.6, which was a documented break with 2.4 which could easily be fixed by fixing affected 3rd party scripts. Considering that upstream to a large part isn't interested in working on 2.6 anymore -- the last commit by a core developer to this branch was in February this year -- I don't expect to see another 2.6 bugfix release. 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 (which I already do to a certain extent, I can e.g. confirm that the ufraw gimp plugin built with 2.6 works with a private installation of current git master). Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- 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
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: gimp
Petr Machata writes: > Kevin Kofler 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. (Not that this would be sufficient grounds for breaking the policy, of course.) PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gimp
Kevin Kofler 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
