Re: Orphaning buoh, libsoup22
On Fri, 2012-03-02 at 14:43 +0100, Nicola Soranzo wrote: > Il giorno ven, 02/03/2012 alle 14.41 +0200, Jonathan Dieter ha scritto: > > I've orphaned buoh and libsoup22 in all active branches of Fedora. Buoh > > is a GTK online comics reader that I haven't used in forever and > > libsoup22 is a compat version of libsoup required for buoh. I don't > > think any packages other than buoh require libsoup22, but I could be > > wrong. > > libsoup22 is also required by libsyncml . > > Nicola > Ok, as it's been a week, I'm going to go ahead and retire buoh. I won't retire libsoup22 as it appears that at least one other package is using it. Jonathan 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 buoh, libsoup22
On Fri, 2012-03-09 at 10:05 +0200, Jonathan Dieter wrote: > Ok, as it's been a week, I'm going to go ahead and retire buoh. I won't > retire libsoup22 as it appears that at least one other package is using > it. > > Jonathan And it appears that I can't commit my changes in git. I'm assuming it's because I accidentally hit the retire button on the F17 branch when I orphaned buoh. If a provenpackager could help me, please, I'd like to retire buoh in master and f17 (if possible). Jonathan 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: phoronix benchmarks ext4 vs. btrfs
On Mar 9, 2012, at 12:30 AM, Matthias Runge wrote: >> > if your file system places data inefficiently on disk/storage, you want > to measure this, too. If you're comparing file system speed, I think, > you should measure the whole thing and be sure to create comparable > data. The source files are on a jhfs+ volume. I'm disinterested in disk to disk copy. And I'm disinterested in comparing jhfs+ to other file system copies. I'm wondering how a system pushing data from memory to disk. > > You can't really control, how your file system cache is filled. > Although I must say, measuring a the whole effort a few times > consecutively provides more reliable numbers (caution: but no > disk speed measurement). I can probably control it to some degree if there isn't much free memory left, by creating a large ramdisk, that will end up as file system cache. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review Swap: smb4k
On Wed, 07 Mar 2012 23:46:58 +, SB (Sérgio) wrote:
> Hi,
> I'd like that someone sponsor me, to reinsert smb4k in Fedora.
> I have follow upstream and update the package to last stable version.
> The .spec is just an update of previous version, so should be easy to
> review , or is already reviewed .
>
> https://bugzilla.redhat.com/show_bug.cgi?id=799651
The package doesn't follow the latest packaging guidelines yet, however.
Could you re-examine sections
* BuildRoot tag
* Explicit Requires
* Requiring Base Package
* File Permissions
at https://fedoraproject.org/wiki/Packaging:Guidelines ?
Further items:
> %setup -q
> # Fix pt translation
> pushd po/pt/
> mv pt.po smb4k.po
> popd
When was that fix introduced? And is it still necessary?
The comment could be more verbose.
> %files devel
> %defattr(-,root,root,-)
> # %{_kde4_includedir}/smb4k*.h
> %{_libdir}/libsmb4kc*.so
Why is the headers dir not included? The -devel package explicitly
refers to "include files". Where are they?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review Swap: smb4k
As smb4k is a KDE Platform based app, I can also help with review, just we will have to find a sponsor. Also please go through the current packaging guidelines as Michael already pointed you to it. Jaroslav - Original Message - > Hi, > I'd like that someone sponsor me, to reinsert smb4k in Fedora. > I have follow upstream and update the package to last stable version. > The .spec is just an update of previous version, so should be easy to > review , or is already reviewed . > > https://bugzilla.redhat.com/show_bug.cgi?id=799651 > > Thanks, > -- > Sérgio M. B. > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: User session printing
On Thu, 2012-03-08 at 09:52 -0900, Jef Spaleta wrote: > 2012/3/8 Miloslav Trmač : > > The lazy answer to both is "fail, or not, the same way as cups > > currently fails, or not" (in fact, could the session printing service > > simply be cups that treats the system instance as another remote > > server?). > > If we were looking for the lazy answer, we'd just not bother with queing at > all. Yes, exactly, and that is what I'm suggesting. For printing entirely in the user session it is a case of using an alternative to using CUPS running on the local machine, so that means: a) no filters or drivers; the job document is the PDF produced by the application/print dialog b) no queueing; submit the job directly to the print server, and if that fails then explain why immediately 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: [fedora-java] Roadmap for Java things in Fedora
Quoting Garrett Holmstrom (2012-03-08 23:11:26) >On Mar 7, 2012 7:54 AM, "Stanislav Ochotnicky" >wrote: >> - Remove mention of maven2 in guidelines since all supported versions >>have maven-3.x. Some other small cleanups as well perhaps > >Is there already a separate set of java guidelines for EPEL? If there isn't >does this mean we should create them? I am not sure why maven2 part peaked your interest with regards to EPEL. Maven 2 is not present there at all. There is in fact very little Java world in EPEL and if someone wants to change that: Great! But heed my warning: Unless you are one-man-packaging-army, you'll end up crazy old man/woman before packaging anything useful. As far as I am concerned: EPEL follows Fedora guidelines that existed at the time when RHEL was branched off Fedora. So it might make sense to freeze them in some state somewhere for posterity I guess, but I wouldn't touch them (much) -- Stanislav Ochotnicky Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning buoh, libsoup22
On 03/09/2012 08:12 AM, Jonathan Dieter wrote: On Fri, 2012-03-09 at 10:05 +0200, Jonathan Dieter wrote: Ok, as it's been a week, I'm going to go ahead and retire buoh. I won't retire libsoup22 as it appears that at least one other package is using it. Jonathan And it appears that I can't commit my changes in git. I'm assuming it's because I accidentally hit the retire button on the F17 branch when I orphaned buoh. If a provenpackager could help me, please, I'd like to retire buoh in master and f17 (if possible). Done. All that's left for you to do is to file a rel-eng ticket to get the package to be blocked from F-17 and Rawhide (step 7 on http://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life). Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-java] Roadmap for Java things in Fedora
- Original Message - > From: "Stanislav Ochotnicky" > To: "Development discussions related to Fedora" > > Sent: Friday, March 9, 2012 11:58:39 AM > Subject: Re: [fedora-java] Roadmap for Java things in Fedora > > Quoting Garrett Holmstrom (2012-03-08 23:11:26) > >On Mar 7, 2012 7:54 AM, "Stanislav Ochotnicky" > > > >wrote: > >> - Remove mention of maven2 in guidelines since all supported > >> versions > >>have maven-3.x. Some other small cleanups as well perhaps > > > >Is there already a separate set of java guidelines for EPEL? If > >there isn't > >does this mean we should create them? > > I am not sure why maven2 part peaked your interest with regards to > EPEL. > Maven 2 is not present there at all. There is in fact very little > Java > world in EPEL and if someone wants to change that: Great! But heed my > warning: Unless you are one-man-packaging-army, you'll end up crazy > old > man/woman before packaging anything useful. > > As far as I am concerned: EPEL follows Fedora guidelines that existed > at > the time when RHEL was branched off Fedora. So it might make sense to > freeze them in some state somewhere for posterity I guess, but I > wouldn't touch them (much) There are a number of libraries available in RHEL 6 which should enable enhancing EPEL 6 substantionally as long as one don't depend on maven or is ready to either redo the package build system to use ant (mvn ant:ant might be your friend) or package Maven into EPEL 6 (this is something I think will be too much work). EPEL 5 should be out of question for almost everything java related as the java packaging changed a lot since RHEL 5 release. P.S. This mail is too not discourage too much from working on EPEL :). Alex > > > -- > Stanislav Ochotnicky > Software Engineer - Base Operating Systems Brno > > PGP: 7B087241 > Red Hat Inc. http://cz.redhat.com > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning buoh, libsoup22
On Fri, 2012-03-09 at 10:20 +, Paul Howarth wrote: > On 03/09/2012 08:12 AM, Jonathan Dieter wrote: > > If a provenpackager could help me, please, I'd like to retire buoh in > > master and f17 (if possible). > > Done. All that's left for you to do is to file a rel-eng ticket to get > the package to be blocked from F-17 and Rawhide (step 7 on > http://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life). Thanks much! I've opened the ticket at https://fedorahosted.org/rel-eng/ticket/5120 Jonathan signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
f16 log flooded with dbus-daemon/upowerd warnings
I've got a lot of messages like this: Mar 9 07:31:49 nbecker1 dbus-daemon[987]: ** (upowerd:1208): WARNING **: Property get or set does not have an interface string as first arg -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: phoronix benchmarks ext4 vs. btrfs
On 03/09/2012 01:43 AM, Adam Williamson wrote: On Thu, 2012-03-08 at 22:19 -0700, Chris Murphy wrote: I'm not sure how useful 'time' is as a benchmark for file copies. Don't file transfers get cached and return to a console as 'complete' long before the data is ever written, sometimes? I'm pretty sure you sometimes hit the case where you copy 200MB to a USB stick, it returns to the console pretty fast, but the light on the stick is still flashing, and if you run 'sync', it sits there for quite a while before returning to the console, indicating the transfer wasn't really complete. So I'm not sure 'time'ing a 'cp' is an accurate test of actual final-write-to-device. That is true---but in that case, we could flush the disks. and then time the operation followed by another flush, i.e.: sync; time (cp ...; sync) I assume that the old-time Unix superstition of calling sync three times no longer applies :) Perhaps a dedicated disk benchmark like bonnie++ would be a better test, though. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: phoronix benchmarks ext4 vs. btrfs
On 03/09/2012 08:42, Przemek Klosowski wrote: On 03/09/2012 01:43 AM, Adam Williamson wrote: On Thu, 2012-03-08 at 22:19 -0700, Chris Murphy wrote: I'm not sure how useful 'time' is as a benchmark for file copies. Don't file transfers get cached and return to a console as 'complete' long before the data is ever written, sometimes? I'm pretty sure you sometimes hit the case where you copy 200MB to a USB stick, it returns to the console pretty fast, but the light on the stick is still flashing, and if you run 'sync', it sits there for quite a while before returning to the console, indicating the transfer wasn't really complete. So I'm not sure 'time'ing a 'cp' is an accurate test of actual final-write-to-device. That is true---but in that case, we could flush the disks. and then time the operation followed by another flush, i.e.: sync; time (cp ...; sync) I assume that the old-time Unix superstition of calling sync three times no longer applies :) Perhaps a dedicated disk benchmark like bonnie++ would be a better test, though. If you want to look seriously into file-system benchmarking I would suggest looking into the work done by the fsbench people at Stony Brook University's Filesystem and Storage Lab (FSL). There is a survey paper there for the last decade of FS benchmarks and their short commings and what should be addressed. http://www.fsl.cs.sunysb.edu/project-fsbench.html Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-constant-boolean] Created tag perl-constant-boolean-0.02-5.el6
The lightweight tag 'perl-constant-boolean-0.02-5.el6' was created pointing to: e708c4f... - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass -- 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: f16 log flooded with dbus-daemon/upowerd warnings
On 03/09/2012 12:53 PM, Neal Becker wrote: I've got a lot of messages like this: Mar 9 07:31:49 nbecker1 dbus-daemon[987]: ** (upowerd:1208): WARNING **: Property get or set does not have an interface string as first arg Seems to be KDE specific see bug 743344 ... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: phoronix benchmarks ext4 vs. btrfs
On Fri, Mar 9, 2012 at 10:11 AM, David Quigley wrote: > On 03/09/2012 08:42, Przemek Klosowski wrote: >> >> On 03/09/2012 01:43 AM, Adam Williamson wrote: >>> >>> On Thu, 2012-03-08 at 22:19 -0700, Chris Murphy wrote: I'm not sure how useful 'time' is as a benchmark for file copies. >>> >>> >>> Don't file transfers get cached and return to a console as 'complete' >>> long before the data is ever written, sometimes? >>> >>> I'm pretty sure you sometimes hit the case where you copy 200MB to a USB >>> stick, it returns to the console pretty fast, but the light on the stick >>> is still flashing, and if you run 'sync', it sits there for quite a >>> while before returning to the console, indicating the transfer wasn't >>> really complete. So I'm not sure 'time'ing a 'cp' is an accurate test of >>> actual final-write-to-device. >> >> >> That is true---but in that case, we could flush the disks. and then >> time the operation followed by another flush, i.e.: >> >> sync; time (cp ...; sync) >> >> I assume that the old-time Unix superstition of calling sync three >> times no longer applies :) >> >> Perhaps a dedicated disk benchmark like bonnie++ would be a better >> test, though. > > > > If you want to look seriously into file-system benchmarking I would suggest > looking into the work done by the fsbench people at Stony Brook University's > Filesystem and Storage Lab (FSL). There is a survey paper there for the last > decade of FS benchmarks and their short commings and what should be > addressed. > > > http://www.fsl.cs.sunysb.edu/project-fsbench.html > fsbench is amazing, I also use fio and fs_mark to test various things. But these are artificial workloads! These numbers don't mean a damned thing to anybody, the only way you know if a fs is going to work for you is if you run your application on a couple of fses and figure out which one is faster for you! For example if you mostly compile kernels, btrfs is fastest. However if you mostly use a fs for your virt images, don't use btrfs! It's all a matter of workloads and no amount of benchmarking is going to be able to tell you if your pet workload is going to work well at all. The work that we file system developers do with benchmarking is to stress particular areas of our respective filesystems. For example, with Dave's tests he was testing our ability to scale as the amount of metadata gets ridiculously huge. He has exposed real problems that we are working on fixing. However these real problems are things that I imagine 99% of you will never run into, and therefore should not be what you use to base your decisions on. So let's try to remember that benchmarks mean next to nothing to real users, unless watching iozone output happens to be what you use your computer for. Thanks, Josef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Test-Assert/f17] (2 commits) ...Run the release tests too
Summary of changes: ab75957... Update to 0.0504 (*) 69c4f9e... Run the release tests too (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: phoronix benchmarks ext4 vs. btrfs
On 03/09/2012 11:00, Josef Bacik wrote: On Fri, Mar 9, 2012 at 10:11 AM, David Quigley wrote: On 03/09/2012 08:42, Przemek Klosowski wrote: On 03/09/2012 01:43 AM, Adam Williamson wrote: On Thu, 2012-03-08 at 22:19 -0700, Chris Murphy wrote: I'm not sure how useful 'time' is as a benchmark for file copies. Don't file transfers get cached and return to a console as 'complete' long before the data is ever written, sometimes? I'm pretty sure you sometimes hit the case where you copy 200MB to a USB stick, it returns to the console pretty fast, but the light on the stick is still flashing, and if you run 'sync', it sits there for quite a while before returning to the console, indicating the transfer wasn't really complete. So I'm not sure 'time'ing a 'cp' is an accurate test of actual final-write-to-device. That is true---but in that case, we could flush the disks. and then time the operation followed by another flush, i.e.: sync; time (cp ...; sync) I assume that the old-time Unix superstition of calling sync three times no longer applies :) Perhaps a dedicated disk benchmark like bonnie++ would be a better test, though. If you want to look seriously into file-system benchmarking I would suggest looking into the work done by the fsbench people at Stony Brook University's Filesystem and Storage Lab (FSL). There is a survey paper there for the last decade of FS benchmarks and their short commings and what should be addressed. http://www.fsl.cs.sunysb.edu/project-fsbench.html fsbench is amazing, I also use fio and fs_mark to test various things. But these are artificial workloads! These numbers don't mean a damned thing to anybody, the only way you know if a fs is going to work for you is if you run your application on a couple of fses and figure out which one is faster for you! For example if you mostly compile kernels, btrfs is fastest. However if you mostly use a fs for your virt images, don't use btrfs! It's all a matter of workloads and no amount of benchmarking is going to be able to tell you if your pet workload is going to work well at all. The work that we file system developers do with benchmarking is to stress particular areas of our respective filesystems. For example, with Dave's tests he was testing our ability to scale as the amount of metadata gets ridiculously huge. He has exposed real problems that we are working on fixing. However these real problems are things that I imagine 99% of you will never run into, and therefore should not be what you use to base your decisions on. So let's try to remember that benchmarks mean next to nothing to real users, unless watching iozone output happens to be what you use your computer for. Thanks, Josef True fsbench can be used for micro benchmarking but if you read the paper on that page it also goes over the bechmarking suites that are supposed to provide real world workloads as well. Copying files isn't much more complex than a couple micro benchmarks. It really is only testing read/write performance. If you want to do real performance testing like you said you need to be running real world workloads. The database benchmarks in the paper cover some of them but also provides criticism about the nature of the workloads. The cool thing about the projects on those pages is that they allow you to capture the same workload and replay them on different filesystems. You can hope you get the same workload twice across two runs or you can capture the workload with tracefs and replay it with replayfs. Now this does introduce some overhead as these are stackable filesystems so they are going to add an additional thin vfs like layer to your analysis but if both of the filesystems have that you can factor that overhead out and get performance data for each filesystem individually. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: User session printing
On Fri, Mar 9, 2012 at 12:46 AM, Tim Waugh wrote: > Yes, exactly, and that is what I'm suggesting. For printing entirely in > the user session it is a case of using an alternative to using CUPS > running on the local machine, so that means: > > a) no filters or drivers; the job document is the PDF produced by the > application/print dialog > > b) no queueing; submit the job directly to the print server, and if that > fails then explain why immediately Seems reasonable. Immediate failures will be less for confusing for everyone. And it'll give frontline technical support (community and/or organizational) some ability to actually troubleshoot the failure as its happening. Back to the use case of a primarily single user laptop touching multiple networks on a daily basis. For that situation is it expected that the default print server will still be the laptop's own cup server for networked printers? Or is it expected that by default users will be configuring to talk to the printer server daemon embedded on the actual network printers without having to interact with a local cups daemon at all? I just want to be clear on what b) will look like as part of designed for flow. -jef"Fail Faster!"spaleta -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
GSoC 2012, Fedora Project application is submitted
Hello, I have submitted the application[1] on-behalf the Fedora project for GSoC 2012. Thanks for supporting and volunteering to mentor the ideas[2]. Please feel free to explore the GSoC portal in Fedora wiki[3] and the use the Talk: page for discussions. The selected organizations list will be published on 16th March. If you are interested the idea list is open for ideas, keep adding. Those who are interested, please subscribe for summer-coding list[4]. [1] https://fedoraproject.org/wiki/GSoC_2012_org_application [2] https://fedoraproject.org/wiki/Summer_coding_ideas_for_2012 [3] https://fedoraproject.org/wiki/GSOC_2012 [4] https://admin.fedoraproject.org/mailman/listinfo/summer-coding -- Regards, Buddhike Chandradeepa Kurera(bckurera) Fedora Ambassador Sri Lanka Event Liaison - Design Team Email: bckur...@fedoraproject.org | IRC: bckurera -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Old Fedora versions and bugzilla
Hello, I was looking into bugzilla and I'm wondering why there are open bugs for old and no more maintained Fedora versions ( F < 14). The most part of them are automatically created by ABRT, but why bugzilla should accept to create bugs for unmaintained versions? Is there a logic that I cannot see, or it could be a thing to tweak? Mattia -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summer coding idea
On Fri, 9 Mar 2012 07:15:07 +0530 Buddhike Kurera wrote: > On Wed, Mar 7, 2012 at 10:52 PM, Anuj More > wrote: > > Hello, > > > > I was thinking of porting something like AUR (Arch User Repository) > > to Fedora. I have blogged about it, and any feedback about the > > feasibility, technical issues, is appreciated. > > > > Link to blog post: > > http://execat.blogspot.com/2012/03/aur-clone-for-fedora.html > > > > Also, do you think it's worth adding to this[1] or this[2] page? > > > > Thanks! > > > > [1]: https://fedoraproject.org/wiki/Summer_coding_ideas_for_2012 > > [2]: > > https://fedoraproject.org/wiki/Summer_coding_ideas_for_2012/Students_Idea > > -- Anuj > > Visit: https://fedoraproject.org/wiki/User:Anujmore > > Hello > > I am forwarding the mail from the summer-coding list. > Any idea, support is welcome, thanks This looks like: http://fedoraproject.org/wiki/Category:Copr (which started out as a 2010 summer of code idea). I think a lot of work has been done on it, it's just waiting for some resources and integration type stuff. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Old Fedora versions and bugzilla
* Mattia Verga [09/03/2012 23:26] : > > why > bugzilla should accept to create bugs for unmaintained versions? Is > there a logic that I cannot see, or it could be a thing to tweak? Bugzilla did not have the ability to retire versions until 4.2 https://bugzilla.mozilla.org/show_bug.cgi?id=77193 Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 Alpha and VMWare Fusion
Hi. On Tue, 6 Mar 2012 15:58:16 +0100, Jan Kratochvil wrote > Confirming: > /usr/bin/qemu-kvm -cdrom Fedora-17-Alpha-x86_64-DVD.iso -boot d -m > 2048 -vga vmware fails to initialize X and falls back to text. > > It works with any of -vga cirrus/std/qxl. I have not found Anaconda > Bug for it, if it belongs to Anaconda though. When's the last time this has been confirmed to work? I've never had much luck with qemu's vmware graphics emulation. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 Alpha and VMWare Fusion
On Sat, 10 Mar 2012 00:00:03 +0100, Ralf Ertzinger wrote: > When's the last time this has been confirmed to work? It always worked, for example for: Fedora-16-x86_64-Live-Desktop.iso It crashes even with /usr/bin/X and xorg-x11-drv-vmware-11.0.3-13.fc17.x86_64 (not just in the installer): https://bugzilla.redhat.com/show_bug.cgi?id=782995 https://bugzilla.redhat.com/show_bug.cgi?id=785572 Regards, Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
help requested with Sourceforge download URL for RPM Source tag
In the process of updating the muParser package to the latest upstream release, I am unable to construct a proper Sourceforge URL for the upstream release that meets the Fedora packaging guideline. Can someone more expert about Sourceforge URLs please give me a hand? The file I want is muparser_v2_2_2.zip, which can be seen at this URL: http://sourceforge.net/projects/muparser/files/muparser/Version%202.2.2/ I'm probably doing something dumb, but I can't seem to get that file from any variant of a download.sourceforge.net URL that I've tried, using different variations of the case of the P in the project name, etc. Thanks! Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: help requested with Sourceforge download URL for RPM Source tag
Eric Smith writes: I'm probably doing something dumb, but I can't seem to get that file from any variant of a download.sourceforge.net URL that I've tried, using different variations of the case of the P in the project name, etc. http://downloads.sourceforge.net/project/muparser/muparser/Version%202.2.2/muparser_v2_2_2.zip is going to bounce you to your default mirror. Don't know if rpmlint, or the gizmo that complains about broken source URL links, will have a problem with that. If so, you'll just have to pick the URL for one of the mirrors. Sourceforge mirrors are fairly stable, over time. pgpNXyGJBwhMF.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: help requested with Sourceforge download URL for RPM Source tag
On 03/09/2012 08:15 PM, Eric Smith wrote: In the process of updating the muParser package to the latest upstream release, I am unable to construct a proper Sourceforge URL for the upstream release that meets the Fedora packaging guideline. Can someone more expert about Sourceforge URLs please give me a hand? The file I want is muparser_v2_2_2.zip, which can be seen at this URL: http://sourceforge.net/projects/muparser/files/muparser/Version%202.2.2/ I'm probably doing something dumb, but I can't seem to get that file from any variant of a download.sourceforge.net URL that I've tried, using different variations of the case of the P in the project name, etc. Thanks! Eric http://downloads.sourceforge.net/muparser/muparser_v2_2_2.zip -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: help requested with Sourceforge download URL for RPM Source tag
Orion Poplawski wrote: http://downloads.sourceforge.net/muparser/muparser_v2_2_2.zip Thanks! I could have sworn that I tried that one, but I guess I must have screwed it up somehow. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: help requested with Sourceforge download URL for RPM Source tag
On 3/9/12 10:18 PM, Eric Smith wrote:
> Orion Poplawski wrote:
>> http://downloads.sourceforge.net/muparser/muparser_v2_2_2.zip
>
> Thanks! I could have sworn that I tried that one, but I guess I must have
> screwed it up somehow.
When all else fails, there is always the documentation ;)
(of course finding the docs can sometimes be the trick)
> http://fedoraproject.org/wiki/Packaging:SourceURL#Sourceforge.net
>
> For packages hosted on sourceforge, use
>
> Source0: http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz
>
> changing ".tar.gz" to whatever matches the upstream distribution.
in your case %{name}-%{version} needs tweaking too.
-Eric
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Notice: IPv6 breaking issues tentatively considered blocker for F17
Hey, folks. We made a fairly significant call at the blocker review meeting today, and agreed to notify devel list and FESCo (I'll file a FESCo ticket also) so everyone's aware and can raise objections if they wish. The bug under discussion was https://bugzilla.redhat.com/show_bug.cgi?id=591630 . The effect of the bug is that, if you install Fedora OOTB (the bug applies to at least 15 and 16 as well as 17) on a system on an IPv6-only network, it will not be able to connect to the network. Procedurally, the bug violates the Alpha release criteria "It must be possible to run the default web browser and a terminal application from all release-blocking desktop environments. The web browser must be able to download files, load extensions, and log into FAS" and "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops", but in the specific context of an IPv6-only network. When criteria are breached only in specific configurations, whether they're a blocker or not becomes a judgment call, under this preamble which is in each criteria page: "There may be times where a requirement is unmet only in a particular configuration, such as with some keyboard layouts but not others, or if a particular character is used in a username, password or passphrase. In such cases, the release team should use their judgement and refer to precedent to determine whether or not the issue should be considered to block the release. They should consider the number of users likely to be affected by the issue, the severity of the case when the issue is encountered, and the ease or otherwise with which the issue can be avoided by both informed and uninformed users." At the meeting, we made the call that IPv6-only networks are becoming a configuration sufficiently important that a serious breach of the criteria in the context of an IPv6-only network is significant enough to be considered a release blocker, and we accepted the bug as a blocker. Obviously this is a pretty significant call that would set a precedent for future releases and proposed blockers, so we wanted to flag it up for wider discussion in case anyone thinks it was the wrong way to go. A full log of the meeting is available at http://meetbot.fedoraproject.org/fedora-bugzappers/2012-03-09/f17-beta-blocker-review-2.2012-03-09-17.02.log.html . Discussion of this bug starts from: 18:41:26 Bug 591630: high, urgent, ---, twoerner, ASSIGNED, DHCPv6 responses are not allowed by default ip6tables ruleset Please feel free to comment, thanks! -- 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: Notice: IPv6 breaking issues tentatively considered blocker for F17
On Fri, 2012-03-09 at 20:54 -0800, Adam Williamson wrote: > Hey, folks. We made a fairly significant call at the blocker review > meeting today, and agreed to notify devel list and FESCo (I'll file a > FESCo ticket also) so everyone's aware and can raise objections if they > wish. > > The bug under discussion was > https://bugzilla.redhat.com/show_bug.cgi?id=591630 . The effect of the > bug is that, if you install Fedora OOTB (the bug applies to at least 15 > and 16 as well as 17) on a system on an IPv6-only network, it will not > be able to connect to the network. To be more precise...DHCPv6 is blocked. So I guess if you used a static network config it would work. -- 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: Notice: IPv6 breaking issues tentatively considered blocker for F17
On Fri, Mar 9, 2012 at 11:14 PM, Adam Williamson wrote: > On Fri, 2012-03-09 at 20:54 -0800, Adam Williamson wrote: > > Hey, folks. We made a fairly significant call at the blocker review > > meeting today, and agreed to notify devel list and FESCo (I'll file a > > FESCo ticket also) so everyone's aware and can raise objections if they > > wish. > > > > The bug under discussion was > > https://bugzilla.redhat.com/show_bug.cgi?id=591630 . The effect of the > > bug is that, if you install Fedora OOTB (the bug applies to at least 15 > > and 16 as well as 17) on a system on an IPv6-only network, it will not > > be able to connect to the network. > > To be more precise...DHCPv6 is blocked. So I guess if you used a static > network config it would work. > -- > 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 > Considering how rare it is to use a static network config, a blocker on DHCPv6 is definitely a good idea. I'm aware of at least a few networks that are switching over to v6 internally and using 6to4 techniques to allow IPv4 services to work (which breaks quite a few streaming applications, like Empathy's Google Talk voice/video chat). That being said, it would be considered a v6-only network and it would be quite bad if Fedora couldn't connect to it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
