Re: OpenCASCADE and applications depending on it (was: LinuxCNC RTAI kernel)
Ok, the smesh from sourceforge doesn't appear to be maintained anymore but I have been patching it to keep it working with freecad but checking freecad master they've continued to modify it such that I'm not sure my version will work for much longer. Now the question is what to do about that... I might be able to come up with a "freecad-smesh" subproject as they are turning into the de facto upstream... Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Out of virtual memory on ARM builder
On Fri, Feb 14, 2014 at 04:00:09PM -0600, Mátyás Selmeci wrote: > This may be a stupid question, but can you solve this by putting > more swap on those builders? It depends. If the system is sufficiently resource constrained that malloc() is actually telling you that you're not going to the moon, more RAM will help. But what's more likely is that it's running out of process address space - a 32 bit process can only address 3GB of address space (which isn't necessarily all RAM), no matter how much RAM is available[1]. Adding more RAM isn't going to help there. Getting rid of 32-bit build systems is. [1] On x86, anyway. I don't know what the ARM VM split is. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Out of virtual memory on ARM builder
On Fri, 14 Feb 2014 16:00:09 -0600 Mátyás Selmeci wrote: > This may be a stupid question, but can you solve this by putting more > swap on those builders? Possibly so yeah. Currently they have 4GB mem and 4GB swap. Ideally it would be good to fix in the package or tools though, so people with smallish machines could actually build things too. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Out of virtual memory on ARM builder
On 02/14/2014 02:53 PM, Dmitry Butskoy wrote: Dennis Gilmore wrote: The arm builders all have 4gb of ram. how much ram should the tests need? BTW, some "big" application -- seamonkey (former mozilla/netscape suite) -- fails to build on arm due to the same reason -- not enough memory on the build host. ~buc This may be a stupid question, but can you solve this by putting more swap on those builders? -Mat smime.p7s Description: S/MIME Cryptographic Signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: advertisement in packaged software (e.g. Firefox)
On Thu, Feb 13, 2014 at 09:01:15PM +0200, Nikos Roussos wrote: > > The fact that the package is calling home (whether or not the location > > of the IP is checked), is a form of tracking. Particularly since firefox > > updates are being handled by Fedora and there is no need for our version > > to be calling home to check for updates. > > *If* it calls home. If this is a predefined list bundled with firefox > there is no reason to call home. The currently available bits of information suggest otherwise: > What information will Mozilla provide sponsored content partners from > the Directory Tiles? > > Mozilla is putting together just the basic metrics that marketers or > content publishers might need to understand the value they are > receiving. As of now, our expectation is that we’ll be delivering the > number of impressions (how many times a tile was shown) and > interactions (how many interactions with a tile, i.e. clicks). taken from: https://blog.mozilla.org/advancingcontent/2014/02/13/more-details-on-directory-tiles/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up; F22 will require applications to ship appdata to be listed in software center
On 02/14/2014 01:41 PM, Adam Williamson wrote: On Fri, 2014-02-14 at 13:02 -0500, Przemek Klosowski wrote: On 01/28/2014 03:12 PM, Richard Hughes wrote: On 28 January 2014 18:43, Przemek Klosowski wrote: There are two separate issues here: 'abandonment', and 'GUIness'. As to the latter, I think it's a mistake to have a primary application installation tool that only deals with GUI apps, because it relegates text-based tools, such as 'units', to a second-class status of being hard to find and to install. That's not the tool we've designed and built. We've built a GUI application installer, not a package installer. While it's not the fault of the installer, I am concerned about that distinction. For better or worse, a lot of useful tools seem to be out of scope for a 'GUI application installer'. GCC, perl, git, octave, R, units, mysql/sqlite3, this kind of thing. Do you actually want to use a tool like Software to install gcc? I just can't see why you would. You know gcc is what you want. You don't need a shiny description and some screenshots and user reviews on a 1-5 star scale. 'yum install gcc' seems a massively better fit. Who would it benefit to have something like gcc in Software? I see what you mean, but how do you install it, and other examples I provided? It's not just gcc: it's gcc-gfortran, gcc-arm, mingw64-gcc, msp430-gcc, etc. If we are providing a next-generation UI for installing, to replace yum, I think it is a step backwards to take away the full search coverage of yum. Let's follow gmail's example: no folders, no fixed hierarchy, just good search. It took me a while to get used to it but I like it now. Maybe I am getting old and grouchy but I think it's an example of the disturbing trend to have a separate tool for every little variation of every function. Just in the last two days I had to consider: - separate installers for different types of applications - having to use all of yum check, yum-complete-transaction, package-cleanup --cleandupes, and rpm --rebuilddb on my failed update - separate droid apps for reading reddit, slashdot, hackaday, etc. Computers are supposed to simplify life! ... Heh, I see my mistake now... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up; F22 will require applications to ship appdata to be listed in software center
2014-02-14 19:41 GMT+01:00 Adam Williamson : > Do you actually want to use a tool like Software to install gcc? > > I just can't see why you would. You know gcc is what you want. You don't > need a shiny description and some screenshots and user reviews on a 1-5 > star scale. 'yum install gcc' seems a massively better fit. Who would it > benefit to have something like gcc in Software? > -- If you are an old Fedora user you will know that the GCC C++ compiler package name is gcc-cpp. However if you are a new Fedora user how are you supposed to know that? Search on the internet? /Andreas Tunek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
EPEL Fedora 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 663 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6 93 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12079/bip-0.8.9-1.el6 16 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0378/quassel-0.9.2-1.el6 15 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0398/socat-1.7.2.3-1.el6 14 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0409/zarafa-7.1.8-1.el6 12 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0426/tpp-1.3.1-17.el6 11 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0440/fwsnort-1.6.4-1.el6 7 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0466/python-gnupg-0.3.6-1.el6 7 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0465/lighttpd-1.4.34-1.el6 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0395/libpng10-1.0.61-1.el6 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0483/boinc-client-7.2.33-3.git1994cc8.el6 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0507/seamonkey-2.21-4.ESR_24.3.0.el6 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0509/python-tahrir-0.5.2-1.el6 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0514/python-tahrir-0.5.1-1.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0525/libyaml-0.1.5-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing bodhi-0.9.8-2.el6 ghc-dlist-0.5-6.el6 libyaml-0.1.5-1.el6 php-horde-Horde-Cache-2.4.1-1.el6 php-horde-Horde-HashTable-1.1.1-1.el6 php-horde-Horde-Imap-Client-2.18.0-1.el6 php-horde-Horde-Injector-2.0.3-1.el6 php-horde-Horde-Mail-2.1.5-1.el6 php-horde-Horde-Mime-2.2.9-1.el6 php-horde-Horde-Smtp-1.4.0-1.el6 php-horde-Horde-Stream-Wrapper-2.1.0-1.el6 php-horde-Horde-Translation-2.1.0-1.el6 php-sabre-dav-1.8.8-1.el6 python-pelican-3.3.0-3.el6 Details about builds: bodhi-0.9.8-2.el6 (FEDORA-EPEL-2014-0530) A modular framework that facilitates publishing software updates Update Information: https://lists.fedorahosted.org/pipermail/bodhi/2014-February/000751.html ChangeLog: * Tue Feb 11 2014 Luke Macken - 0.9.8-2 - Patch our setuptools requirement from Pillow to PIL on RHEL 5 & 6 * Tue Feb 11 2014 Luke Macken - 0.9.8-1 - Update to 0.9.8 * Fri Dec 6 2013 Pierre-Yves Chibon fr - 0.9.7-2 - Change BR from python-setuptools-devel to python-setuptools See https://fedoraproject.org/wiki/Changes/Remove_Python-setuptools-devel * Tue Sep 10 2013 Luke Macken - 0.9.7-1 - Update to 0.9.7 * Sat Aug 3 2013 Fedora Release Engineering - 0.9.5-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild * Wed May 29 2013 Luke Macken - 0.9.5-2 - Update the man page * Mon May 13 2013 Luke Macken - 0.9.5-1 - New bugfix release to work with python-bugzilla 0.8.0 * Fri Feb 22 2013 Luke Macken - 0.9.4-1 - New bugfix release * Wed Feb 13 2013 Fedora Release Engineering - 0.9.3-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild * Tue Nov 13 2012 Luke Macken - 0.9.3-1 - 0.9.3 bugfix release * Wed Aug 8 2012 Luke Macken - 0.9.2-2 - Require python-tgcaptcha2 * Sat Aug 4 2012 Luke Macken - 0.9.2-1 - 0.9.2 bugfix release * Thu Jul 26 2012 Ralph Bean - 0.9.1-3 - "bodhi" now owns datadir, bodhi.cfg, and var/log/bodhi * Thu Jul 26 2012 Ralph Bean - 0.9.1-2 - Fix to "bodhi" user creation. * Thu Jul 26 2012 Ralph Bean - 0.9.1-1 - Creating a 'bodhi' user for mod_wsgi * Wed Jul 18 2012 Fedora Release Engineering - 0.8.5-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild * Thu Mar 29 2012 Ralph Bean - 0.8.8-1 - Sending messages with fedmsg * Thu Jan 12 2012 Fedora Release Engineering - 0.8.5-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild * Tue Nov 22 2011 Luke Macken - 0.8.5-1 - Update to the latest upstream release ghc-dlist-0.5-6.el6 (FEDORA-EPEL-2014-0527) Haskell differences lists Update Information: Haskell difference lists - http://hackage.haskell.org/package/dlist-0.5 References: [ 1 ] Bug #664205 - Review Request: ghc-dlist - Haskell package that provides difference lists https://bugzilla.redhat.com/show_bug.cgi?id=664205
EPEL Fedora 5 updates-testing report
The following Fedora EPEL 5 Security updates need testing: Age URL 663 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5 154 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11560/fail2ban-0.8.10-4.el5 118 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11893/libguestfs-1.20.12-1.el5 93 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12091/bip-0.8.9-1.el5 83 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12169/gc-7.1-6.el5 14 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0410/zarafa-7.1.8-1.el5,php53-mapi-7.1.8-1.el5 11 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0433/puppet-2.7.25-1.el5 7 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0471/lighttpd-1.4.34-1.el5.1 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0531/libyaml-0.1.2-6.el5 The following builds have been pushed to Fedora EPEL 5 updates-testing libyaml-0.1.2-6.el5 Details about builds: libyaml-0.1.2-6.el5 (FEDORA-EPEL-2014-0531) YAML 1.1 parser and emitter written in C Update Information: Add updated indent/flow patches for CVE-2013-6393 (bz1063867) Add patches for CVE-2013-6393 (bz1033990) References: [ 1 ] Bug #1033990 - CVE-2013-6393 libyaml: heap-based buffer overflow when parsing YAML tags https://bugzilla.redhat.com/show_bug.cgi?id=1033990 ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Out of virtual memory on ARM builder
Dennis Gilmore wrote: The arm builders all have 4gb of ram. how much ram should the tests need? BTW, some "big" application -- seamonkey (former mozilla/netscape suite) -- fails to build on arm due to the same reason -- not enough memory on the build host. ~buc -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: The F20 Network Bridge is Failing down!
What version of libnl3 do you have installed? I was having bridge problems too this week. I downgraded libnl3 from 3.2.24-1.fc20 to 3.2.21-2.fc20 and restarted the NetworkManager service, and then my bridge worked. See https://bugzilla.redhat.com/1063290 - Ken On Fri, Feb 14, 2014 at 12:30 PM, Jon wrote: > I've also noticed a regression in my network bridge setup. > Use bridging for both virt-manager, and development work with aarch64 > bringup (emulated ARMv8). > Have seen this happen on two recently updated f20 systems. > > I'm using traditional network-scripts, and what happens is the > physical interface appears to not be added to the bridge interface, > E.G. 'brctl addif br0 em1'. > Will investigate more as time allows, but wanted to confirm the > problem with "me too". > > Thanks, > -Jon Disnard > fas: parasense > irc: masta > > > On Tue, Feb 11, 2014 at 2:11 PM, Steve Dickson wrote: >> Hello, >> >> I have two fully updated F20 boxes running VMs. The >> bridging on one box was working but not on the >> other... It appeared the only real difference was >> the names. The working bridge was call 'br0' >> and the non-working was called 'bridge0' >> >> I also notice that 'br0' showed virt-manager's list of >> viable network interfaces and 'bridge0' did not. >> Obviously that was the problem. >> >> So tried to rename bridge0 to br0 by changing the names >> of the ifcfg files... no luck... the bridge would not come up. >> Next I just remove 'bridge0' and create a new 'br0'. This >> is where I hit the wall. >> >> 1) Network setup will no longer gives an option to create a bridge >>as it once did. The only option I get is VPN. >> >> 2) I am able to create a bridge with nm-connection-editor but >>Network setup still can't see it to bring it up >> >> 3) Using the nmcli command to bring the bridge up, I get >>the following error: >> >># nmcli con up "br0 slave 1" still errors out with >>Error: Connection activation failed: No compatible disconnected device >> found for master connection 157112b2-aea3-4b03-b91e-186bcffbb3f4. >> >> So I went from a functioning bridge not being recognized by virt-manager >> to not being able bring a bridge up or have it recognized by Network Setup. >> >> Any ideas what is going on here? Again, this is on a fully updated >> F20 box... >> >> tia! >> >> steved. >> >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > > > > -- > > -Jon > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: The F20 Network Bridge is Failing down!
I've also noticed a regression in my network bridge setup. Use bridging for both virt-manager, and development work with aarch64 bringup (emulated ARMv8). Have seen this happen on two recently updated f20 systems. I'm using traditional network-scripts, and what happens is the physical interface appears to not be added to the bridge interface, E.G. 'brctl addif br0 em1'. Will investigate more as time allows, but wanted to confirm the problem with "me too". Thanks, -Jon Disnard fas: parasense irc: masta On Tue, Feb 11, 2014 at 2:11 PM, Steve Dickson wrote: > Hello, > > I have two fully updated F20 boxes running VMs. The > bridging on one box was working but not on the > other... It appeared the only real difference was > the names. The working bridge was call 'br0' > and the non-working was called 'bridge0' > > I also notice that 'br0' showed virt-manager's list of > viable network interfaces and 'bridge0' did not. > Obviously that was the problem. > > So tried to rename bridge0 to br0 by changing the names > of the ifcfg files... no luck... the bridge would not come up. > Next I just remove 'bridge0' and create a new 'br0'. This > is where I hit the wall. > > 1) Network setup will no longer gives an option to create a bridge >as it once did. The only option I get is VPN. > > 2) I am able to create a bridge with nm-connection-editor but >Network setup still can't see it to bring it up > > 3) Using the nmcli command to bring the bridge up, I get >the following error: > ># nmcli con up "br0 slave 1" still errors out with >Error: Connection activation failed: No compatible disconnected device > found for master connection 157112b2-aea3-4b03-b91e-186bcffbb3f4. > > So I went from a functioning bridge not being recognized by virt-manager > to not being able bring a bridge up or have it recognized by Network Setup. > > Any ideas what is going on here? Again, this is on a fully updated > F20 box... > > tia! > > steved. > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- -Jon -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ModemManager update
On 13.02.2014 19:56, Dan Williams wrote: > On Sat, 2014-02-01 at 15:03 +0100, poma wrote: >> With a companion libraries. ;) >> >> ↗ libmbim-1.6.0 >> ↗ libqmi-1.8.0 >> ↗ ModemManager-1.2.0 >> >> >> poma >> >> >> Oh Danny boy, the pipes, the pipes are calling >> From glen to glen, and down the mountain side >> The summer's gone, and all the flowers are dying >> 'Tis you, 'tis you must go and I must bide. > > I've done the builds for rawhide with your patches; lets let them be > there for a week to see if there are major issues, and then update F20. > Sound OK? > > Dan > > Maestro! Thanks! poma -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up; F22 will require applications to ship appdata to be listed in software center
On Fri, Feb 14, 2014 at 1:41 PM, Adam Williamson wrote: > On Fri, 2014-02-14 at 13:02 -0500, Przemek Klosowski wrote: >> On 01/28/2014 03:12 PM, Richard Hughes wrote: >> >> > On 28 January 2014 18:43, Przemek Klosowski >> > wrote: >> > > There are two separate issues here: 'abandonment', and 'GUIness'. As to >> > > the >> > > latter, I think it's a mistake to have a primary application installation >> > > tool that only deals with GUI apps, because it relegates text-based >> > > tools, >> > > such as 'units', to a second-class status of being hard to find and to >> > > install. >> > That's not the tool we've designed and built. We've built a GUI >> > application installer, not a package installer. >> [sorry fo the delayed answer---I got wrapped up and had this draft >> sitting open for two weeks] >> >> While it's not the fault of the installer, I am concerned about that >> distinction. For better or worse, a lot of useful tools seem to be out >> of scope for a 'GUI application installer'. GCC, perl, git, octave, R, >> units, mysql/sqlite3, this kind of thing. It doesn't even make sense >> to shoehorn them into GUI app world by embedding them in terminals, >> because their natural environment is command-line interaction. >> >> The emphasis on GUI is great, but it should enhance rather than >> deprecate the old-style interactive command model that arguably is the >> core idea in Unix. Your tool, while improving the GUI app experience, >> could also support non GUI software---or at least not completely >> ignore its existence. I do get it that there is a class of GUI users >> that need to see a window with buttons and help, and non-GUI apps >> simply baffle them with a blinking command prompt, at best. OTOH, I >> believe there should be a setting in the installer about that, "do not >> show me commandline software". I believe that it should be off by >> default, but maybe I am wrong about that. >> >> Do you really think it's impossible? > > Do you actually want to use a tool like Software to install gcc? > > I just can't see why you would. You know gcc is what you want. You don't > need a shiny description and some screenshots and user reviews on a 1-5 > star scale. 'yum install gcc' seems a massively better fit. Who would it > benefit to have something like gcc in Software? I agree listing gcc or make or binutils in Software would be odd. While I don't wish to spin off on a tangent, it might be possible to have a meta "app" entry for things like "DevTools" that installs all of those at once though. This would likely line up well with Software Collections and such as well (at least in my tiny head). josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up; F22 will require applications to ship appdata to be listed in software center
On Fri, 2014-02-14 at 13:02 -0500, Przemek Klosowski wrote: > On 01/28/2014 03:12 PM, Richard Hughes wrote: > > > On 28 January 2014 18:43, Przemek Klosowski > > wrote: > > > There are two separate issues here: 'abandonment', and 'GUIness'. As to > > > the > > > latter, I think it's a mistake to have a primary application installation > > > tool that only deals with GUI apps, because it relegates text-based tools, > > > such as 'units', to a second-class status of being hard to find and to > > > install. > > That's not the tool we've designed and built. We've built a GUI > > application installer, not a package installer. > [sorry fo the delayed answer---I got wrapped up and had this draft > sitting open for two weeks] > > While it's not the fault of the installer, I am concerned about that > distinction. For better or worse, a lot of useful tools seem to be out > of scope for a 'GUI application installer'. GCC, perl, git, octave, R, > units, mysql/sqlite3, this kind of thing. It doesn't even make sense > to shoehorn them into GUI app world by embedding them in terminals, > because their natural environment is command-line interaction. > > The emphasis on GUI is great, but it should enhance rather than > deprecate the old-style interactive command model that arguably is the > core idea in Unix. Your tool, while improving the GUI app experience, > could also support non GUI software---or at least not completely > ignore its existence. I do get it that there is a class of GUI users > that need to see a window with buttons and help, and non-GUI apps > simply baffle them with a blinking command prompt, at best. OTOH, I > believe there should be a setting in the installer about that, "do not > show me commandline software". I believe that it should be off by > default, but maybe I am wrong about that. > > Do you really think it's impossible? Do you actually want to use a tool like Software to install gcc? I just can't see why you would. You know gcc is what you want. You don't need a shiny description and some screenshots and user reviews on a 1-5 star scale. 'yum install gcc' seems a massively better fit. Who would it benefit to have something like gcc in Software? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up; F22 will require applications to ship appdata to be listed in software center
On 01/28/2014 03:12 PM, Richard Hughes wrote: On 28 January 2014 18:43, Przemek Klosowski wrote: There are two separate issues here: 'abandonment', and 'GUIness'. As to the latter, I think it's a mistake to have a primary application installation tool that only deals with GUI apps, because it relegates text-based tools, such as 'units', to a second-class status of being hard to find and to install. That's not the tool we've designed and built. We've built a GUI application installer, not a package installer. [sorry fo the delayed answer---I got wrapped up and had this draft sitting open for two weeks] While it's not the fault of the installer, I am concerned about that distinction. For better or worse, a lot of useful tools seem to be out of scope for a 'GUI application installer'. GCC, perl, git, octave, R, units, mysql/sqlite3, this kind of thing. It doesn't even make sense to shoehorn them into GUI app world by embedding them in terminals, because their natural environment is command-line interaction. The emphasis on GUI is great, but it should enhance rather than deprecate the old-style interactive command model that arguably is the core idea in Unix. Your tool, while improving the GUI app experience, could also support non GUI software---or at least not completely ignore its existence. I do get it that there is a class of GUI users that need to see a window with buttons and help, and non-GUI apps simply baffle them with a blinking command prompt, at best. OTOH, I believe there should be a setting in the installer about that, "do not show me commandline software". I believe that it should be off by default, but maybe I am wrong about that. Do you really think it's impossible? By the way, I even use some commandline-like apps on my Android. In fact, I dislike the fact that the 'GUI app' view of the world results in separate app for every function: an app for Slashdot, and a slightly different app for Reddit. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal to WGs and rel-eng: Move 90-default.preset from systemd to fedora-release
On Fri, Feb 14, 2014 at 04:02:47PM +0100, Kevin Kofler wrote: > > That seems reasonable, and in that case, something like "fedora-presets" > > and "fedora-workstation-presets", etc., seems appropriate, and the > > corresponding release package could pull them in. > What about my proposal to drop the preset directly onto the file system (but > in /etc rather than in /usr/share as we do now) in the live kickstarts? > After all, a file in /etc doesn't really need to be owned by some package. > (Having it unowned also means sysadmins can easily customize it by editing > it directly, as opposed to creating their own file in /etc.) I think in most caess, it's actually _nicer_ to create your own overrides file rather than editing a big monolith one, bceause with the monolithic approach you have to deal with merging changes in areas you didn't care about. I'm also not in favor of adding _more_ "canonical voodoo" to kickstart files -- that is, stuff which is effectively mandatory in every %post section. -- Matthew Miller-- Fedora Project-- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [stable branch idea] Re: Branched iso
On Sex, 2014-02-14 at 14:36 +0700, Michel Alexandre Salim wrote: > Hi Sérgio, > > On 02/14/2014 02:28 PM, Sérgio Basto wrote: > > > sorry I don't have time to follow fedora.next tread / discussion , btw I > > also have a big idea for fedora.stable , pretty simple idea, to a fedora > > releases more stable like one fedora 20.1 > > > There used to be such an effort (look up Fedora Unity re-spins) but it > eventually foundered. > > Recent Fedora releases have updates available in deltarpm formats, which > greatly reduces the amount of bandwith required to get the latest > updates -- do you have a specific use case where that does not suffice? > > (in which case I'd recommend setting up a local mirror and/or a > Spacewalk update server) Fedora n.1 will bring a better and consolidated spins, boot.iso, etc, and is just use pungi , for smooth upgrade from Fedora n-1 , is just an rebase of updates. Maybe when I get a more powerfull laptop , for my server build there some of those things . > Best regards, > -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: libicu soname bump in rawhide
Hi, On Fri, Feb 14, 2014 at 01:40:26PM +0100, Jakub Jelinek wrote: > On Tue, Feb 11, 2014 at 10:41:09PM +0100, Eike Rathke wrote: > > As pre-announced on devel@ I'm updating libicu to 52.1 > > Note, e.g. texlive hasn't been rebuilt yet in rawhide, it is broken for more > than 2 days now, which e.g. blocks building gcc and thus a F21 mass rebuild. texlive build is finishing. Everything else that does not FTBFS has been rebuilt. D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Why libicu soname bump required harfbuzz package to be built twice?
Hi, On Fri, Feb 14, 2014 at 08:47:25AM -0700, Kevin Fenzi wrote: > On Thu, 13 Feb 2014 21:44:12 -0800 > Adam Williamson wrote: > > > icu requires quite a large number of rebuilds, including some tricky > > ones (I just did tracker, which has to be bootstrapped, and > > libreoffice is another...), so I think it's reasonable to assume the > > icu maintainer isn't going to be doing them all, and help out with > > the rest. gnustep is being a PITA now. le sigh. > > I'll also note that the icu maintain is not a provenpackager. It was mainly a communication problem: I was prepared to handle the rebuilds, but when Eike did not ping me that he built new ICU, I assumed that he got hold of some other provenpackager :-( D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Out of virtual memory on ARM builder
On 02/14/2014 05:30 PM, Jerry James wrote: But memory, now, that's an issue. All I know for sure is that the x86_64 and i686 builds succeeded, so those boxes had "enough" memory; the ARM build failed, so that box did not have "enough" memory. Based on the data presented so far, it could also be an ARM-specific GCC bug, so no amount of memory would be sufficient there. -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Out of virtual memory on ARM builder
On Fri, Feb 14, 2014 at 9:16 AM, Richard W.M. Jones wrote: > It sounds rather ill-defined :-) What counts as large amounts of > memory or CPU? > Yes, I really don't know. CPU isn't so much the concern, anyway. Let those builder churn away for long periods of time. Bwahahahaha! But memory, now, that's an issue. All I know for sure is that the x86_64 and i686 builds succeeded, so those boxes had "enough" memory; the ARM build failed, so that box did not have "enough" memory. Since memory is exhausted while compiling the test, not while running the test, the required amount of memory isn't necessarily fixed. It may depend on architecture, version of the compiler, and possibly other factors that I don't know about. I really don't know what "enough" is, therefore ... Can you choose it based on something like the output of `free -m` > and/or `grep -i bogomips /proc/cpuinfo` ? Note the second command > might not produce any output (no output on ARM for sure) so don't rely > on that. ... I don't really see how I can do something like this. For now I have turned the troublesome tests off for ARM only, and left behind a comment in the spec that if other architectures fail to compile the tests due to memory exhaustion, the same should be done for them. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Out of virtual memory on ARM builder
On Fri, Feb 14, 2014 at 09:10:23AM -0700, Jerry James wrote: > On Fri, Feb 14, 2014 at 8:54 AM, Jerry James wrote: > > > There's no parallel make involved. Drat. Well, I'll figure out which > > test(s) are eating up the memory and disable it/them on ARM, I guess. > > Thanks for the replies, everybody. > > > > A little bit of digging into the sources shows that I just need to add > -DHAVE_FAST_COMPILER=0 to the build flags to turn off the tests that > require large amounts of memory and CPU cycles to compile. I will do this > for ARM. Are there any secondary arches that are likely to have the same > problem? It sounds rather ill-defined :-) What counts as large amounts of memory or CPU? Can you choose it based on something like the output of `free -m` and/or `grep -i bogomips /proc/cpuinfo` ? Note the second command might not produce any output (no output on ARM for sure) so don't rely on that. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal to WGs and rel-eng: Move 90-default.preset from systemd to fedora-release
On Fri, Feb 14, 2014 at 15:22:26 +, Colin Walters wrote: That would mean that if we wanted to enable a new service by default, admins wouldn't get it on upgrades. Which may be fine with the traditional rpm-on-client-side installs. I don't think that has to be the case. If the files in /etc only list specific services, than an update to the /usr/lib version could still set a default for the new service. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Base] Fedora Base Design Working Group (2014-02-14) meeting minutes and logs
Covered a quick update on the cleanup work with some nice progress (first changes landing!). Moved over to a quick recap of DevConf. Excellent conf there with a panel of the Fedora WG representatives for Q&A. Last but not least requirements checkup, at the moment mainly focused on rel-eng, so dgilmore volunteered to do a writeup of what he knows already will be needed. Meeting ended Fri Feb 14 16:10:15 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2014-02-14/fedora_base_design_working_group.2014-02-14-15.00.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2014-02-14/fedora_base_design_working_group.2014-02-14-15.00.txt Log: http://meetbot.fedoraproject.org/fedora-meeting/2014-02-14/fedora_base_design_working_group.2014-02-14-15.00.log.html Thanks & regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Manager Core Services| Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Wankelstrasse 5 | Web: http://www.redhat.com/ D-70563 Stuttgart, Germany -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Out of virtual memory on ARM builder
On Fri, Feb 14, 2014 at 8:54 AM, Jerry James wrote: > There's no parallel make involved. Drat. Well, I'll figure out which > test(s) are eating up the memory and disable it/them on ARM, I guess. > Thanks for the replies, everybody. > A little bit of digging into the sources shows that I just need to add -DHAVE_FAST_COMPILER=0 to the build flags to turn off the tests that require large amounts of memory and CPU cycles to compile. I will do this for ARM. Are there any secondary arches that are likely to have the same problem? -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Out of virtual memory on ARM builder
On Fri, Feb 14, 2014 at 1:59 AM, Dan Horák wrote: > I think it was g++ (or the ld linker) what went out of memory, not > unexpected with 4GB memory plus some swap, 4 CPUs and parallel make. > Jerry, can you retry with parallel make disabled? > Actually, the failure occurred while running %check, which is this: %check make check There's no parallel make involved. Drat. Well, I'll figure out which test(s) are eating up the memory and disable it/them on ARM, I guess. Thanks for the replies, everybody. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Why libicu soname bump required harfbuzz package to be built twice?
On Thu, 13 Feb 2014 21:44:12 -0800 Adam Williamson wrote: > icu requires quite a large number of rebuilds, including some tricky > ones (I just did tracker, which has to be bootstrapped, and > libreoffice is another...), so I think it's reasonable to assume the > icu maintainer isn't going to be doing them all, and help out with > the rest. gnustep is being a PITA now. le sigh. I'll also note that the icu maintain is not a provenpackager. I should have offered to help when they announced the upgrade. Next time we should see if we can line up some folks to do rebuilds faster on it. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal to WGs and rel-eng: Move 90-default.preset from systemd to fedora-release
On Fri, Feb 14, 2014 at 10:02 AM, Kevin Kofler wrote: Matthew Miller wrote: That seems reasonable, and in that case, something like "fedora-presets" and "fedora-workstation-presets", etc., seems appropriate, and the corresponding release package could pull them in. What about my proposal to drop the preset directly onto the file system (but in /etc rather than in /usr/share as we do now) in the live kickstarts? That would mean that if we wanted to enable a new service by default, admins wouldn't get it on upgrades. Which may be fine with the traditional rpm-on-client-side installs. But I think this "upgrades diverge from fresh reinstalls" is a deeply fundamental problem - one I am simply not allowing to occur in the OSTree replication model. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ModemManager update
On Thu, 2014-02-13 at 19:00 +, Sérgio Basto wrote: > On Qui, 2014-02-13 at 12:56 -0600, Dan Williams wrote: > > On Sat, 2014-02-01 at 15:03 +0100, poma wrote: > > > With a companion libraries. ;) > > > > > > ↗ libmbim-1.6.0 > > > ↗ libqmi-1.8.0 > > > ↗ ModemManager-1.2.0 > > > > > > > > > poma > > > > > > > > > Oh Danny boy, the pipes, the pipes are calling > > > From glen to glen, and down the mountain side > > > The summer's gone, and all the flowers are dying > > > 'Tis you, 'tis you must go and I must bide. > > > > I've done the builds for rawhide with your patches; lets let them be > > there for a week to see if there are major issues, and then update F20. > > Sound OK? > > So to test it, I need build [1] > ModemManager, libmbim and libqmi any thing else ? I believe these 3 are all you need. If you encounter any problems: mmcli --set-logging=DEBUG and then try to reproduce the problem, and grab the systemd journal output from ModemManager. "mmcli -m 0" output is also very useful, feel free to XXX out any IMSI or IMEI or phone #. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal to WGs and rel-eng: Move 90-default.preset from systemd to fedora-release
Matthew Miller wrote: > That seems reasonable, and in that case, something like "fedora-presets" > and "fedora-workstation-presets", etc., seems appropriate, and the > corresponding release package could pull them in. What about my proposal to drop the preset directly onto the file system (but in /etc rather than in /usr/share as we do now) in the live kickstarts? After all, a file in /etc doesn't really need to be owned by some package. (Having it unowned also means sysadmins can easily customize it by editing it directly, as opposed to creating their own file in /etc.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: libicu soname bump in rawhide
On Fri, 2014-02-14 at 13:40 +0100, Jakub Jelinek wrote: > On Tue, Feb 11, 2014 at 10:41:09PM +0100, Eike Rathke wrote: > > As pre-announced on devel@ I'm updating libicu to 52.1 > > When a shared library has so many dependencies and the SONAME has been > bumped already ~ 50 times Well, icu went straight from version 4.8 to 49 so it's really been approx 13 soname bumps since 2006 I believe. FWIW the icu version is tied to the version of the unicode standard it implements. C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal to WGs and rel-eng: Move 90-default.preset from systemd to fedora-release
On Fri, Feb 14, 2014 at 02:30:47AM -0600, Dennis Gilmore wrote: > > > It really depends on how much it changes, I really do not like > > > updating fedora-release very much. > Its something that defines the release, which is done when the release > is out, we did need to make changes recently to support fedup, which > caused issues for those who had modified their .repo files. we have > added newer release GPG keys also, I plan to have f22 and f23's gpg > keys in fedora-release at f21 release time. so that we do not need to > update it. > > Of course if we change the release support period then that may not be > sufficient or appropriate. I don't think adding a file that will change > frequently to something that should be static is appropriate. That seems reasonable, and in that case, something like "fedora-presets" and "fedora-workstation-presets", etc., seems appropriate, and the corresponding release package could pull them in. -- Matthew Miller-- Fedora Project-- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: libicu soname bump in rawhide
On Tue, Feb 11, 2014 at 10:41:09PM +0100, Eike Rathke wrote: > As pre-announced on devel@ I'm updating libicu to 52.1 When a shared library has so many dependencies and the SONAME has been bumped already ~ 50 times, wouldn't it be appropriate time to talk to upstream to consider providing stable API/ABI, symbol versioning etc.? I mean, if a shared library has 1-2 users, we can still live with it being in constant flux, but for a widely used shared library stable public ABI is really important. Note, e.g. texlive hasn't been rebuilt yet in rawhide, it is broken for more than 2 days now, which e.g. blocks building gcc and thus a F21 mass rebuild. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Base] Base Design WG agenda meeting 14. Feb 2014 15:00 UTC on #fedora-meeting
Agenda: - Cleanup status/report - DevConf meet up summary - Requirements/changes Base needs in Fedora (https://fedorahosted.org/fesco/ticket/1178) As time permits: - FPC recommendation for future - Open Floor Thanks & regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Manager Core Services| Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Wankelstrasse 5 | Web: http://www.redhat.com/ D-70563 Stuttgart, Germany -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: advertisement in packaged software (e.g. Firefox)
On 14 February 2014 06:08, Ralf Corsepius wrote: > On 02/13/2014 07:50 PM, Nicolas Mailhot wrote: >> >> >> Le Jeu 13 février 2014 19:40, Rahul Sundaram a écrit : >>> >>> Hi >>> >>> >>> On Thu, Feb 13, 2014 at 12:56 PM, Ralf Corsepius wrote: >>> A party who is molesting me with ads and tries to spy on me, hardly is my friend. >>> >>> >>> >>> That certainly goes way too far. We have assurance from Mozilla that >>> there >>> is no spying or tracking going on here >> >> >> How can they give any assurance? Unless the targets of those ads are >> hosted by mozilla, all it takes to track people is for one of the >> advertisers to read its server logs. > > Exactly. > > Beside this, IMO, the FLOSS community needs to set a non-misunderstandable > sign that Ads are not welcome. > Even the Fedora home page has a hosting sponsor link (though Gnome and FSF don't). I think there's quite a lot of premature overreaction going on here. Provided it's been done in a secure manner this is basically just providing a set of bookmarks, which will actually disappear once you start browsing the web. Mozilla is not Shazam, they're still controlled by a NPO, they've been pushing free software and open standards for over a decade. If they can find a way to get continued funding and less reliance on Google without compromising their principles that's a good thing (hmm, an open source organisation with one major commercial sponsor, sounds familiar). -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Self Introduction: Leon Weber
Hi everyone, I’m a Fedora user for about 1.5 years, and I was missing some software that was available in Debian/Ubuntu but not in Fedora, because it uses historical technologies (shadow authentication instead of PAM, …), mainly my favourite screen locker. Hence, I decided to rewrite it for Fedora, and now I’d like to make it available for other users who might be switching from Debian and miss it like me, or completely new users. I’ve familiarized myself with Fedora’s packaging procedures and done some informal reviews to learn, so now I’m looking for sponsors for Bug #1065306 and #1065301 (the latter of which is a dependency of the first). I mainly programm in Python but also do some sysadmin work or run networks on some german hacker events. Regards, -- Leon. signature.asc Description: Digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Out of virtual memory on ARM builder
On Thu, Feb 13, 2014 at 01:47:51PM -0700, Jerry James wrote: > What do I do about this? > > http://koji.fedoraproject.org/koji/taskinfo?taskID=6526911 > > [While building and running tests]: > > CC ../build/flintxx/test/t-traits > CC ../build/flintxx/test/t-fmpzxx > virtual memory exhausted: Cannot allocate memory > make[1]: *** [../build/flintxx/test/t-fmpzxx] Error 1 > make[1]: Leaving directory `/builddir/build/BUILD/flint-2.4.1/flintxx' > make: *** [check] Error 2 > > The i686 and x86_64 builds were successful. What can I do to increase the > likelihood that the ARM build will also complete successfully? I would > rather not disable tests if that is not absolutely necessary. As a general comment, ARM 32 bit has quite limited physical RAM. Commonly available hardware maxes out at 2 GB. 1 GB or even 512 MB is not uncommon. This might be a factor if you expect people to rebuild your package on their Cubies and Olimexs. The builders apparently have 4 GB according to a comment in this thread. The Calxeda machines I used had 8 GB, the largest I've seen on ARM. These use LPAE (which is like PAE on x86), so all that memory is not available to a single process. ARM 64 bit will be much better. Also the ratio of cores to memory can be unusual. I have an 8 core ARM 32 bit machine that has 2 GB of RAM, with swap on MMC (very slow), so you wouldn't want to do a 'make -j8' on it. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: advertisement in packaged software (e.g. Firefox)
- Original Message - > From the original post at [1]: > > "Directory Tiles will instead suggest pre-packaged content for > first-time users. Some of these tile placements will be from the > Mozilla ecosystem, some will be popular websites in a given geographic > location, and some will be sponsored content from hand-picked partners > to help support Mozilla’s pursuit of our mission. The sponsored tiles > will be clearly labeled as such, while still leading to content we think > users will enjoy." > > It does not look like an advertisement to me and IMHO it's perfectly > okay if we or users can change/remove some of them and replace with > Fedora ones. And the titles are regenerated with recently visited > webpages and thus works as a history. Yeah, this is the way I understand it. If we will be allowed to change it, I can imagine we can use it in a good way to point our users to Fedora sites as bookmarks do now. As I agree we should deal with this situation case by case - can we check with Mozilla, if we would be allowed to change these tiles first? Jaroslav > > ma. > > [1] > https://blog.mozilla.org/advancingcontent/2014/02/11/publisher-transformation-with-users-at-the-center/ > > On 02/12/2014 03:36 PM, Kai Engert wrote: > > On Mi, 2014-02-12 at 10:46 +0100, Kai Engert wrote: > >> Do the Fedora guidelines allow packaging of software that will show > >> advertisement to the user? > >> > >> Are there any existing packages that already do that? > > > > There are multiple open questions that need answers. I wanted to get the > > first question answered first, but since the discussion has already > > started to discuss consequences, let's get the questions and potential > > consequence spelled out and discussed separately. > > > > This discussion is trigged by http://lwn.net/Articles/585577/ > > > > Question (1) > > > > Are we allowed to ship software in Fedora that dynamically loads > > advertisements from the web and shows them to users? > > > > I'm partly guessing here. I suspect that showing advertisements doesn't > > mean showing things that were decided at build time, but rather content > > that is dynamically decided to be delivered by Mozilla. > > > > I think this question should be answered first, and independently of > > other questions. > > > > Question (2) > > > > Is the Fedora community willing to accept Mozilla's desire to show > > advertisements in Firefox? > > > > This might depend on the amount and kind of advertisement that will be > > shown. The information we've received so far in the public blog doesn't > > clarify this yet: > > https://blog.mozilla.org/advancingcontent/2014/02/11/publisher-transformation-with-users-at-the-center/ > > > > Only if the answer to at least one of the questions (1) or (2) is "no", > > then we must discuss the other questions: > > > > Question (3) > > > > Does removing the advertisement feature of Firefox violate the > > trademark? > > > > We don't know the answer yet, and this will probably require a statement > > from Mozilla. > > > > Only if answer for question (3) were "yes", we'd need to look into > > removing the trademarks, and how exactly to do it (whether we'd do it on > > your own, or if we'd work with another project that already does that). > > > > Personally, my initial reaction is disappointment that the free software > > project I've been contributing to since 2001 considers to use it as a > > mechanism to deliver advertisement, but I'd like to wait with my final > > judgement until we hear more details. > > > > Kai > > > > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Out of virtual memory on ARM builder
On Fri, 14 Feb 2014 02:51:36 -0600 Dennis Gilmore wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Thu, 13 Feb 2014 13:47:51 -0700 > Jerry James wrote: > > > What do I do about this? > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=6526911 > > > > [While building and running tests]: > > > > CC ../build/flintxx/test/t-traits > > CC ../build/flintxx/test/t-fmpzxx > > virtual memory exhausted: Cannot allocate memory > > make[1]: *** [../build/flintxx/test/t-fmpzxx] Error 1 > > make[1]: Leaving directory > > `/builddir/build/BUILD/flint-2.4.1/flintxx' make: *** [check] Error > > 2 > > > > The i686 and x86_64 builds were successful. What can I do to > > increase the likelihood that the ARM build will also complete > > successfully? I would rather not disable tests if that is not > > absolutely necessary. > > The arm builders all have 4gb of ram. how much ram should the tests > need? I think it was g++ (or the ld linker) what went out of memory, not unexpected with 4GB memory plus some swap, 4 CPUs and parallel make. Jerry, can you retry with parallel make disabled? Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Out of virtual memory on ARM builder
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 13 Feb 2014 13:47:51 -0700 Jerry James wrote: > What do I do about this? > > http://koji.fedoraproject.org/koji/taskinfo?taskID=6526911 > > [While building and running tests]: > > CC ../build/flintxx/test/t-traits > CC ../build/flintxx/test/t-fmpzxx > virtual memory exhausted: Cannot allocate memory > make[1]: *** [../build/flintxx/test/t-fmpzxx] Error 1 > make[1]: Leaving directory `/builddir/build/BUILD/flint-2.4.1/flintxx' > make: *** [check] Error 2 > > The i686 and x86_64 builds were successful. What can I do to > increase the likelihood that the ARM build will also complete > successfully? I would rather not disable tests if that is not > absolutely necessary. The arm builders all have 4gb of ram. how much ram should the tests need? Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJS/dkZAAoJEH7ltONmPFDRw+kP/Aldw1w08M2v0/Wrnf5rkJb3 jtny2XE4UCLV1zx/g4Fy7SN/f2DIbiJrWrVFul9qHrvTqe0hGHi5tGy50w8XuBtr 01n1NMhuAiXWRXvvPGMGUkxJnDCJWMk39sfuwFzn2Cut5WkkprFzUInjstwtGRkP k8xySLkUrh+9dhO+Gke72e4LSMbphhD5IlmukLnFt3Z/tBsR2pn2TN5QrBfZ1PSH AoJzluVLsnNql7r6tCK/YhBIyb3B9TP1sv32KcKgPWv+9l+KbBGuZYuUIwTaBvqw ZowB93sJiAlaFimbfEbjESHRHtWL2BjhHxHXSMcJf9tcbhejNL4RcUYunZ0d7tTq xdAL7RXPv98rDAuoADU9ibsLWa4TckCh63DUcxzmmrWOHANQQxHeNi994iMQB5VA i+bqjkrkeinDhBm3XvYjZgfAnYXEYMDaNbKYqUpz/Wfg5slgLl4QsH4oeXWFRIbP qn4MZTfwt6VVtMrloYtXSOcvcSYkq/AjoeZ8iB4WzYlTBUG03OpxKG3gK+DyuvXd D++lPy5DYjncQIC/h0XaNfzinWIiKNDWQZKarhC90Zgf4SrHjoLaMKIWlZOA+yhN +NBjw3oOYm5NkKe7S0YquHgNJS+hdt7IF+2p3tsKEQcIwW9rJXrhs2HabNfTYQlv qEi9tDTS157U1GhREHJ1 =FteW -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal to WGs and rel-eng: Move 90-default.preset from systemd to fedora-release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 13 Feb 2014 16:31:31 -0500 Adam Jackson wrote: > On Thu, 2014-02-13 at 13:44 -0600, Dennis Gilmore wrote: > > On Thu, 13 Feb 2014 17:39:40 +0100 > > Miloslav Trmač wrote: > > > > Based on these arguments, I'd like to propose to move this file > > > > to the fedora-release package (or elsewhere, if you can suggest > > > > better place). > > > > > > > > > I agree this would make sense in principle; does the maintainer of > > > fedora-release wants to take on the task to maintain this file? > > > > It really depends on how much it changes, I really do not like > > updating fedora-release very much. > > Because... > Its something that defines the release, which is done when the release is out, we did need to make changes recently to support fedup, which caused issues for those who had modified their .repo files. we have added newer release GPG keys also, I plan to have f22 and f23's gpg keys in fedora-release at f21 release time. so that we do not need to update it. Of course if we change the release support period then that may not be sufficient or appropriate. I don't think adding a file that will change frequently to something that should be static is appropriate. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJS/dQ9AAoJEH7ltONmPFDRuLMP/RJ0KvBWdCZR+Xf4W/8LYpTt 98DH18uzJnzL4pKTGGxp7vA3jDK98si3eLrLDxfRGt34jKxWeT8aiQGnI1K9LF84 vxyNv4+U0hFKNHE5FHcgf3NhR+NIxahwn4+XAklrAodaqnBAUeqnCamEzESbPJIN uhLJfIN+K3rQqfWJs1pm+v23LkCDJeYoaPhM3FYHbJCwHPTgaqEXeNGbxf+6Ri8A HDYwyAhShny6B5cWlqui8wun5xGZhdetYOIUTaed93ibLeXzjiZXYWbbrwwmJSSj 8OdqIYRPJ3g/ul65SFqjd2/nhl7ejoWInWR8/U3F9bz2Rbt/eGyg/3XDcZSY4QvZ 6vrSHnUZWkkXE1KFh3U/yaY8zinz/WCK9lVWC+iuTpyt0mKy65De4n1iVwVYCoGD 5fPM4wyoQMmwhwEXmptMDHWEPEjxAuUN2Vg+XdF2a8M7pLLPqQo6JnvRPaWOVggd 3yKblxVB+BJ6u4Ts0VAdBlPfKkJipY3XlLdBE/ZkKqhc1fnw4Kttr/b8oX2C1bhw WiXLPJlZCJp+pBUBRjCKCkD0LK5l2QIixnHIqkHxd+PapiRST8tc/8+vsBw7yfYo YvPC6g4VjB2jwFetVyBd3ubjak8WMdWXBwJcEldomH7Jz2b4pUX9d2nMS7Is+o3n XdeVM6MP+qsHamJM3Bfe =7My4 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
