PackageKit Password Prompt on Fedora 36
I hope this is the right mailing list since this is about Fedora 36. I upgraded from Fedora 35 to the Fedora 36 Alpha (at the time). Occasionally when coming out of sleep I get a password prompt from, I believe, PackageKit. Before I filed a bug I was curious if this was a known issue. Thanks! -- Mark Bidewell http://www.linkedin.com/in/markbidewell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Building Kernels in Fedora 32
Hopefully this is not too far from Fedora development, but it affects the kernel for Fedora 32. https://bugzilla.kernel.org/show_bug.cgi?id=206661 I'm trying to build a vanilla 5.6 kernel on Fedora 32 to test a fix for Wireless AC issues. When I try to boot the kernel though I just get a black screen. Normal Fedora kernels work and I have disabled UEFI secure boot. Kernels I build in a QEMU VM with a BIOS work so I think this is related to UEFI. Any ideas how to debug? -- Mark Bidewell http://www.linkedin.com/in/markbidewell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 Wifi Loss
On Mon, Feb 24, 2020 at 8:59 PM Samuel Sieb wrote: > On 2/24/20 5:51 PM, Mark Bidewell wrote: > > Looks like an issue with firmware: > > > > Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: no > > suitable firmware found! > > Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: minimum > > version required: (null)0 > > Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: maximum > > version supported: (null)39 > > Definitely looks like a driver bug. You could file a report on the > kernel bugzilla. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Thanks! I created: https://bugzilla.kernel.org/show_bug.cgi?id=206661 -- Mark Bidewell http://www.linkedin.com/in/markbidewell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 Wifi Loss
On Mon, Feb 24, 2020 at 4:27 PM Samuel Sieb wrote: > On 2/24/20 1:02 PM, Mark Bidewell wrote: > > Sorry if this is the wrong list for this, but since this refers to > > Fedora 32 I figured I would start here. I updated to the Fedora 32 > > Branched release and my Wifi no longer enables on the 5.6 RC kernel. > > lspci still shows the wireless card by the is no wifi section in Gnome > > settings and ip addr show does not show the card. Leftover kernels from > > F31 still work fine with Wifi. My card is an Intel Wireless AC 9260 > > > > Any suggestions on how to debug? > > Check the journal for messages about it. Run "sudo journalctl -b" to > see the logs from the current boot. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Looks like an issue with firmware: Feb 24 20:32:51 precision7530-lan kernel: Intel(R) Wireless WiFi driver for Linux Feb 24 20:32:51 precision7530-lan kernel: Copyright(c) 2003- 2015 Intel Corporation Feb 24 20:32:51 precision7530-lan kernel: mc: Linux media interface: v0.10 Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: enabling device ( -> 0002) Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct firmware load for (null)39.ucode failed with error -2 Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct firmware load for (null)38.ucode failed with error -2 Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct firmware load for (null)37.ucode failed with error -2 Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct firmware load for (null)36.ucode failed with error -2 Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct firmware load for (null)35.ucode failed with error -2 Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct firmware load for (null)34.ucode failed with error -2 Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct firmware load for (null)33.ucode failed with error -2 Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct firmware load for (null)32.ucode failed with error -2 Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct firmware load for (null)31.ucode failed with error -2 Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct firmware load for (null)30.ucode failed with error -2 Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct firmware load for (null)29.ucode failed with error -2 Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct firmware load for (null)28.ucode failed with error -2 Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct firmware load for (null)27.ucode failed with error -2 Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct firmware load for (null)26.ucode failed with error -2 Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct firmware load for (null)25.ucode failed with error -2 Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct firmware load for (null)24.ucode failed with error -2 Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct firmware load for (null)23.ucode failed with error -2 Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct firmware load for (null)22.ucode failed with error -2 Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct firmware load for (null)21.ucode failed with error -2 Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct firmware load for (null)20.ucode failed with error -2 Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct firmware load for (null)19.ucode failed with error -2 Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct firmware load for (null)18.ucode failed with error -2 Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct firmware load for (null)17.ucode failed with error -2 Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct firmware load for (null)16.ucode failed with error -2 Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct firmware load for (null)15.ucode failed with error -2 Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct firmware load for (null)14.ucode failed with error -2 Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct firmware load for (null)13.ucode failed with error -2 Feb 24 20:32:51 precisio
Fedora 32 Wifi Loss
Sorry if this is the wrong list for this, but since this refers to Fedora 32 I figured I would start here. I updated to the Fedora 32 Branched release and my Wifi no longer enables on the 5.6 RC kernel. lspci still shows the wireless card by the is no wifi section in Gnome settings and ip addr show does not show the card. Leftover kernels from F31 still work fine with Wifi. My card is an Intel Wireless AC 9260 Any suggestions on how to debug? -- Mark Bidewell http://www.linkedin.com/in/markbidewell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Stop please
On Fri, Jan 8, 2016 at 8:38 AM, Ian Malone <ibmal...@gmail.com> wrote: > On 8 January 2016 at 12:02, Sam Varshavchik <mr...@courier-mta.com> wrote: > > Samuel Sieb writes: > > > >> On 01/07/2016 08:34 PM, Michael Catanzaro wrote: > >>> > >>> I decided I would instruct Byron in how to unsubscribe from our mailing > >>> list, when I discovered *I don't know how.* > >>> > >>> It seems with HyperKitty we no longer have an easily-accessible way to > >>> unsubscribe from our mailing lists. How can this be done without > >>> registering a Fedora account? > >>> > >> There's info in the email headers although if you're not that familiar > >> with mailing lists that's not exactly discoverable. > > > > > > Robust mail clients can use the RFC 2369 headers to prominently present > an > > unsubscribe link when displaying list mail. > > > > Excellent, that's that solved then. > > -- > imalone > http://ibmalone.blogspot.co.uk > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > Unfortunately GMail's web interface does not seem to recognize those headers :(. So a fair number of uses will have issues. BTW thats a great tip on the headers, never know about them until today -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: RFC: Proposal for a more agile Fedora.next (draft of my Flock talk)
No one said that stuff should change unexpectedly (and that's not what currently happens either). Actually its the opposite you want to consider the whole picture when doing changes and not think of independent pieces stuck together. That's why the lets build some core platform and put stuff on top of it is flawed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Honestly, I keep seeing this argument in this thread, but it doesn't square with reality. The concept of an OS and all of its apps as a monolithic distribution with a single release schedule is unique to Linux. Every other major OS (with the exception perhaps of Windows) strictly differentiates between core OS and apps. Some examples: FreeBSD - installs a core OS on which ports and packages are installed into a separate tree. Versions of Ports are allowed to float independent of the BSD base. PC-BSD - listing separately because in addition to the separation by FreeBSD, it introduces self-contained packages that even ship with their own libraries to keep the core clean MacOSX - System is kept in a separate tree from apps. Modification of System Paths is strongly discouraged. Apps are installed in a parallel tree or as packages similar to PC-BSD. Solaris - only ships with an extremely minimal system. Virtually all apps must be install separately. Windows ships a core OS but allows (at least in the past - can't speak to 8) installed apps and libraries to mix with system libraries. But even they seem to be moving toward a more sandboxed model. This is not to say that the Above OSs have it right, but to say a core / apps separation is fundamentally flawed is incorrect. I would say the separation allows for more robust upgrades ( user-installed software doesn't taint the system tree) and more rapid upgrades of apps (a Libreoffice update should have to wait on the Kernel). -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Proposal for a more agile Fedora.next (draft of my Flock talk)
On Fri, Jul 26, 2013 at 9:02 AM, drago01 drag...@gmail.com wrote: On Fri, Jul 26, 2013 at 2:20 PM, Mark Bidewell mbide...@gmail.com wrote: No one said that stuff should change unexpectedly (and that's not what currently happens either). Actually its the opposite you want to consider the whole picture when doing changes and not think of independent pieces stuck together. That's why the lets build some core platform and put stuff on top of it is flawed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Honestly, I keep seeing this argument in this thread, but it doesn't square with reality. The concept of an OS and all of its apps as a monolithic distribution with a single release schedule is unique to Linux. Every other major OS (with the exception perhaps of Windows) strictly differentiates between core OS and apps. Splitting apps and OS makes sense. But the OS is more then just the kernel and a few low level libraries. The OS (without apps) goes up to X/wayland and the desktop environment. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel I would argue that a tri-level separation is best for Linux, A small core OS, a System layer which contains (X, Wayland, DE, etc), and apps. Which circles us back to rings (no pun intended). -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedup Performance
I am doing an upgrade from F18 to F19 using fedup network and performance is very slow - 3+ hours on a 20 Mbit connection. There seems to be about a 10-15 second delay between package downloads. Is there a reason for this delay? -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Fedora revamp proposal
On Wed, Mar 6, 2013 at 10:03 PM, Adam Williamson awill...@redhat.comwrote: So just a couple of notes on the proposal: It's phrased in very technical terms here - probably a wise choice - but I think it's worth noting one of the angles we took in discussing it in person at FUDCon is that it has the potential to contribute to the more general idea of making Fedora more flexible in terms of what we can build and release. It has the effect of giving us a defined 'core' of functionality on top of which we could build various things. It would only be one piece of a larger puzzle here - things like better image building tools and Formulas are part of the same puzzle - but it's an element I was quite interested in. Also, I recall the in-person discussions making it clearer that this plan is pretty strongly dependent on automated testing. This has been discussed somewhat in the follow-ups, but to make sure it's very clear, my reading of the proposal is that it would require substantially more sophisticated and reliable tests than we currently have in AutoQA, and we'd need development resources - either RH paid, or volunteer - to build AutoQA up to the point where it could support this plan without causing unnecessary disruption. -- 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/develhttps://admin.fedoraproject.org/mailman/listinfo/devel Are there any records of these FUDCon discussions? Creating defined core of functionality seems like it could solve several problems. I would be curious as to what ideas we proposed on that. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Mon, Feb 4, 2013 at 12:49 AM, Kevin Kofler kevin.kof...@chello.atwrote: Matthias Clasen wrote: - Cinnamon started out as 'using GNOME components', but it is [now] a full fork of mutter, gnome-shell and nautilus, at least, and bug-fixes are not going either way... Those are applications which form the workspace, not random components. I'm fairly sure that when they speak about reusing GNOME components, they really mean the libraries and the standalone applications, not the workspace. (For those familiar with KDE, what they're forking is only the GNOME equivalent of kde-workspace and not all the other components of GNOME.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel I would oppose Cinnamon as a default on stability/maturity grounds. The last time I tried Cinnamon (granted this was on Ubuntu) it had a lot of problems. For example Nemo would get into fights with the default installed nautilus resulting in no desktop icons. The massive forking of underlying components could easily create problems. KDE however is a tested desktop which I would love to see as the default (or as others have proposed a no default). In my opinion Fedora ships the best KDE around. Although early signs seem to point to Kubuntu 13.04 really improving under Blue Systems TLC. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Where are we going? (Not a rant)
On Sat, Dec 8, 2012 at 1:48 PM, Roberto Ragusa m...@robertoragusa.itwrote: On 12/07/2012 08:26 PM, Mark Bidewell wrote: It underscores the need for the base OS or core to be absolutely as small as possible. FreeBSD provides a good model, small installed system customized with packages/ports. Personally I would like to see a three-level approach: Level 1 (Core) - OS Kernel, command-line utilities, C/C++ compiler and libc - moves the slowest. Level 2 (System) - Dev Libraries, interpreters (Python, Ruby, etc), X11, KDE/QT, GNOME, etc - moves faster. Level 3 (Userland) - LibreOffice, Firefox, Games, etc. A major change to one level should cause a rebuild of higher layers to avoid the API issues you mention. Changes within a layer should be independent. I would propose change rates of: Level 1 - 12-18 mos Level 2 - 6-12 mos Level 3 - release as soon as stable packages are available. IMHO it is not the level of things which is problematic. I have no problem with rapid updates for the kernel (great for hardware support and bug fixes), or for X11 (same reasons), gcc upgrades never gave me problems, I like the fast updates to KDE. There are two things which are problematic: 1) projects undergoing great revolutions. They are quickly absorbed by Fedora and all the immaturity issues of the projects cast shadows on Fedora. Two examples: GNOME 2-3, KDE 3-4; exactly the same problem, upstream changing everything and users unhappy about the results (even if different answers were given by KDE (wait, we will readd what is missing) and by GNOME (forget what is missing, this is how it will be). Obviously a regression of the desktop environment is not a small detail for end users (read: Fedora doesn't work). 2) revolutions at the system level. Things that replace other things and everything changes: command line tools, GUIs, config files, logs, ... Many examples: pulseaudio, NetworkManager, systemd, grub2, firewalld. These projects sometimes have bugs (being in their infancy), often are badly documented and are always completely unknown by end users; the result is that things do not work and who knows how this should be fixed. In many cases the impact on the collateral utilities (dracut, system-config-*, anaconda, ...) contribute to the chaos. As a final consideration, the fixability of the issues is important. I can easily revert to a previous kernel, I can less easily throw away pulseaudio, and I can in no way fix GNOME 3. (my two cents, as someone using Red Hat / Fedora daily since RH5.1, and never stepping up as Fedora packager because too scared by the bureaucracy) -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel I hear you. I will admit I haven't thought through all of the possible permutations. Probably a better criterion would be impact of ABI changes. What I would like to see changed is the fact that, right now (and this goes for all Linux distros), if you want to have the smallest probability of upgrade issues, all packages must upgrade at once - preferably with a clean install. On other OSs, If I want a new version of Libreoffice I can download and install it. On Linux, your choices are: 1) Install from source or packages may be available from the developer and take the risk that they might not play nice with the rest of the system. 2) Wait for the next OS release. It seems like there should be some way to improve this situation. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Fri, Dec 7, 2012 at 8:55 AM, Radek Vokal rvo...@redhat.com wrote: On 12/06/2012 07:00 AM, Adam Williamson wrote: On Wed, 2012-12-05 at 22:25 -0600, Michael Ekstrand wrote: On 12/05/2012 03:06 PM, Bill Nottingham wrote: Matthew Miller (mat...@fedoraproject.org) said: Three things: 1) Fedora is big enough that we have concrete situations where one size doesn't fit all. Puppet being broken on F17 (and probably F18 as well) is a fine example of something within the distro itself. And, as a platform for development, offering more version choices to our users would be a strength. heretical Well, then maybe Fedora's too big, and we should move to a model where Fedora is much smaller, and the grand Fedora universe contains things that are packaged *for* one or multiple Fedoras. /heretical FWIW (probably not much), I also think this is a great idea. It feels strange to me that the same thing contains manages everything from base system (e.g. kernel through core GNOME stack) and add-on apps (say Battle for Wesnoth, to pick a relatively obvious example). Now, there's a bike shed to be painted over where the lines should be drawn. We could draw them between Core and Extras! So what if we actually do .. but in a different way - eg. we would ensure that we have stable API, no feature breakage in a release for a package that do belong to core and allow faster turnaround for packages in extras .. it's not like locking it down as it used to be but defining more strict rules for certain set of packages. R -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel +1 -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Fri, Dec 7, 2012 at 10:40 AM, Jon Masters j...@redhat.com wrote: On 12/06/2012 01:00 AM, Adam Williamson wrote: On Wed, 2012-12-05 at 22:25 -0600, Michael Ekstrand wrote: On 12/05/2012 03:06 PM, Bill Nottingham wrote: Matthew Miller (mat...@fedoraproject.org) said: Three things: 1) Fedora is big enough that we have concrete situations where one size doesn't fit all. Puppet being broken on F17 (and probably F18 as well) is a fine example of something within the distro itself. And, as a platform for development, offering more version choices to our users would be a strength. heretical Well, then maybe Fedora's too big, and we should move to a model where Fedora is much smaller, and the grand Fedora universe contains things that are packaged *for* one or multiple Fedoras. /heretical FWIW (probably not much), I also think this is a great idea. It feels strange to me that the same thing contains manages everything from base system (e.g. kernel through core GNOME stack) and add-on apps (say Battle for Wesnoth, to pick a relatively obvious example). Now, there's a bike shed to be painted over where the lines should be drawn. We could draw them between Core and Extras! :) Note that just because we got rid of Core doesn't mean that it was a bad idea. Ubuntu even adopted a Core of their own a while back. Maybe they'll have the same experience we had and get away from that, or maybe Linux distributions should ultimately not be in the business of providing all+kitchen sink. Speaking only personally, what I want is a stable core platform of very limited size against which I can install other packages and stacks. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel +1 Personally I think the line should be drawn similar to FreeBSD/Ports. Core should be primarily OS kernel, shell utilities and C compiler. Maybe X as well. Extras should be anything not required for an operational system even if installed by the initial install. My biggest beef with Linux packaging has been that, by and large, all packages have to be upgraded in sync if you want to have a supported system. Battle for Wesnoth shouldn't be tied to kernel updates. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Where are we going? (Not a rant)
For example, making it so key applications and development stacks could easily float from one base OS to the next would make it less of an issue when the base OS needs to be upgraded. Not sure I catch your drift here, but it sounds like it could cause API mismatch headaches. It underscores the need for the base OS or core to be absolutely as small as possible. FreeBSD provides a good model, small installed system customized with packages/ports. Personally I would like to see a three-level approach: Level 1 (Core) - OS Kernel, command-line utilities, C/C++ compiler and libc - moves the slowest. Level 2 (System) - Dev Libraries, interpreters (Python, Ruby, etc), X11, KDE/QT, GNOME, etc - moves faster. Level 3 (Userland) - LibreOffice, Firefox, Games, etc. A major change to one level should cause a rebuild of higher layers to avoid the API issues you mention. Changes within a layer should be independent. I would propose change rates of: Level 1 - 12-18 mos Level 2 - 6-12 mos Level 3 - release as soon as stable packages are available. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Thu, Dec 6, 2012 at 10:06 AM, Adam Williamson awill...@redhat.comwrote: On Thu, 2012-12-06 at 15:30 +0100, Nicolas Mailhot wrote: IMHO use of software collections is a symptom of a badly run organisation not devoting enough cycles to maintain the software it uses, and hoping (as in wishful thinking) no problem will go critical before the product they built on top of those collections is end-of-lifed I completely fail to see how entities with that problem will manage to maintain the package number explosion creating software collections will induce. On the one hand, I agree completely - I think the 'share all dependencies dynamically' model that Linux distros have traditionally embraced is the right one, and that we're a strong vector for spreading the gospel when it comes to that model, and it'd be a shame to compromise that. On the other hand, we've been proselytizing the Java heretics for over a decade now, and the Ruby ones for a while, and neither shows any signs of conversion or just plain going away, so we may have to call it an ecumenical matter and deal with their models somehow. Sucky as it may be. I don't know, I'm a bit conflicted. -- 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 I used to use Fedora as my primary OS (Now I use a Mac). The major issue which drove me away and which I believe SC would help to solve is that with the current dependency model is that it becomes I want a new version of Libreoffice so now I have to upgrade my entire system from the Kernel on up (and by upgrade I mean clean install) to avoid issues. SC would help decouple system and userland apps which would do wonders for usability. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yum Package Remove Order
On Fri, Nov 30, 2012 at 10:54 PM, Adam Williamson awill...@redhat.comwrote: On Fri, 2012-11-30 at 17:24 +0100, Nicolas Mailhot wrote: Le Ven 30 novembre 2012 15:11, Mark Bidewell a écrit : I have been working on packaging software into RPMs for my company. These RPMs create directories in %post into which dependent RPMs install components. You need to create those directories in %install and have your package own them in %files, and have dependant rpms depend on your package then everything will work fine Or for bonus points, the app itself ought to create the directories in the first place, if they're associated with the app. Packages should only create directories for stuff that's added as part of the package, not part of the software per se - say, you're including a convenience script which is not upstream, or moving the icons around, or something. -- 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 Here is the setup we have. 1) An RPM which creates a raw JBoss install 2) An RPM which sets up a specialized server config (based on the default config from 1) with common configuration 3) RPMs containing WARs (and configuration). The reason we encounter the CentOS 5 bug is that the when the RPM in 2 uninstalls, it removes the server config and with it the WARs from 3. Is there a better way? Thanks -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Yum Package Remove Order
I have been working on packaging software into RPMs for my company. These RPMs create directories in %post into which dependent RPMs install components. If I yum remove the main package it will be erased first by yum prior to erasing the dependent packages. When the uninstall scripts for the dependent packages run, they may fail due to files and directories being missing that they expect from the main package leaving things in an inconsistent state. Is this a bug or known behavior we need to account for in some way? Thanks. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yum Package Remove Order
On Fri, Nov 30, 2012 at 9:47 AM, Fernando Nasser fnas...@redhat.com wrote: Hi, Why are you creating these directories in %post in the firs place? If you create them in %install (empty) and own them regularly in %file and do the same on the other packages that install thins on it, they will be properly removed when the last RPM that owns them go away. Regards, Fernando - Original Message - From: Mark Bidewell mbide...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Friday, November 30, 2012 9:11:54 AM Subject: Yum Package Remove Order I have been working on packaging software into RPMs for my company. These RPMs create directories in %post into which dependent RPMs install components. If I yum remove the main package it will be erased first by yum prior to erasing the dependent packages. When the uninstall scripts for the dependent packages run, they may fail due to files and directories being missing that they expect from the main package leaving things in an inconsistent state. Is this a bug or known behavior we need to account for in some way? Thanks. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- 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 I was not aware of %install(empty) where can I find some documentation? Thanks -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New release cycle proposal (was Rolling release model philosophy (was ...))
oddly this looks a lot like the Ubuntu release cycle if you replace stable with LTS On Tue, Nov 6, 2012 at 2:16 PM, Jason Brooks jbro...@redhat.com wrote: On 11/06/2012 10:55 AM, Matthieu Gautier wrote: No, I never suggest that. Preview versions have a timelife of 6mo instead of 12. Stable version have a lifetime of 24mo (12mo for regular updates) instead of 12. The cycle would have to go: stable, preview, preview, stable, and so on to avoid maintaining more than two releases at a time. If it went back and forth between stable and preview, you'd have three supported releases at once in the second half of year two. Regards, Matthieu Gautier How about NO? https://gs1.wac.edgecastcdn.**net/8019B6/data.tumblr.com/** tumblr_mbfshfloal1rpdotto1_**1280.jpghttps://gs1.wac.edgecastcdn.net/8019B6/data.tumblr.com/tumblr_mbfshfloal1rpdotto1_1280.jpg -- @jasonbrooks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: changing development cycle
I like this idea, it would also allow the introduction of things like newer versions of Libreoffice, KDE, GNOME faster than potentially breaking changes. On Mon, Nov 5, 2012 at 8:27 AM, Paolo Leoni ulixe...@yahoo.it wrote: You can find the same proposal scheme using this link (in order to avoid mail formatting issues): http://www.paololeoni.eu/fedora_proposal.jpg bye, Paolo 2012/11/5 Paolo Leoni ulixe...@yahoo.it Hi, I'm a Fedora user and, occasionally, contributor. I'm writing to you only to expose a simple proposal on Fedora future. We are debating on how Fedora Development cycle could be improved, and, at the same time, how to maintain its bleeding edge way. So, this is my proposal: We could introduce a periodically different Fedora development cycle, with major and minor release numbers. When we want release a new major version, we have a development cycle pretty longer, e.g. one year. For the minor release we have the old development cycle: 6 months. The minor release that come before the major release could have a life cycle with a lenght of 18 months, to compensate the longer devel cycle of the next major release. The time to begin development of a major released could be discussed and decided by FESCo. This is a simple graphical concept of the proposal: || = 6 months of distribution development || = 6 months of distribution stable life Fedora 17.8 ||--|--| Fedora 17.9 |~|--|--|--| Fedora 18.0 (e.g.: introducing new anaconda...) |~|~|--|--| Fedora 18.1 |~|--|--| Fedora 18.2 |~|--|--| .. How do you think? Regards, Paolo Leoni ~ www.paololeoni.eu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17 Beta Observations
So it looks for the VMWare 'vmwgfx' driver and it's not there (I'm not sure if that driver is something Fedora would be expected to include, or if it's a 'guest additions' kind of thing). Then it falls back on 'vmwlegacy', which promptly blows up. ajax, airlied, are we expecting this 'vmwlegacy' driver to work, or should it be suppressed in favour of vesa or something? -- 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 Given that installing GNOME desktop and Base X via yum yields a functioning desktop, I would assume that the driver is included with Fedora. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Release name voting and Poll for whether to continue naming releases
On Fri, Apr 20, 2012 at 6:33 PM, Matej Cepl mc...@redhat.com wrote: On 20.4.2012 18:09, Ralf Corsepius wrote: Never. Nobody uses the code names. It's a waste of time and choosing names like Beefy Miracle is a good way of making the distro look a whole lot less professional. Well, as far as I can tell, many Ubuntu and Debian users prefer to call their release by name. Yes, and I wonder why Fedora users just don't it. Nobody knows why, either we have too stupid names, or we are too geeky, or something. And I have to admit, that although my first Debian was potato and I have switched to Fedora just before etch (and I have no idea, what was the number of these releases), I have never felt the smallest inclination to call my first Fedora distro anything else than Fedora Core 6. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel I think it has as much to do with the names as anything else. Ubuntu names are short and easy. Fedora names tend to be more obscure Lucid or Precise makes more sense than Zod or Beefy (forget the fat distro connotation...). Also the Ubuntu pattern is clear and wellknown (Adjective and animal name). I am still not sure how we got from Superman's nemesis to hot dogs (at least I think that is where beefy miracle came from...). -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Release name voting and Poll for whether to continue naming releases
I am still not sure how we got from Superman's nemesis to hot dogs (at least I think that is where beefy miracle came from...). I didn't know Jules Verne was superman's nemesis. -- Regards, Frank Jack of all, fubars -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel Verne wasn't Zod was. However, given that each name has a relationship to the one before, there is a linkage. But to your point Jules Verne - Hot dogs? Not exactly clear. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17 Beta Observations
OK, so Mark, it looks like we need you to file a bug on the segfault you hit when trying to run anaconda with the vmwlegacy driver (as long as I'm interpreting the log right). Can you do that and link to the bug? 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 The bug is reported here: https://bugzilla.redhat.com/show_bug.cgi?id=815467 -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17 Beta Observations
On Wed, Apr 18, 2012 at 9:23 AM, Mark Bidewell mbide...@gmail.com wrote: On Wed, Apr 18, 2012 at 9:15 AM, Paul Wouters pwout...@redhat.com wrote: On Wed, 18 Apr 2012, Mark Bidewell wrote: However, no GUI for installation is less than userfriendly did you give the VM 768MB or more RAM? It might not really need it anymore, but last I checked Anaconda checked for it before switching into gui install mode. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel I will double check although I think the default is 1GB. -- Mark Bidewell http://www.linkedin.com/in/markbidewell The VM I used had 1GB of memory. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17 Beta Observations
On Thu, Apr 19, 2012 at 2:23 PM, Adam Williamson awill...@redhat.comwrote: On Thu, 2012-04-19 at 07:29 -0400, Mark Bidewell wrote: The VM I used had 1GB of memory. It's pretty much impossible for us to just guess why the installer drops to text mode. You should be able to get X logs from the installer environment; boot the installer, go to alt-f2, and poke around in /var/log and /tmp . Does the 'basic graphics mode' option 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 OK, dug into the logs, at the tail end of the X.log file is a Seg Fault loading. I am attaching the X.log file. Basic graphics mode does work, however the buttons along the bottom are not visible. -- Mark Bidewell http://www.linkedin.com/in/markbidewell X.log Description: Binary data -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 17 Beta Observations
After trying the F17 Alpha with no success, I tried the F17 Beta. I installed in the VMWare Fusion Technical Preview (which supports Linux 3D Graphics). On install I was dumped into the text installer which installed a basic 211 package installation. Improved from the Alpha is that I could get a working X install by installing the X and GNOME package groups. However, no GUI for installation is less than userfriendly and given that it worked once the packages were installed it should work for Anaconda. Also, I was surprised by the slim set of command line tools installed by the text install (no 'less'). -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17 Beta Observations
On Wed, Apr 18, 2012 at 9:15 AM, Paul Wouters pwout...@redhat.com wrote: On Wed, 18 Apr 2012, Mark Bidewell wrote: However, no GUI for installation is less than userfriendly did you give the VM 768MB or more RAM? It might not really need it anymore, but last I checked Anaconda checked for it before switching into gui install mode. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel I will double check although I think the default is 1GB. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 Alpha and VMWare Fusion
I tried the i686 DVD (haven't tried the live cd yet), On install I got a text installer that installed a minimal system (191 packages - no options). It did boot, but after installing KDE and X via yum, startx failed. On Tue, Mar 6, 2012 at 9:51 AM, Martin Stransky stran...@redhat.com wrote: Try i686 iso, the x86_64 is broken. On 03/06/2012 03:43 PM, Mark Bidewell wrote: Last night I attempted an install of F17 Alpha on VMWare Fusion. 1) My first attempt was using the install DVD. I was redirected into a text installer, I was not prompted to select packages. The resulting install hard lock starting SSH 2) Trying the KDE LiveCD froze during boot (don't know on what since the boot screen was up). Has anyone else seen this? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F17 Alpha and VMWare Fusion
Last night I attempted an install of F17 Alpha on VMWare Fusion. 1) My first attempt was using the install DVD. I was redirected into a text installer, I was not prompted to select packages. The resulting install hard lock starting SSH 2) Trying the KDE LiveCD froze during boot (don't know on what since the boot screen was up). Has anyone else seen this? -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 Alpha and VMWare Fusion
On Tue, Mar 6, 2012 at 9:51 AM, Martin Stransky stran...@redhat.com wrote: Try i686 iso, the x86_64 is broken. On 03/06/2012 03:43 PM, Mark Bidewell wrote: Last night I attempted an install of F17 Alpha on VMWare Fusion. 1) My first attempt was using the install DVD. I was redirected into a text installer, I was not prompted to select packages. The resulting install hard lock starting SSH 2) Trying the KDE LiveCD froze during boot (don't know on what since the boot screen was up). Has anyone else seen this? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel Thanks, will do. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Torvalds:requiring root password for mundane things is moronic
On Wed, Feb 29, 2012 at 7:36 AM, Emanuel Rietveld codehot...@gmail.comwrote: On 02/29/2012 01:15 PM, drago01 wrote: On Wed, Feb 29, 2012 at 1:02 PM, Neal Beckerndbeck...@gmail.com wrote: I think he's got a point http://www.osnews.com/story/**25659/Torvalds_requiring_root_** password_for_mundane_things_**is_quot_moronic_quot_http://www.osnews.com/story/25659/Torvalds_requiring_root_password_for_mundane_things_is_quot_moronic_quot_ Yeah but last time we tried this in fedora it got flamefested so we had to revert. Perhaps a solution is adding a group with the needed permissions and make it really easy to add an account to that group. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel +1 to this. Many tasks should not require full root permissions to execute. Having a set of groups centered around tasks (install printers, install software, etc.) would definitely make this simpler. This method would also be arguably be more secure than sudo as processes don't run with root permission therefore root privileged cannot be gained by exploiting a program. Another situation where having a group based security would be nice is access to privileged ports. Try running JBoss as a non-root user on port 80. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Apple will use LLVM
On Thu, Feb 16, 2012 at 11:08 AM, Gregory Maxwell gmaxw...@gmail.com wrote: On Thu, Feb 16, 2012 at 10:25 AM, Vladimir Makarov vmaka...@redhat.com wrote: GCC has a big community of very dedicated people. LLVM has no such community. So IMHO GCC will be more high quality compiler than LLVM until LLVM gets such community. That can't be expected to continue now that there are many employers hiring people and forbidding them from working on GCC, even in their own time, while permitting them to work on LLVM. I'm not just spreading sour news for the sake of it, here is an example of where I ran into this impeding a GCC crash bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50335#c8 (Though it will be quite ironic when LLVM becomes unusable to everyone because the we don't give up our patent rights for this when we contribute to it turns it into a thicket) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel In addition, FreeBSD is working to ensure that the base system can be compiled without gcc so that will add to the community. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux Questions Desktop Environment of the Year - interesting result
On Sun, Feb 12, 2012 at 7:12 PM, Kevin Kofler kevin.kof...@chello.at wrote: Genes MailLists wrote: While it may make sense to make KDE the default DE for fedora - I suspect that this cannot happen in fedora due to pressures from the large number of gnome devs associated with Fedora - or could it? Should it? IMHO, not only should the KDE spin become the default, but the Xfce spin should replace the GNOME spin (which of course needs to stop calling itself the Desktop spin) on the mirrors. GNOME is no longer a major desktop! Xfce is now the second most popular desktop after KDE Plasma Desktop. I wonder if moving Gnome shell as a tablet spin and making KDE the default laptop/desktop DE would have been a really smart move. Is it too late? Perhaps we all really want a phone DE on our 42 inch desktops with a touch screen that somehow doesn't cause muscle strain ... For a tablet spin, Plasma Active makes a lot more sense than gnome-shell: http://plasma-active.org/ https://fedoraproject.org/wiki/Features/PlasmaActive Plasma Active is actually designed for tablets, whereas the gnome-shell developers denied on more than one occasion that tablets were their intended target, even though its bizarre design happens to work out better for tablets than for normal computers. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel The confusion in the Linux Desktop space was a big reason why I jumped from Fedora to a Mac. I love KDE and it would be a great default, I just wish that the decision hadn't been made to develop KDE in such a way as to push the graphics envelope. While I realize by Dell B130 is old, I should be able to drag a window around without artifacts (with or win out compositing. Ubuntu's Unity run the best. I feel that a lot of effort is being put into bling for bling's sake. On my Mac most of the bling enhances usability. I wish KDE didn't use 5-10% of my CPU at idle. IMO, the DE should attempt to consume as few resources as possible. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Changes to the Packaging Guidelines
On Tue, Feb 7, 2012 at 1:25 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2012-02-07 at 13:51 +0530, Rahul Sundaram wrote: On Tue, Feb 7, 2012 at 12:38 PM, Bohuslav Kabrda bkab...@redhat.com wrote: Again, citing FHS: Distributions may install software in /opt, but must not modify or delete software installed by the local system administrator without the assent of the local system administrator. How can this be interpreted as non-OS vendor supplied? This is one of many places in which FHS is vague but that's the common interpretation all distributions rely on Um. Really? Wasn't there a distro - I'm thinking SUSE? - that installed KDE in /opt for a long time? -- 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 Suse is technically closer to the original intent of the filesystem hierarchy standard. /usr/bin is for non-critical system binaries (on some Unix installations, /usr/bin is mounted readonly via NFS). /usr/local and /opt would then be used to hold optional packages. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The question of rolling release?
I just had a conversation which I believe sheds some light on the problem which a rolling release is trying to solve. The example is Ubuntu bu you could apply the same to Fedora/RHEL. My coworker wants to use Ubuntu LTS for development on Heroku. He wants the stability of an LTS, but he needs a later version of Ruby to run the Heroku tools. He has found that there is not supported way to upgrade Ruby short of recompiling Ruby or upgrading his entire system. Because of this he has returned to developing on OS X which handles the Ruby upgrade. I understand the cry of what about dependencies? However, if Linux is to succeed we need to be able to be able to work with cases like this one which OS X are fine with i.e. where only one or two packages out of an entire system need to be upgraded leaving the rest of the system alone. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The question of rolling release?
On Thu, Jan 26, 2012 at 12:37 PM, Frank Murphy frankl...@gmail.com wrote: On 26/01/12 17:15, Mark Bidewell wrote: My coworker wants to use Ubuntu LTS for development on Heroku. He wants the stability of an LTS, but he needs a later version of Ruby to run the Heroku tools. He has found that there is not supported way to upgrade Ruby short of recompiling Ruby or upgrading his entire system. Because of this he has returned to developing on OS X which handles the Ruby upgrade. Supported by Fedora or Ruby? -- Regards, Frank Murphy, friend of fedoraproject UTF_8 Encoded -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Since he was using Ubuntu I will say distro-supported, but if he was using Fedora it would be Fedora supported. Ruby does not maintain distro specific packages. Ubuntu has PPAs but these are somewhat spotty for some software. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The question of rolling release?
On Thu, Jan 26, 2012 at 12:49 PM, Frank Murphy frankl...@gmail.com wrote: On 26/01/12 17:43, Mark Bidewell wrote: Since he was using Ubuntu I will say distro-supported, but if he was using Fedora it would be Fedora supported. Ruby does not maintain distro specific packages. Ubuntu has PPAs but these are somewhat spotty for some software. Sorry, I meant if he wasn't worried about Fedora supporting his Ruby. He could have used rvm to keep updated. ditto Ubuntu. -- Regards, Frank Murphy, friend of fedoraproject UTF_8 Encoded -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel I will look at rvm. thanks -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The question of rolling release?
On Thu, Jan 26, 2012 at 12:51 PM, Kevin Fenzi ke...@scrye.com wrote: On Thu, 26 Jan 2012 12:15:01 -0500 Mark Bidewell mbide...@gmail.com wrote: I just had a conversation which I believe sheds some light on the problem which a rolling release is trying to solve. The example is Ubuntu bu you could apply the same to Fedora/RHEL. My coworker wants to use Ubuntu LTS for development on Heroku. He wants the stability of an LTS, but he needs a later version of Ruby to run the Heroku tools. He has found that there is not supported way to upgrade Ruby short of recompiling Ruby or upgrading his entire system. Because of this he has returned to developing on OS X which handles the Ruby upgrade. ...snip... This is the age old LTS 'use case'. I want: * A super stable platform. * Backporting security fixes only and tons of testing and care. * Minimal updates, only the backported security fixes after massive testing. oh, and: * The very latest git head of php, python, ruby, or some other very very specific component. The problem here is that these are opposite goals. And they are also exclusive... ie, I might want the very latest php and nothing else, but $otheruser may want stable php but the latest ruby. It's hard to win here. ;) kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel I understand the difficulty, but facilitating some degree of flexibility would be a big usability improvement. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The question of rolling release?
On Thu, Jan 26, 2012 at 1:12 PM, drago01 drag...@gmail.com wrote: On Thu, Jan 26, 2012 at 6:15 PM, Mark Bidewell mbide...@gmail.com wrote: I just had a conversation which I believe sheds some light on the problem which a rolling release is trying to solve. You didn't state how a rolling release would solve that (it wouldn't). This is really a package management issue. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel A rolling or semi-rolling release would make the most recent packages available in some way. With careful updating a minimum Ruby upgrade could be accomplished. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The question of rolling release?
I have used Fedora, Ubuntu, and Arch. I believe the ideal is a combination of the three 1) A pure rolling release like Arch, upgrades packages when they are stable without regard to external impacts. The early adoption of Python 3 in Arch broke many packages and took awhile to fix. 2) Ubuntu has 6 month releases and 2 year LTS releases. PPAs allow upgrading of some packages without touching the core system. 3) Fedora gives rapid shipping of latest packages. In my mind an ideal linux distro would break up the package set into: 1) User - These are packages that users want rapid access to the latest (Examples Firefox, Libreoffice) 2) System - These are packages that better be stable and working without external breakage before being pushed but still readily available (Examples: X11, KDE, GNOME, XFCE, Perl, Python). 3) Core - These packages represent the base system needed to operate these packages should move with utmost caution (Examples: kernel, gcc, glibc, shell). A somewhat stable kernel ABI would help, but that is not happening. Recommended Cycles for major upgrades for each group: 1) User - As soon as possible. 2) System - 6 months. 3) Core - 12-18 months. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The question of rolling release?
On Tue, Jan 24, 2012 at 10:03 AM, Rahul Sundaram methe...@gmail.com wrote: On 01/24/2012 08:21 PM, Mark Bidewell wrote: Recommended Cycles for major upgrades for each group: 1) User - As soon as possible. 2) System - 6 months. 3) Core - 12-18 months. Problem is that, it is often the case that 1) requires updates in 2) and sometimes even 3) Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Hence why I wish there was some commitment to ABI stability :-(. However, I don't think the situation is as dire as you suggest. for the following reasons: 1) I don't think that many changes in the user section would rely heavily on new libraries. (Firefox 9 and Libreoffice both run fine on Ubuntu 10.04 LTS which is almost 2 years old). 2) If a User package does require system changes the the upgrade waits to the next system release (This is the current Fedora model). 3) If a package needed changes to all three (I can't think of an example KVM maybe). Then a release could be cut with everything at the latest/required versions. Interested users could upgrade, the remainder would be brought current at the next core release. The big idea behind what I propose is that package upgrades need to be differentiated based on the potential for disruption. An upgrade to libreoffice is less disruptive than a kernel upgrade and an upgrade to Gnome is more disruptive than a libreoffice upgrade. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security updates for Firefox 4 in F-15
For me the most important benefit is OS independent software, especially web browser. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Debates like this expose a weakness in packaging philosophy. The current philosophy seems to be all packages are equal. An update to Open/Libre Office is handled the same as an update to the kernel or glibc. It seems like in mainstream Linux distros your options often are: 1) Wait 6 months for new software. 2) Download / build from source and deal with system integration issues. 3) Download unofficial package. The reality is that not all packages are equal, and some could/should be pushed faster than others. Firefox and Libreoffice are good examples of this. If parallel installs of Xulrunner are needed, in my opinion, so be it. Ultimately, packaging philosophy could hold back/prevent mainstream (i.e. non power user) Linux adoption. These users will ask themselves I can get the latest version well integrated on release day using Windows or Mac, why not Linux?. Ubuntu is moving (once again in my opinion) in the correct direction with its combination of LTS (a stable base) and PPAs for more rapid updates of things like Firefox. The fact that they have LTS tagging also prevents the question of How many versions to support?. The answer is clear: two, the current LTS and the latest 6 month release. Finally, with packaging cycles changing might it be time to revisit the decision to merge Fedora Core and Extras? Creating separate repos with different goals might be wise. I apologize for the long rant. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
Why are people choosing it over other solutions, and what can we change in qemu/kvm to get users using that instead ? Dave 1. Easy setup of networking (bridged). 2. Support decent graphics mode in guests. (After installing guest additions, a winxp guest on fedora host can run in any graphics resolution. I don't think qemu/kvm does this). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel To add to the point about graphics support there is also the fact that GNOME3/Unity will only run with accelerated graphics which only VirtualBox supports. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
mandb behavior
I was working with CentOS 5 and I was noticing some what appear to be functional regressions in F14 mandb: 1) In the centos configuration you can specify manpaths with wildcard expansions. Example: /opt/*/man would specify all man subdirectories in /opt. In F14 this no longer works. 2) In F14, directories specified in the MANPATH environment variable seem to be ignored. Are these intended? Thanks -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
Out of interest, do you use individual shells/terms or something that provides a more remote desktop like experience? I use ssh -Y. Anything that sits in a huge window showing an entire desktop-in-a-desktop is so obviously the wrong way to do it, from both a usability and efficiency perspective, that I'm just astonished that people suggest I use something like VNC. We use both approaches, I suppose both have their merits, and we shouldn't rule out either method of working. -Cam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel One of the many concerns I have with Wayland involves VNC. Right now VNC on X uses some of the multiuser functions to enable multiple VNC consoles. Will Wayland still allow for this or will we be back to Windows with only one VNC session per computer. Linux/Unix is designed around multiuser/multisession, I believe we would be amiss to remove those capabilities from the OS. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
i686/x86_64 dual install media
Sorry if this has been discussed, but has there every been discussion of a dual 32/64-bit install media? I realize that the default package selection would be reduced but with a high speed connection it shouldn't be too big of an issue. Having a single ISO for both my 64-bit desktop and 32-bit laptop would be quite nice. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: clutter on F13 - nvidia graphics card
On Wed, May 12, 2010 at 8:18 AM, Ankur Sinha sanjay.an...@gmail.com wrote: hey, I'm using pyclutter to develop an app. It worked perfectly on F12, on nouveau. The same code is failing on F13 with segfaults. Any pointers to debugging this? I don't think it's a clutter issue since the program works on my colleague's machine which features intel graphics. Could someone please tell me what the status of support for clutter on nvidia cards in F13 is? Does nouveau support composting or whatever it is needed for clutter? I'd like to learn more on the subject so any links etc. would really be helpful. I would like to offer my machine for testing too here. Thanks and regards, Ankur -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel I don't know if this helps but here is a thread on gnome-games (uses clutter) issues: http://lists.fedoraproject.org/pipermail/devel/2010-April/134957.html -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Therefore, I will stay in office until the end of my term, but I will not be available for reelection. I would like to thank the people who voted for me last year for their support and apologize to those who would have liked to vote for me this time for not giving them this opportunity. If you would like a KDE SIG person in FESCo, vote for Steven M. Parrish (and vote for Rex Dieter for the Board). But if you want to see the kind of change to FESCo I'd like to see, it'll take a faction of at least 5 people to make it happen. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel I'm sorry to hear this as well. Fedora KDE has made great strides and is in my opinion the premiere KDE distro. Thanks for your work! -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Gnome Games Clutter/OpenGL issues
I have been dealing with this issue in the context of Ubuntu Lucid, however since it can be reproduced under F13 Beta I thought it would be wise to raise it here. In some cases, gnome-games do not properly fall back to software rendering and fail to start. This bug happens reliably with KVM and VirtualBox but has been reported on real HW. The bugs are: https://bugzilla.gnome.org/show_bug.cgi?id=615630 https://bugs.launchpad.net/bugs/561734 -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gnome Games Clutter/OpenGL issues
On Tue, Apr 20, 2010 at 1:52 PM, Jeff Spaleta jspal...@gmail.com wrote: On Tue, Apr 20, 2010 at 9:32 AM, drago01 drag...@gmail.com wrote: Clutter is not targeting mesa's software rastersizer ... so clutter upstream do not really care if it works without any hardware support or not. Which is all fine for an optional component gnome-shell which explicitly states it targets hardware accelerated graphics only. But should be be putting clutter based apps into the default packageset for the desktop in F13 if they don't fallback gracefully for unaccelerated graphics? We haven't stated that accelerated hardware will be a minimum requirement in F13 have we? I know its coming, but we haven't actually crossed that line yet. If we can't get this working with software rendering as a fallback...perhaps we jettison this game from the default packageset and move it over to gnome-games-extra. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Quadrapassel is in gnome-games-extra. One interesting note I will try to get more details on. is that some are reporting the bug when using nouveau (which I assumed was accelerated). -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
