Re: Command line arguments depend on locale
Matthias Clasen mcla...@redhat.com 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 a...@redhat.com 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 skvi...@fedoraproject.org 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: What are reasonable blockers for making journald the default logger in F19?
Lennart Poettering mzerq...@0pointer.de 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: modules, firmware, kernel size
Josh Boyer jwbo...@gmail.com 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: modules, firmware, kernel size
Josh Boyer jwbo...@gmail.com 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: What are reasonable blockers for making journald the default logger in F19?
Matthew Miller mat...@fedoraproject.org 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 to...@pipebreaker.pl 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 mr...@courier-mta.com 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: Schedule for Monday's FESCo Meeting (2012-06-18)
Richard Hughes hughsi...@gmail.com 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: *countable infinities only
Jay Sulzberger j...@panix.com 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 hughsi...@gmail.com 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 jwbo...@gmail.com 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 awill...@redhat.com 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 bj...@xn--rombobjrn-67a.se 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 a...@redhat.com 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 mystill...@gmail.com 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 mzerq...@0pointer.de 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 tm...@redhat.com 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 mj...@srcf.ucam.org 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
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: Making . not match special extensions
Benny Amorsen benny+use...@amorsen.dk 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
Re: SYSTEMD: Give us a option for upstart
Steve Clark scl...@netwolves.com 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 cmad...@hiwaay.net 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 p...@all-the-johnsons.co.uk 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: Fedora backports repo?
Bruno Wolff III br...@wolff.to 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: systemd and changes
Al Dunsmuir al.dunsm...@sympatico.ca 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 awill...@redhat.com 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 kevin.kof...@chello.at 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
