Re: F20 Beta upgrade issues - network status gone
On Wed, 13 Nov 2013 17:58:27 -0800 Adam Williamson awill...@redhat.com wrote: On Wed, 2013-11-13 at 18:44 -0600, Michael Ekstrand wrote: I just upgraded my laptop from F19 to F20 Beta, using fedup, and encountered 2 noticeable problems with the upgrade process that I'm not sure where/how to correctly report: - Upon update, nm-applet was gone and my gnome-shell status area had no network status or control. Installing network-manager-applet brought it back. I had a working network status display prior to upgrade. Assuming you have a straightforward wired connection, this is not a bug. See the discussion in https://bugzilla.redhat.com/show_bug.cgi?id=1005719 starting around comment #13. It's a wireless connection; before re-installing network-manager-applet, the integrated status menu didn't have anything to say about networking, so I couldn't check or make sure I was connected to the wireless. It seems like this is an issue in packaging somehow, that fedup didn't know to install network-manager-applet. Or maybe that fix was not the way it's supposed to be fixed - I just did that because I had remembered from previous versions of gnome-shell that the network controls operated by controlling nm-applet. - I don't have any Bluetooth status or display in gnome-shell now. I did previously. I do not know what I need to install or tweak to get it back, or where to report it. I'm not as sure about this one, but it's probably the same thing: no 'status' will be displayed unless there's something useful to display (like a paired device). Yep, pairing a device makes it show up. -- Michael Ekstrand — http://elehack.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: F20 Beta upgrade issues - network status gone
On Thu, 14 Nov 2013 07:41:20 -0600 Michael Ekstrand mich...@elehack.net wrote: On Wed, 13 Nov 2013 17:58:27 -0800 Adam Williamson awill...@redhat.com wrote: On Wed, 2013-11-13 at 18:44 -0600, Michael Ekstrand wrote: I just upgraded my laptop from F19 to F20 Beta, using fedup, and encountered 2 noticeable problems with the upgrade process that I'm not sure where/how to correctly report: - Upon update, nm-applet was gone and my gnome-shell status area had no network status or control. Installing network-manager-applet brought it back. I had a working network status display prior to upgrade. Assuming you have a straightforward wired connection, this is not a bug. See the discussion in https://bugzilla.redhat.com/show_bug.cgi?id=1005719 starting around comment #13. It's a wireless connection; before re-installing network-manager-applet, the integrated status menu didn't have anything to say about networking, so I couldn't check or make sure I was connected to the wireless. It seems like this is an issue in packaging somehow, that fedup didn't know to install network-manager-applet. Or maybe that fix was not the way it's supposed to be fixed - I just did that because I had remembered from previous versions of gnome-shell that the network controls operated by controlling nm-applet. I just uninstalled network-manager-applet, restarted my session, and I do have network controls now. So it looks like things do work, although I do not know why I did not have network controls when I first logged in after the upgrade. -- Michael Ekstrand — http://elehack.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
F20 Beta upgrade issues - network status gone
I just upgraded my laptop from F19 to F20 Beta, using fedup, and encountered 2 noticeable problems with the upgrade process that I'm not sure where/how to correctly report: - Upon update, nm-applet was gone and my gnome-shell status area had no network status or control. Installing network-manager-applet brought it back. I had a working network status display prior to upgrade. - I don't have any Bluetooth status or display in gnome-shell now. I did previously. I do not know what I need to install or tweak to get it back, or where to report it. So (A) where should I direct these reports (I do not know what component is responsible for nm-applet disappearing, or what is responsible for the Bluetooth status display in the first place), and (B) how do I get my Bluetooth status back? - Michael -- Michael Ekstrand — http://elehack.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: $HOME/.local/bin in $PATH
On Mon, 28 Oct 2013 19:51:06 +0100 Michael Schwendt mschwe...@gmail.com wrote: On Mon, 28 Oct 2013 19:44:23 +0100, Alec Leamas wrote: Deja vú: https://lists.fedoraproject.org/pipermail/devel/2011-July/154896.html Hah! A thread of doom. [...] Does any software store files into $HOME/.local/bin/ yet? Yes. pip install --user some python package The pip user scheme is to use ~/.local as an FHS-ish thing. IMO, this is much superior to the cabal, gem, etc. notion that they should each have their own bin directory for user-installed programs. - Michael -- Michael Ekstrand — http://elehack.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: $HOME/.local/bin in $PATH
On Mon, 28 Oct 2013 20:30:05 + Sérgio Basto ser...@serjux.com wrote: On Seg, 2013-10-28 at 14:00 -0500, Michael Ekstrand wrote: Does any software store files into $HOME/.local/bin/ yet? Yes. pip install --user some python package The pip user scheme is to use ~/.local as an FHS-ish thing. IMO, this is much superior to the cabal, gem, etc. notion that they should each have their own bin directory for user-installed programs. Hi, I have pip in Debian servers (old and new release) and in Fedora, and don't find any .local/bin So my argument is more , nobody and noapp put things in ~/.local/bin Fedora 19: $ pip install --user --upgrade mercurial $ ls ~/.local/bin/hg /home/michael/.local/bin/hg So, if you use 'pip install --user' to install a Python module that provides scripts/executables, it will by default put those executables in ~/.local/bin. and where is xdg recommendation to use .local/bin ? I goggling it and don't find any reference to that . I don't know where, if anywhere, this behavior is specified. It's just what the Python package installation tools do. I haven't seen any other program do this, for better or worse. - Michael -- Michael Ekstrand — http://elehack.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: Software Management call for RFEs
On 05/28/2013 06:25 AM, Mathieu Bridon wrote: On Tue, 2013-05-28 at 13:14 +0200, Miroslav Suchý wrote: On 05/22/2013 03:43 PM, Jan Zelený wrote: Please send your requests as replies to this email so they can be properly discussed. Have equivalent of apt-get autoremove. That's what yum-plugin-remove-with-leaves does. Almost, but not quite (it must be done when you remove the package, can't be done after). The clean_requirements_on_remove=1 setting is also helpful, like 'autoremove' after each 'remove'. Still can't be done after-the-fact, but is nice (and more accurate, AFAIK, since it uses the yumdb 'reason' tag). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On 05/23/2013 06:21 AM, Jan Zelený wrote: On 22. 5. 2013 at 10:55:14, Michael Ekstrand wrote: Performance improvement: improve scaling to 5K+ installed packages. Since the TeXLive repackaging, my laptop several thousand packages, about half of which are TeX-related (I like to have a fairly full TeX install with all the docs). There are two noticable problems: yum slows down considerably (esp. in transaction check operations), and PackageKit can't handle upgrades of more than 2500 packages at a time. Well, PackageKit is already out of our scope but I will talk to Richard about this. OK. Relevant bug report: https://bugzilla.redhat.com/show_bug.cgi?id=894731 On the rpm side - we are already working on that On the yum side - have you tried dnf? It should handle this much better. Not yet. I plan to upgrade my laptop to F19 sometime in the beta or RC time frame, and was thinking of trying dnf then. - Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
Performance improvement: improve scaling to 5K+ installed packages. Since the TeXLive repackaging, my laptop several thousand packages, about half of which are TeX-related (I like to have a fairly full TeX install with all the docs). There are two noticable problems: yum slows down considerably (esp. in transaction check operations), and PackageKit can't handle upgrades of more than 2500 packages at a time. - Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
On 01/30/2013 07:57 AM, François Cami wrote: Hello, On Wed, Jan 30, 2013 at 1:44 PM, Jaroslav Reznik jrez...@redhat.com wrote: = Features/ApacheOpenOffice = https://fedoraproject.org/wiki/Features/ApacheOpenOffice Feature owner(s): Andrea Pescetti pesce...@apache.org Add Apache OpenOffice, the free productivity suite, to Fedora. == Detailed description == Apache OpenOffice (formerly OpenOffice.org) is the the leading free and open- source office software suite. I would object to the use of the word leading there, merely on subjective grounds. +1. I don't at all object to having Apache OpenOffice available again, if people want it, but I am skeptical about marketing it as leading. If that can be objectively demonstrated by some metric (it may well surpass LibreOffice counting Windows downloads, I do not know), then the language can stay. But repeating unproven assertions of fact in feature marketing and messaging does not seem to me to be a good idea. - Michael -- 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 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. I wouldn't at all mind even seeing multiple packaging systems at work - RPM manages the core system, and something like PC-BSD's PBIs used for “applications”. But it does seem unlikely to ever happen, at least in the context of an existing distribution. - Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy
On 11/02/2012 04:53 PM, Tom Lane wrote: Adam Williamson awill...@redhat.com writes: On Fri, 2012-11-02 at 21:07 +0100, drago01 wrote: I disagree with that. Fedora releases had some small regression introduced via updates from time but is is *very* usable as a stable operating system. I disagree. It's usable by the kind of people who use Fedora. Uh, no. What you describe is usable by the kind of people who use rawhide. Which is what, 1% of our user base? If that. Abandoning any pretense of having stable releases will eliminate a huge fraction of the user community. For sure it will eliminate *me*. I'm not in the business of fighting OS bugs every single day, and I will not be forced into that business. I have other things that I'm more productive at. +1. One of the major reasons I came to Fedora (after a long tour that took me through Slackware, Gentoo, Debian Testing, Ubuntu, with brief stints elsewhere) is that it has releases. Real releases, with most major changes happening with the new release. I ran Debian Testing for several years, and encountered a problem. I was spending too time paying attention to changes and new software developments, and when they might hit my system, at the expense of getting work done. It's purely selfish, my psychology, etc., but I personally basically need a release, so I can batch up all my ooh, what's this shiny new thing? tendencies in a few days twice a year, rather than an hour here and an hour there. Having used Fedora now since F15, I've personally found the releases to be quite reliable and usable, with just enough software updating over their lifecycle to keep my laptop rather comfortable. And better than my brief previous Fedora experience back around F9, when every other kernel update broke my wireless card[1]. Best, - Michael 1. Literally. Whether or not my wireless networking worked toggled with each kernel update with remarkable consistency. I'm glad things are better now. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/01/2012 01:24 PM, Matthew Garrett wrote: On Fri, Jun 01, 2012 at 02:16:45PM -0400, Gerry Reno wrote: Windows-8 will install/boot on existing hardware w/o SecureBoot. Yes. Will Windows-8 install/boot on new hardware that contains SecureBoot without SecureBoot enabled? Yes. Will OEM Windows 8 installs - requiring SecureBoot to be enabled as per logo requirements - boot on such hardware with SecureBoot disabled? Or will only retail/upgrade installs install on SecureBoot-capable but disabled hardware? - Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME 3 - font point sizes now scaled?
On 10/03/2011 10:48 AM, Camilo Mesias wrote: Hi, A daft question perhaps, but I thought... I'm not sure how we can make DPI magically be correct in gazillions of broken displays' EDID. How do other OS' do it? I don't know that they do. In my use of Windows up through XP, I never saw evidence of it re-scaling fonts based on DPI, at least for general UI use (word processors may do so). - Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what if native systemd service is slower than old sysvinit script?
On 09/15/2011 05:27 PM, Adam Williamson wrote: On Thu, 2011-09-15 at 14:14 -0400, Bernd Stramm wrote: Many computers are booted very rarely, once a day or so, and then sit idle for very long periods of time. This is very wasteful. The reason people do this is because booting takes a long time compared to starting the set of applications they use. If you could boot and start applications in say, 1/2 second, usage patterns would be completely different. What you really want there, though, is efficient and reliable suspend, not full power cycle. This is what everyone does with cellphones and tablets. Or bulletproof session management. With an encrypted disk, putting the data at rest is beneficial. Alternatively, hibernate could work if it were much faster, but my recent experience with hibernate is that a full boot is notably faster. Once everything is built on systemd units and it be parallelized... - Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
On 08/30/2011 06:30 PM, Chris Jones wrote: I see it all the time. Some older hardware still requires floppies... It just seems like a generic defense statement for the fans of floppies and for those who insist on using them for god knows what reason. Any hardware that is true to that statement must be at least 15 years old surely! And for the cheap price of PCs these days, whether it is building your own or grabbing an oem system, just upgrade to something that does have full usb support. I am not defending floppies - I think the current approach of ship the module, but don't load it by default is quite sensible - but there is an additional use case: perhaps the machine itself does not need floppies, but being able use it to prepare floppies for another machine that does (e.g. some old piece of electronics that can save data to floppy, a dedicated-use computer for running scientific experiments, etc.). - Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OpenBUGS program has a pre-compiled )S library from MS Windows. Any possibility to package it?
On 06/14/2011 07:41 PM, Kevin Kofler wrote: PS: Paul Johnson wrote: I was wondering if there could be an exception here, since the code is actually available and open. Have you even looked at that source code? I just have: 1. They refer to the Window$ download for the code. That's a .EXE file created with some proprietary installer generator (probably something that's part of that Black Box crap), 7z cannot do anything with it (and it can unpack at least self extractors and NSIS installers). Rather than running that EXE in WINE to get at the .odc files, I decided to look elsewhere, and in fact found their repository, but: I'm wanting to use BUGS myself, so I've spent some time today poking around at it. Here's a report on what I've found; it might help in future analysis or further work on making this software usable and available. They use Inno Setup for their installer, so it is proprietary in the sense that the format is not standardized, but Inno Setup is open source. Its source code has been used to write innounp[1], an unpacker for Inno Setup files. Unfortunately, Inno Setup and innounp are written in Delphi, so the usefulness diminishes at that point. However, it should be possible to construct a portable unpacker using the innounp sources as a reference, and it may even be possble to build them with FreePascal, depending on how much Delphi-specific stuff they use. Also, there is the cp-dev project[2] for building Component Pascal programs on Linux, but it seems to want plain text input (.cp rather than .odc) and also seems to require Black Box to bootstrap. I do not know if it is self-hosting after the initial bootstrap. So, a from-source build is still a ways off, but not necessarily entirely unfeasible. If cp-dev is self-hosting, license-clean[3], and capable of building OpenBUGS, is there a way to get it in to Fedora? It seems it would require running an initial pre-compiled binary, bootstrapped with Black Box, to then be able to recompile cp-dev from SRPMs and use the recompiled version to keep it up to date. There is still the issue of the lack of a free software viewer and editor for the .odc files, but that seems to be a separate issue from that of being able to re-build OpenBUGS with a completely free toolchain. It could be that OpenBUGS will forever need to live in third-party repositories. - Michael 1. http://innounp.sourceforge.net/ 2. http://cp-dev.sourceforge.net 3. cp-dev seems to not only use Black Box to bootstrap, but it also seems to use Black Box sources as a part of itself. I have not yet investigated whether this is true and, if true, how the relevant sources are licensed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OpenBUGS program has a pre-compiled )S library from MS Windows. Any possibility to package it?
On 08/26/2011 12:13 PM, Michael Ekstrand wrote: 3. cp-dev seems to not only use Black Box to bootstrap, but it also seems to use Black Box sources as a part of itself. I have not yet investigated whether this is true and, if true, how the relevant sources are licensed. BlackBox Component Builder's installation includes lots of source code and is licensed under what looks like the Sleepycat license (BSD + copyleft). So it looks like the build and packaging toolchain for OpenBUGS does consist of open source software, but this software is built for Windows, may depend on GUIs for launching and controlling the build, and has a nontrivial bootstrap process. - Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Calling autoconf in a spec.
On 07/15/2011 11:43 AM, Kevin Kofler wrote: Sam Varshavchik wrote: There's a big difference between having the upstream, who knows their configure script inside and out, That's a very bold assertion. ;-) Many upstream developers just copypaste their configure.ac scripts together from examples or other projects without understanding them. The current maintainer might also not be the developer who wrote the scripts (who is often the only one understanding them). Case in point: There are bazillions of projects testing for the existence of standard ANSI C89 / ISO C90 (not C99, C90!) functions (which have been available on every even remotely modern OS for decades) in their configure scripts, then just ignoring the results of the checks and just using memcpy etc. without a second thought (which makes sense because those are part of an ubiquitous, 23-year-old standard, but then checking for them in configure and defining unused HAVE_MEMCPY etc. booleans does NOT make sense). Likewise, projects routinely check for the existence of a Fortran compiler without even including a single line of Fortran. To be fair, a lot of this is ascribable to libtool (in the output, not in the configure.ac). If you use libtool (which most autotooled projects incorporating shared libraries do), the single line in configure.ac to activate and configure libtool performs a bunch of C checks and looks for the Fortran compiler (I've always assumed so that it can determine whether it can/should support Fortran libraries or client code, but have never verified this assumption). It could be better (e.g. looking whether AC_LANG_FORTRAN has been called and skipping Fortran otherwise), but using Libtool generates a lot of checks which the program itself likely doesn't use or respect. - Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trusted Boot in Fedora
On 06/24/2011 03:24 AM, Gregory Maxwell wrote: On Fri, Jun 24, 2011 at 4:07 AM, Rahul Sundaram methe...@gmail.com wrote: If you have *specific* concerns, let's hear those. You seem to just quoting parts of a public wiki page anyone can read. I don't see the point of that If trusted boot in fedora is widely deployed, then $random_things may demand I use a particular fedora kernel in order to access them. Both handcapping my personal freedom to tinker with my own computer by imposing new costs on it, and hampering the Fedora project by creating additional friction against upgrades. (Sorry, I can't upgrade to the new kernel to test that, because then I won't be able to watch netflicks!) Would it be possible or practical to ship tboot in Fedora with the user-serving protections enabled - verifying the kernel/initrd for secure disk encryption, for instance - but disabling remote attestation and similar features in the default configuration? If there's a way that I can harness the TPM to ensure the integrity of my boot path - and it is sufficiently transparent that I am confident of what it is doing, and can build and sign my own kernels if desired - I would be interested in that. However, I appreciate (and largely agree with) Gregory's concerns about being an enabler for a broader restricted computing ecosystem. - Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: conclusion: F15 / systemd / user-experience
On 06/13/2011 11:57 PM, Genes MailLists wrote: Fedora could well benefit from switching to a rolling release model as well (no not rawhide - a controlled rolling release much as the kernel development follows). I ran rolling release distros on my laptops for a while - Gentoo, then Debian Testing. I came to the conclusion about 3 years ago that, personally, a rolling release does not work for me, even though Debian Testing is very reliable. If I have a rolling release, I am regularly looking for what's new, trying it out, and tinkering with my system. This distracts me from getting my actual work done. Having real stable releases allows me to consolidate this exploration and tinkering in a week or two twice a year, and I can always source-install or backport the few applications where I do have a legit need for more recent versions (although 6 months is generally often enough for upgrading them). Now, this is just me and my psychology. But the 6-month release cycle is very good for me, and I think many people likely benefit from consolidating update adjustment into regular intervals. - Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Guide to setting karma thresholds?
I'm working on pushing my first bugfix to F15 (#711261), using the guides I found in the wiki[1][2]. For a non-critical-path package, the Update Policy says that it needs to meet the positive karma threshold set by the submitter, but does not indicate what that threshold should be or guidance for determining appropriate values. The default is 3; I'm assuming that leaving it there is a reasonable thing to do (and I won't be surprised if the 7-day criteria will be hit first for this package). However, I am still wondering: is there any guidance or policy published on how to determine appropriate karma thresholds? What justifies increasing or decreasing the thresholds? Userbase? Impact of change? Thank you, - Michael 1. https://fedoraproject.org/wiki/Updates_Policy 2. https://fedoraproject.org/wiki/Package_update_HOWTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Self Introduction
Greetings. I'm Michael, a Ph.D student in human-computer interaction at the University of Minnesota researching recommender systems (and working on an open source recommender toolkit). In my spare time I engage in recreational OCaml hacking (and use it whenever I can in my research work as well). I'm starting out helping fix some things on a couple existing OCaml packages. I'll be hanging around the ocaml-devel list and trying to be generally helpful there. - Michael Home page: http://elehack.net/michael/ Twitter: http://twitter.com/elehack IRC nick: elehack Jabber: same as e-mail address -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
