Re: RFC: Audacious 3.6 build options
Michael, Thanks for sharing that. I think it'd be the best to go with the flow. That is, use the QT GUI. In the long run I think it is best to avoid maintaining multiple packages. I haven't seen the new QT GUI to be honest, it might be ugly, but still :) Perhaps if there is too much rage about it, we can maintain also an audacious gtk2 version (or someone else can :). I'd advise against it though. Maybe we should open it to the devel list? Is it possible to compile audacious on its own and then supply gtk3 and qt packages on top of it? Sounds like it might be difficult to maintain such a thing. Cheers, Dan. On Mon, Mar 2, 2015 at 1:45 AM, Michael Schwendt mschwe...@gmail.com wrote: Audacious 3.6 has been released. This is another chance for interested people to join and help deciding how to proceed with the Fedora packages. I'm still looking for co-maintainers, too, especially some who have an opinion on how to package it. I've been building pre-releases for it via Fedora Copr ( https://copr.fedoraproject.org/coprs/mschwendt/audacious-next/ ) but don't know whether anyone else has played with those yet (minus the MP3'n'similar plugins, of course, which are not available). Audacious 3.6 has changed the used programming language from C to C++. This also affects the Plugin API again, of course. It offers new GUI options for us to choose from: 1) The developers have introduced a Qt 5 based GUI that can coexist with the GTK+ GUI. It's called experimental, since it's not as feature-rich as the GTK+ GUI yet. It's a long-time goal to switch to Qt, however: http://redmine.audacious-media-player.org/boards/1/topics/1269 2) The developers are unhappy with gtk3 and have returned to gtk2. Currently, they offer _two_ different source tarballs, as they still support gtk3, too, and some of the changes are not done conditionally in the source code. They write: | Audacious can still be built with GTK3 if desired, | but we recommend the GTK2 variant for any desktop environment | other than GNOME 3. Which _would_ open the possibility to build both, but I don't think that would be worth the trouble (implicit conflicts in libs and packaged files - the necessity to work around the conflicts somehow, since they are forbidden if following Fedora's guidelines - the necessity to add explicit inter-dependencies between packages, and most users would still only install audacious and not an optional audacious-gtk2 or such). Enabling the Qt GUI would link Audacious core libraries with Qt by default in addition to GTK+ and GLib. That has the potential to annoy Qt haters, and Qt fans might be upset about the gtk3 dependency, too. Comments, anyone? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Review swap: NetworkManager-iodine
Hi there, Getting a spec for NetworkManager-iodine took minutes (pretty similar to the NetworkManager-ssh one, which I also maintain). It's here: https://bugzilla.redhat.com/show_bug.cgi?id=1040459 Happy to review anything else in return, however I'm aware I'm not a very experienced packager. Thanks Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: No Default Syslog
+1 - same here. You're far from being alone. I'm still trying to get used to the new systemd in Fedora and still trying to think why I need it. Altogether for my day to day use I find it as added complexity with no real benefit cerca f15. Unix/Linux for me is the simplicity of text files. If I lose the simplicity of text files I just wonder what is left for me? A bunch of vague files in a binary format I need complex tools to decipher? Might as well just install win7 and utilize my gfx card. Same happened to me when I moved from being a big fan of KDE to LXDE. Why is that? KDE became just too heavy, too much I just didn't need. LXDE just lets me open a terminal, a web browser, a music player and get my done with. A change like that is something probably the ubuntu community would like to adopt. A change that would just give me yet another reason to not use ubuntu. Linux is text files. It's grep, sed, bash, awk and all the other amazing text manipulation utilities we have. A change like that might actually make me move away from Fedora after being loyal to it for as long as it existed. And I know I will not be alone. Lets try to keep things simple. This is why we use Fedora. This is why I use Fedora. On Mon, Jul 15, 2013 at 7:11 PM, Miroslav Suchý msu...@redhat.com wrote: On 07/15/2013 10:44 AM, Jaroslav Reznik wrote: = Proposed System Wide Change: No Default Syslog = https://fedoraproject.org/**wiki/Changes/NoDefaultSysloghttps://fedoraproject.org/wiki/Changes/NoDefaultSyslog Change owner(s): Lennart Poettering lennart at poettering net, Matthew Miller mattdm at fedoraproject org No longer install a traditional syslog service by default. (Specifically, remove rsyslog from the @core or @standard groups in comps.) The systemd journal will be the default logging solution. Rsyslog, Syslog-NG, and even traditional sysklogd will continue to cover use cases outside of the default. My voice may be one of thousands, but I'm saying: I want to have traditional syslog service as default and have journal from systemd as option. -- Miroslav Suchy Red Hat, Software Engineer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, Jul 16, 2013 at 1:55 AM, Lennart Poettering mzerq...@0pointer.dewrote: On Tue, 16.07.13 00:55, Dan Fruehauf (malko...@gmail.com) wrote: +1 - same here. You're far from being alone. The +1 BTW was on Miroslav's comment. Obviously I'm against that change. I'm still trying to get used to the new systemd in Fedora and still trying to think why I need it. Altogether for my day to day use I find it as added complexity with no real benefit cerca f15. Unix/Linux for me is the simplicity of text files. If I lose the simplicity of text files I just wonder what is left for me? A bunch of vague files in a binary format I need complex tools to decipher? Might as well just install win7 and utilize my gfx card. Well, there are certain things on Unix that are text files and many things that are not. Binary log files have a long tradition on Unix, for example in wtmp and utmp. We have binary files in /etc, and everywhere else. And the reason for that being? I have no idea either, it's probably too old to be dug. Howver yes, I'd like these to be text based as well. journalctl is certainly not a complex tool to understand. Command lines usually get shorter by using it rather than the equivalent for /var/log/messages. People might also argue the event viewer in windows is not a complex tool. See where it got them. Mind you event viewer is probably a bit more mature than journalctl. cat /var/log/messages becomes just journalctl tail -f /var/log/messages becomes journalctl -f tail -n 100 /var/log/messages becomes journalctl -n 100 grep foo /var/log/messages becomes journalctl | grep foo All of these examples add a magnitude of complexity in terms of code. I'm unconvinced. And the outputs of these files are the exact same text streams you are used to. However, enhanced with a lot of niceties that make them more user friendly. For example, you get colors based on the log level, or there's a line drawn between reboots. You get the time zone corrected, and you get unconditional PID data, you can filter very very easy, the data is unfakable and so on. Just think about this: journalctl -b shows you output of the current boot only journalctl --since=today shows you the output of today only journalctl -p notice shows you only notice and error messages (i.e. all the important stuff) journaclctl -u crond shows you only the messages from cron. ... and so on. Now try to think how hard it is to express queries the same way on classic syslog. And how slow they become on larger database because they aren't indexed. journalctl makes a lot of things easier, much easier. If you say it is complex or difficult to use I am pretty sure you never had a closer look at it. (Also, I am not sure what you mean by vague. Please note that the file format is fully documented: http://www.freedesktop.org/wiki/Software/systemd/journal-files/ also, we commited to an API for them and more) I'm pretty sure somewhere also the windows binary format is documented. Lets try to keep things simple. This is why we use Fedora. This is why I use Fedora. We are certainly making things simpler by introducing nice query tools like journalctl and by reducing the number of packages we install by default, and by removing redundancy. Nice query tools? Lets go with a RDBMS to store the logs then? And for a short story about a system (I had nothing to do with) which based their log files in a RDBMS and their configuration in XML format. Failed miserably. The end. Another question while we're at it - what happens if and when you decide to change your binary format for storing files for whatever reason? Is that when we understand that we should have been left with just text based files? Lennart -- Lennart Poettering - Red Hat, Inc. -- 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
Re: F20 System Wide Change: No Default Syslog
On Tue, Jul 16, 2013 at 7:06 AM, Lennart Poettering mzerq...@0pointer.dewrote: On Mon, 15.07.13 14:53, Eric Smith (brouh...@fedoraproject.org) wrote: The need for /var/log/messages filters down to wanting to use less or shell built-ins to read the data, which is a valid usecase, but not worth the overhead in 99% of cases. But it's what people actually use in 99.9% of cases. 99.9% of the time I don't need the extra information in the binary journal. Making /var/log/messages unavailable by default has a huge down side. If we go to having only binary logs by default, maybe we should also go to having only binary configuration files by default. It's basically the same arguments: there's more information available; it's easier for software to parse; it can be made more reliable; special tools are OK and people don't really need to open it in a text editor. We've seen how well that works on Windows. Blech. Nobody is proposing this. Slippery slope arguments seldom are particularly convincing... Slippery slope arguments is what will make Fedora stop being Linux and become a bunch of utilities to parse some binary format files on top of a Linux kernel. And it's easy to turn this around: by following your logic we really should get rid of ELF binaries and instead write everything in some scripting language instead, since ELF binaries are, well, binary... That's pretty silly. But as much as I'm opposed to journalctl, I would have been opposed to changing anything else which is Bash based to something that's ELF, unless there is a good argument for that (performance... or?). Compiled stuff adds many times unneeded complexity. It's a matter of finding the right balance: i.e. what can be text files, and where we have to win more by making it binary. I am pretty sure this is a case where we win more by sticking to binary files. It's totally fine if you disagree on this, but I'd still like to ask you to think about whether your specific usecase and specific requirements are strong enough to (continue to) be the default for Fedora, instead of just being your local configuration of Fedora. The right balance is definitely not having log files as a binary format. We don't need use cases for log files. Log files should be plain text, plain simple, portable, accessible. journalctl is doing the exact opposite and not providing much benefit. Honestly Lennart, this is something that will make people start hating Fedora. Especially people who deal with crashes, recovery and support. I mean, you should never forget that on your own machines everything will stay as is: you will install syslog, and things will be exactly as before. Lennart -- Lennart Poettering - Red Hat, Inc. -- 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
Re: F20 System Wide Change: No Default Syslog
On Tue, Jul 16, 2013 at 9:51 AM, Lennart Poettering mzerq...@0pointer.dewrote: On Tue, 16.07.13 09:13, Dan Fruehauf (malko...@gmail.com) wrote: Well, there are certain things on Unix that are text files and many things that are not. Binary log files have a long tradition on Unix, for example in wtmp and utmp. We have binary files in /etc, and everywhere else. And the reason for that being? I have no idea either, it's probably too old to be dug. Howver yes, I'd like these to be text based as well. Oh, the reasons are pretty well-known for those cases. For example wtmp/utmp is binary so that utmp works nicely as sparse file and the entries may be accessed using the UID number as seek index (multipled by the fixed entry size). So, it's about indexing, exactly as for journal files. The Unix guys back then chose binary when it made sense for their immediate technical requirements. And for us it's the exact same. What made sense back in the day is today yet another vague decision that was being dragged with us for decades - because it made sense at the time. Going from text to binary is easy. Always easy to break things. Going back to text (if we want to) will be difficult. The above example is a really good one for why not to go binary, by all means. journalctl is certainly not a complex tool to understand. Command lines usually get shorter by using it rather than the equivalent for /var/log/messages. People might also argue the event viewer in windows is not a complex tool. See where it got them. Mind you event viewer is probably a bit more mature than journalctl. Well, if I cannot convince you to even try it out, and you insist on conflating the windows log viewer with journalctl (which is about as smart as conflating microsoft word with vi), then I guess there's no point in discussing this with you. Perhaps there isn't. On the day I will boot a Linux system and have no /var/log/messages out of the box, it'll be time for a change. By all means any windows person I know would much rather have logs as plain text. Not the other way around. Lets try to keep things simple. This is why we use Fedora. This is why I use Fedora. We are certainly making things simpler by introducing nice query tools like journalctl and by reducing the number of packages we install by default, and by removing redundancy. Nice query tools? Lets go with a RDBMS to store the logs then? Nobody suggests that. What's wrong with RDBMS? You only need to echo 'select * from log' | SOME_SQL_PROGRAM | less, it's exactly the same and you also have all the querying capabilities of a RDBMS. And for a short story about a system (I had nothing to do with) which based their log files in a RDBMS and their configuration in XML format. Failed miserably. The end. We do neither. You do neither, but you follow the very same path. Another question while we're at it - what happens if and when you decide to change your binary format for storing files for whatever reason? Is that when we understand that we should have been left with just text based files? We documented the format, and it is quite extensible. The sources are open. Altogether this are the best guarantees that the stuff stays stable and accessible. Thanks, I'd still prefer it text. Lennart -- Lennart Poettering - Red Hat, Inc. -- 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
Re: Hang on reboot with Fedora 19 (after software upgrades)
Alt+F1, Alt+F2, any VTs loaded? Run in single user? Once in, have a look at /var/log for interesting things I guess. On Sun, Jul 7, 2013 at 5:59 PM, Florian Weimer f...@deneb.enyo.de wrote: I tried to reboot after some software upgrades (which were released during the last few days). The system switched to a text console, showing a stray boot message, [ OK ] Started Postfix Mail Transport Agent., but did not proceed with the reboot. Is there something I can do to debug this? Should I boot from a rescue system and save some log files? (The system is currently still stuck, but I doubt there are any magic keys to unlock it.) -- 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
Re: Installing a very old Fedora (FC6) in a chroot?
Perhaps try in some sort of VM, like Virtualbox? On Wed, Jun 12, 2013 at 10:44 PM, Martin Langhoff martin.langh...@gmail.com wrote: To test / bench / verify old behaviour of PHP4, I need to install FC6 in a chroot. Mock doesn't seem to work, given a reasoanble config file pointing to the archive repo. Are there any good / recommended alternatives? Or is mock expected to work? cheers, m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- 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
Re: Software Management call for RFEs
Reverting changes to files handled by RPM (or installing a single file out of the package), for instance: rpm -qp some-rpm.rpm --revert/--extract /etc/some-rpm.conf /etc/another-file.conf I know it can be done with rpm2cpio, just a suggestion to implement it natively and extract the files to their correct location. On Thu, May 23, 2013 at 7:52 AM, Orion Poplawski or...@cora.nwra.comwrote: On 05/22/2013 07:43 AM, Jan Zelený wrote: Dear Fedora community, several months ago, at the Developer conference in Brno, Software Management team received a whole bunch of proposals for new functionality in RPM and related software stack. We acknowledge the need for some changes in Software Management stack in Fedora but we don't want to make changes just by guessing what our users want. Therefore I call to you, consumers of our products (dnf, yum and rpm): what are the changes that you would like to see in the foreseeable future (say 2-3 years) and why would you like to see them (what would they help you with)? There is already a list of some RFEs on rpm.org wiki, you can use it as an inspiration, to see what RFEs we have already received: http://rpm.org/wiki/**FeaturePlanninghttp://rpm.org/wiki/FeaturePlanning The only limitation for your requests is our manifest which defines the scope of SW management stack for the future. It is attached to this email (note that it's quite extensive but the first part should give you a good image of what is the planned scope of SW management stack). Please send your requests as replies to this email so they can be properly discussed. After your proposals are filed and discussed, all will be evaluated by our team and a roadmap with priorities will be created with those selected as doable and meaningful. Thank you in advance for your participation Jan Something I'm just now running into - I have a package that can make use of one of two different backends, but it definitely needs one of them. I don't want to pick which one in the package. Also, it is explicitly referencing specific implementations, not a generic interface, so a generic Provides in the backend packages is not appropriate. But something like: Requires: ( pkgA || pkgB ) might do the trick. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trimming (or obsoleting) %changelog?
Hey, I tend to be against trimming. I was just looking at the binutils changelog (goes back to 1997): $ rpm -q --changelog binutils | wc -c 54984 That's around 50K, and compressed (RPMs are compressed): $ rpm -q --changelog binutils | gzip | wc -c 15552 15K is nothing. Really. I like to see the whole history of a package, it's nice and fun. Perhaps other packages has larger changelogs. I guess common sense is what we should use, but generally speaking I'd say don't trim, as it doesn't really matter and it's cleaner to have a full changelog, rather than a story which starts somewhere in the middle. Just out of curiosity, what packages have huge changelogs? BR Dan Fruehauf. On Mon, Apr 15, 2013 at 10:43 PM, Rex Dieter rdie...@math.unl.edu wrote: Richard Hughes wrote: Is there any guidance as when to trim %changelog down to size? Some packages have thousands of lines of spec file dating back over 15 years which seem kinda redundant now we're using git. To me, common sense dictates that it's perfectly ok to trim the length of the changelog as long as items that are relevant to the current release are kept intact. Use your best judgement where that position lies. -- rex -- 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
Re: Trimming (or obsoleting) %changelog?
I stand corrected then, lets have a look at things uncompressed: glibc - 360K gcc - 20K gdb - 148K Still fail to see the big deal, sorry. On Wed, Apr 17, 2013 at 1:10 PM, Florian Festi ffe...@redhat.com wrote: On 04/17/2013 10:25 AM, Dan Fruehauf wrote: That's around 50K, and compressed (RPMs are compressed): $ rpm -q --changelog binutils | gzip | wc -c 15552 15K is nothing. Really. I like to see the whole history of a package, it's nice and fun. That's not correct. The change log is stored within the rpm header which is not compressed. While there have been efforts to compress the header those changes have not (yet) made it upstream as it would make rpm packages completely incompatible with older rpm versions. For limiting the change log entries in the binary packages %_changelog_trimtime can be used that take a unix time stamp as an integer value. This way the whole history is still available in the spec file. Florian -- 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
