Re: Command line arguments depend on locale
Matthias Clasen writes: > Until you put a pipe between and turn the outputs of command a into > inputs of command b... People will generally be aware that output is locale-dependent. That is most of the point of having locales at all. Setting LC_ALL=C is not a nice option. That would mean that I have to redo all localization (translate the output) when I call it and intend to return the output to the user in the appropriate language. This is at best difficult. I also have to redo sorting and so on. All this so that people can use decimal comma instead of decimal point... Are there other decimal separators in use? Can we patch iputils to accept both comma and dot in all locales? /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Command line arguments depend on locale
Apparently ping has now started interpreting its command line arguments depending on locale. I.e. ping -i 0.1 no longer works in locales where comma is the decimal separator. This makes it difficult to call system commands. The only workaround is to set LC_ALL to a known-good locale, but then your users get no benefit from the translations of error messages and so on. Is Linux really doomed to repeat the mistakes made by Visual Basic more than a decade ago? /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Package Signature Checking During Installation
Adam Jackson writes: > For the same reason Firefox doesn't automatically accept self-signed SSL > certs, and the same reason that ssh doesn't automatically accept new > host keys: it'd be creating trust from thin air. I trust my hardware, I trust my firmware, I trust my install medium. That is not trust from thin air; the hardware is unlikely to be compromised and I verify the install medium. I cannot completely rule out firmware compromise, but if I have been hit by that I am owned already and likely will stay owned for years. I don't trust random mirrors on the Internet. Yet Anaconda somehow does. Despite the fact that it could easily grab the key off the trusted install medium and check the signatures. /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
Seth Vidal writes: > fantastic. show me a deployment somewhere of a 'thin client' that > doesn't use their own custom kickstart/pxe for instantiating the > clients and that will be relevant to this discussion. Is kickstart installs generally out of scope for minimal package set? The problem used to be that even with kickstart, you ended up with a too-large package set which you then had to rpm -e at the end. Awkward. This has gotten much better, of course. Personally I was hoping that the minimal project would end up making it possible, using kickstart, to install enough to get yum running. Ideally the size of that minimal install would be rather small. The users can always add more... If people want an actual functional system out of the box, it seems that they would be better off with one of the other installation choices. But anyway, if it is possible to prevent the installation of openssh-* in the kickstart file, that is ok with me. rpm -e afterwards, not so much. /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size
Josh Boyer writes: > It's not simple. It's not easy. It buys you very very little and it > leaves the maintainers having to continuously guess which package a > module goes into. Then there's the requests to move them from one to > the other. I certainly buy those arguments. The whole thing may be too much of a bother even though it does not mean recompiling anything. It IS quite a lot of work. The savings are quite substantial though. The modules currently loaded on my laptop take up 8MB of disk space, out of about 95MB of modules. It does not seem unreasonable to think that the modules needed for most virtualizated devices could fit in 10MB perhaps, which means a saving of 75MB. /Benny (By the way, I have Infiniband modules loaded, but alas the laptop seems rather lacking when it comes to Infiniband cards!?) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size
Josh Boyer writes: > Of course we would. The entire point is to reduce the size, and the > only way to reduce the size is to build it with different config > options. Just splitting off most modules would do the job I would think... Of course you can go smaller if you change config options, but that is a lot of work. Maintaining a list of core modules does not sound like an unbearable task. (Easy for me to say, of course). Then everything else under /lib/modules can go into a separate RPM. # rpm -ql kernel-3.6.1|grep ^/lib|xargs du -c 31488 total # du -s /lib/modules/3.6.1-1.fc17.x86_64/ 100324 /lib/modules/3.6.1-1.fc17.x86_64/ Making sure that the right systems get the extra module RPM is left as an exercise for the reader. /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
Lennart Poettering writes: > One way to achieve that should be to provide /var/log/README with the > appropriate hints, since I assume much more people will look for logs > in /var/log like it used to be in most of Linux history rather than in > a tool "logread" that is known by an embedded distro by the name of > OpenWRT... You do have a way with words. I did not propose logread because it is used by OpenWRT, I proposed it because it is a sane name. When I read logs, I do not want to control a journal, that is for tune2fs to do. And documentation in /var/log? Seriously? /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
Matthew Miller writes: > Less critical but important: A hard link to an easier-to-guess name like logread (used by OpenWRT)? /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
Tomasz Torcz writes: > Which is which? There are some example here: > http://tagoh.fedorapeople.org/tmp/hints/ > *-autohint variants are clearly blurred, while -*hintfull are eligible. As far as I can tell subpixel rendering is disabled in these examples. Is that relevant today, when almost all displays are LCD? /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
Sam Varshavchik writes: > It took me a while to figure out why my daemon kept breaking all the > time, when it couldn't stat its /proc/self/exe any more. Perhaps it's just me, but why would the daemon stat /proc/self/exe? I presume prelink writes a new file and renames into place as a proper Unix program should, which still leaves the original program intact on disk until the last open file descriptor referring to it is gone. /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
Jay Sulzberger writes: > If I understand correctly, Fedora has now formally allowed > Microsoft to lock Fedora out of many coming ARM devices. As I understand it, you have the freedom to purchase a $99 key from Microsoft which you can then use to install Fedora on those locked ARM devices designed for Windows 8. The current proposal is that Fedora does NOT spend the $99 on an ARM key, but any Fedora user could circumvent that. Admittedly most likely with a bit of annoying paperwork and key juggling. Hopefully the technical part would be made quite easy because it would be like the process for running self-signed on x86. Fedora also has the ability to change its collective mind at any time; if it is discovered that it makes more sense to sign Fedora ARM with a key from Microsoft, then Fedora has that option open. This whole business is leaving an awfully bad taste in my mouth but I have no ideas which are better than the original proposal. /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
Richard Hughes writes: > The async-message bus isn't the only problem. You *have* to restart a > process before it will be running a new library version. That mean > testing (and probably patching) every single application and daemon in > our stack Why testing the daemons? Any daemon which cannot be restarted by systemctl restart foo.daemon is broken already. > and working around this for the proprietary stuff we can't even see > the code for. That includes things like wine, mono, all the different > interpretors, and all the runtimes that we include in Fedora. Requiring a log out is ok IMHO, if there are processes in the session still having the old library mapped after the upgrade. If there are processes which are neither daemons nor part of a session, we should probably have a good look at why. /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
Richard Hughes writes: > It takes me 4 seconds to POST, boot the kernel, get into > system-update.service, and then reboot. Using a new rpm version, > applying several dozen test updates takes another 20 seconds. Your hardware is too cheap. BIOS boot time is proportional to price when the hardware was introduced. More generally, the fact that your hardware happens to boot fast does not mean that extra reboots are not a problem. /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
Josh Boyer writes: > The magic was quite specified. You rebuild the initramfs with the > convertfs module included, and pass the approriate arguments on boot. > There's a wiki page covering exactly that. Yes, the invokation is specified in detail. There just isn't any documentation of what it actually does, to enable you to e.g. do it by hand or have a guess at fixing it if it goes wrong. That is just too risky for me. You cannot upgrade from Fedora 16 to Fedora 17 in an OpenVZ guest, because those don't run an initrd at all (or even a separate kernel). /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
Adam Williamson writes: > 3. yum *if you follow the instructions carefully* Those instructions include dracut doing unspecified magic. For other releases I'd agree with you and do a yum upgrade, but I must admit I don't dare try this time. Preupgrade is a bit higher priority for this release. /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libpng mass rebuild status, 2011-12-06
Björn Persson writes: > ldd works recursively. What does "readelf --dynamic /usr/bin/gnome-session | > fgrep -i png" output? Thank you very much for your help. gnome-session depends on libgdk_pixbuf-2.0.so.0()(64bit) and gdk-pixbuf2 depends on libpng12.so.0()(64bit), so every dependency is correct. The problem was really stupid and I do apologize: arkwui, a part of the proprietary Arkeia backup system, provides libpng12.so.0()(64bit) without actually putting libpng12.so.0 anywhere useful. Sorry for wasting your time. /Benny (Why are backup systems universally crap?) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libpng mass rebuild status, 2011-12-06
Adam Jackson writes: > After yesterday's rebuilds, there remain 271 binary packages from 232 > source packages that still require libpng-compat. This is a bit late of course, but I have just upgraded to xbmc from rpmfusion-rawhide which required libpng15. I allowed yum to pull in dependencies from rawhide, so any dependencies on libpng should be taken care of. Unfortunately not. As an example, take gnome-session (which I upgraded explicitly in an attempt to fix the problem): # rpm -q gnome-session gnome-session-3.3.3-1.fc17.x86_64 # rpm -q --requires gnome-session | fgrep -i png (no output) # ldd /usr/bin/gnome-session|fgrep -i png libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x7fbd0a0c7000) A lot of packages suffer from the same problem; they depend on libpng but the RPM does not require libpng. /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 heads up: X server git snapshots
Mystilleef writes: > Hello, > > Wow, I read this a little too late. I did an update, using > --skip-broken, today and now Xorg is broken. I use the open source ati > drivers. The Xorg log indicates a version mismatch between Xorg and > the drivers. Is there a way to reverse or fix this? yum history followed by yum history undo? /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposing Fedora Feature for private /tmp and /var/tmp for all systemd services in Fedora 17.
Lennart Poettering writes: > Well, that way attackers might still be able fool the admin: i.e. he > could create a directory with a service name and some randomized suffix > and the admin might blindly believe that this directory belongs to the > service, even if it doesn't, but belongs to the evil attacker. Using a > fully randomized name is a bit more secure here, since the admin always > needs to check the service first for the actual directory. How about making a non-world-writable directory somewhere for this purpose, with service-named directories beneath it? That is yet another thing for sysadms to learn about of course, unless it is placed in /tmp itself which creates some security problems again... /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: VerifyHostKeyDNS, was Re: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
Tomas Mraz writes: > And if this malicious DNS administrator controls the caching > nameserver you're using for DNS queries, he can present you ANY data > even 'valid' fake DNSSEC data. This is not generally true. Resolver libraries can (and should, IMHO) verify DNSSEC themselves. Otherwise DNSSEC is somewhat pointless, because it is precisely when you are stuck behind an untrusted Wifi gateway that you need DNSSEC the most. /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
Matthew Garrett writes: > We have no technological solution for dealing with the fact that > applications may move from one DPI to another at runtime, and may even > be displaying on both displays at once. >From a technology viewpoint, that is actually theoretically easy to handle on modern hardware: Render everything as 3D objects and let the graphics hardware scale as appropriate. To get it to look pretty you would need fairly high DPI monitors or fancy scaling algorithms though. I can imagine that sub-pixel rendering would be quite tricky to get right when DPI changes halfway through a character. /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making . not match special extensions
Benny Amorsen writes: > Do any of you use _. to match e.g. the h extension? > > Right now _[a-z] does not match the special h extension but does match > someone explicitly dialling "h". Would it make sense to extend this > behaviour to the . and ! patterns, so they never match h? > > > /Benny I am so sorry. I'll hand in my geek card. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Making . not match special extensions
Do any of you use _. to match e.g. the h extension? Right now _[a-z] does not match the special h extension but does match someone explicitly dialling "h". Would it make sense to extend this behaviour to the . and ! patterns, so they never match h? /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SYSTEMD: Give us a option for upstart
Steve Clark writes: > If your are concerned with boot times suspend to disk! Suspend to disk is dead slow even with an SSD. That really is no alternative. Suspend to RAM is nice when it works which is about 4 times out of 5 on this laptop. (A great improvement over a few years ago, by the way). /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 15 Alpha TC2 Available Now!
Chris Adams writes: > Hmm, also what does this do to PXE booting. IIRC there is a (relatively > low) limit on the size of the initrd loaded by pxelinux. Even if there is no limit, fetching large files over TFTP can be rather slow. The initrd seems to be 135MB right now, which seems to be on the high side. /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Safest way to go from x86 to x86_64
Paul Johnson writes: > Is there a safe way to install the x86_64 system over the 32 bit version > and then clean off the 32 bit stuff that is no longer needed? There is no safe way to do it, but it IS in fact possible. I have done it twice. It is a lot of work, and I recommend against it. However, where is the fun in life if you do not do something impossible once in a while? First of all you need a 64-bit kernel on there (not so difficult; you can just do rpm -i --ignorearch ...) Then you need to create a repository file containing the relevant 64-bit repositories in /etc/yum.repos.d/. It is a bit difficult getting started because yum will complain about duplicate files when you install some x86_64 packages over i386 packages. You can get around that by letting yum fetch the files and rpm --replacefiles. There is a risk of overwriting something vitally important and rendering the i386 part of your system useless before you have a viable x86_64 system. Have a rescue disk handy. Other challenges can be that you cannot necessarily trust the RPM database to survive the architecture change. You may have to manually remove /var/lib/rpm/__* and do a rebuilddb. Or reinstall from backup if that fails. You will also hit some cases where yum gives up in ways that it asks you to report to the maintainers. I have not actually reported those to the maintainers because I imagine that this is a highly unsupported use of yum. You can get around the problems with rpm --replacefiles and similar tricks. Again, do not do this if you are not prepared to lose all your data. /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ethtool not in default system anymore?
Jiri Popelka writes: > I'm not sure. We are trying to eventually get net-tools out of the > default install. > Most of the scripts (initscripts/networking) has been using iproute commands > now and we're trying to navigate people to switch to ip as well. Maybe it would be worth attacking vconfig -> ip link add as well? >From a quick look, all that needs fixing are these 2 lines in fcoe-utils /usr/libexec/fcoe/fcoe-setup.sh vconfig set_name_type DEV_PLUS_VID_NO_PAD vconfig add $ifname $vlan > /dev/null which I believe could be replaced with: ip link add link $ifname name $ifname.$vlan type vlan id $vlan /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora "backports" repo?
Bruno Wolff III writes: > Because it is more work. If one is managing lots of systems as part of a > job, you want to be efficient in how your time is used. Fedora systems > change to fast for that. On the other hand, Fedora saves a lot of time by not having to maintain reasonably new versions of the server software you actually want to run - be it Postgres, BIND, Apache, DHCPD or something else. Maintaining those packages yourself is hard work, especially because you need to stay up-to-date on security updates. For me, Fedora definitely saves work over CentOS. The things that could change this: 1) If Postgres 9 was released in the middle of a cycle so a security upgrade ended up with forcing a full dump/reload of databases. I can't see that happening. 2) If Ruby keeps falling behind. (I'm sure others feel the same about Python...) 3) If Fedora ended up too broken to use for more than one release, so I couldn't just skip a cycle. Fixing the upgrade script every 6 months is a small price to pay for up-to-date software. /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora "backports" repo?
Arthur Pemberton writes: > What exactly is the fear here with these updates? Are there many > desktop users who do NOT want the latest released Firefox? Are there > many people using Fedora as their OS for their database server? I don't know about "many", but there is at least one organisation which runs production databases on Postgres on Fedora. People keep saying that "Fedora isn't for servers", but I just don't see why not. Getting stuck with years-old software in RHEL is no fun at all... Neither is self-compiling or third-party repositories. Anyway, it is unfortunate that the timing is such that Postgres 9 can't make it in time for Fedora 14. Please don't put Postgres 9 into Fedora 14 if it doesn't make it from the start. Major upgrades to Postgres are not something you want to happen during normal maintenance. /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd and changes
Al Dunsmuir writes: > Let's not forget that NM is not suitable for someone running a local > DNS server (bind with DNSSEC enabled). It also does not work at all > when used on a laptop as a caching DNS. Doesn't NetworkManager respect PEERDNS=no? As I understand it, it does read ifcfg-whatever. If it doesn't, that should be reasonably easy to fix. /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] orphaned packages in F-14
Adam Williamson writes: > PA uses a more correct but more CPU-intensive resampling method than > ALSA by default. On very slow systems it's a good idea to > edit /etc/pulse/daemon.conf and change the 'resample-method' parameter. Back when I had a slow enough machine to care (A Sempron 2600+ I believe, about a year ago), it was not the resampling which caused performance problems. Changing resample-method did not appreciably change CPU usage. On even slightly faster systems the CPU usage is very low and then resample-method does make a difference -- but why pick something worse when pulseaudio is already in the low single digits? The Sempron machine is dead now and I do not have anything else slow enough anymore. /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal
Kevin Kofler writes: > If the application is in Fedora as all applications eventually ought to be, > we will take care of rebuilding it. Otherwise, whoever built it (some third- > party repository or the user him/herself) is responsible for rebuilding it. > This has always worked fine, I don't see the problem. This is pretty harsh for in-house applications for companies. We'll have to watch the updates, rebuild the in-house applications, and deploy them to the internal repository on the day that they go into Fedora. Not the day before or the day after, because that would break dependencies. You can argue that such places should not accept unfiltered Fedora updates at all but run their own update servers. You can also argue that such places should pick a different distribution, because Fedora can't cater to everyone. Just please make sure the policy is announced so that we can act sensibly. Especially if the policy is "Gnome libraries won't require rebuilds during a release, whereas KDE libraries might". /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Remove write permissions from executables
Richard Zidlicky writes: > Mounting the fs read only is much easier and safer - and has long tradition. This is not feasible as a distribution policy. You can't guarantee that /usr/bin is on its own partition so you can mount it read only. The only way to achieve it would be creative use of mount --bind, something which certainly goes against tradition. Also, the advantage of the proposed change was that it would not affect e.g. yum upgrade. Creative use of mount --bind could perhaps achieve the same result, but not in a way which I consider sane. All in all I think it's a shame that the original proposal didn't work out at this time. Having binaries owned by bin:bin does have Unix (but not Linux AFAIK) tradition behind it. /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel