Re: Heads up: libpng bumped to 1.5.x in rawhide
On 11/07/2011 12:16 PM, Tim Waugh wrote: On Sat, 2011-11-05 at 13:02 -0400, Tom Lane wrote: twaugh ghostscript twaugh gutenprint I've rebuilt these two. Tim. */ (Apologies for replying to your reply, Tim, but I wasn't subscribed at the start of this thread.) I'm a graphviz upstream maintainer, not a fedora maintainer, so these changes have not been applied yet: I verified that graphviz can be built locally with libpng15, after: - rebuilding gd - no changes needed - rebuilding gdk_pixbuf2 - no changes needed - rebuilding DevIL - needed patch https://bugzilla.redhat.com/show_bug.cgi?id=751583 - rebuilding graphviz - needed patch https://bugzilla.redhat.com/show_bug.cgi?id=751807 The graphviz changes were due to changes in PHP's abi, rather than libpng15. The PHP abi problem also affects fc16. John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
Simo, For the VPN scenario I've been happily using dnrd for some time. I use it to steer DNS requests for mycompany.com to the company's DNS servers, and all other DNS requests to the external servers. Unlike just adding the company DNS servers to /etc/resolv.conf, this never uses the company's DNS for external domain resolution, even if the primary ISP's DNS servers are down. I also use routing to steer company traffic to the VPN, and the rest to my default route. John On 06/20/2012 11:47 AM, Simo Sorce wrote: Ok, I guess this topic has been brought up before, but I think some things changed recently that would warrant seriously considering adding a default caching name server in fedora installs. There are at least 2 situations where it is needed, and they are common or will be common enough. The 2 use cases for which a properly configurable and dynamically changeable caching DNA name server would be really useful are: - DNSSEC verification - Clients using VPNs into private networks. The first case is already in the works, and the reason it needs a caching DNS name server is the complexity of dealing with DNSSEC verification. I won't spend time on that except for saying this effort should be part of a unified solution. The second case is what is really hurting me. I have my own DNS server at home that resolves address only for my private network, and forwards any other request. When I connect to my employer VPN however I need to use their DNS server to resolve their internal machines, the same happens to pretty much any other VPN service I have used. Also I do not need to route all DNS traffic in the VPN for all web sites, mostly for performance reasons, but also for privacy reasons. This could be easily solved if we have a caching DNS server that can be dynamically change to forward DNS requests to the proper DNS server only for the private domains they provide. A good name caching server would forward all .redhat.com DNs request top the DNS addresses provided by the VPN connection, all my .home addresses to my local DNS server (provided by dhcp) and perhaps all other addresses to a configurable 'default DNS server'. Of course for this to work properly we need some level of integration between Network Manager and the DNS caching server so that the dynamic configurations can be pushed in/out when the related networks come up/down. Discuss. Simo. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PATH=/usr/local/bin:/bin:/usr/bin considered harmful
Having thought about it, I don't think it's unreasonable to do a which $PROG, and stick it into the hashbang. I think that's a perfectly reasonable approach, with portability being the goal. The problem I see here, is that Fedora's bash is compiled with the default PATH placing a symlink, /bin, ahead of /usr/bin, in the PATH list: +1 on this. This has very little to do with yum; It affects other programs too. It breaks graphviz builds, for example, because its build scripts try to deduce various tcl paths from `which tclsh` It is also a significant performance hit for every executable lookup to traverse an extra softlink from /bin - /usr/bin. Since there is nothing in /bin now, /bin should be after /usr/bin in the default PATH.. John On 06/21/2012 11:15 PM, Sam Varshavchik wrote: The perl update that hit updates this week is causing a yum conflict with some locally-built packages, of this type: Error: Package: courier-imap-4.10.0.20120202-2.17.x86_64 (installed) Requires: /bin/perl Removing: 4:perl-5.14.2-211.fc17.x86_64 (@anaconda-0) Not found Updated By: 4:perl-5.14.2-212.fc17.x86_64 (updates-released-local) Not found From what I can tell, the sequence of events is: A) A local package's configure script executes which perl, and puts that into each perl script's hashbang. So: [root@octopus ~]# which perl /bin/perl This results in: #! /bin/perl B) The rpm package gets built. find-requires that puts this dependency into the package: requires=/bin/perl C) At install time, rpm seems to be smart to figure this out: [root@octopus ~]# rpm -q --whatprovides /bin/perl perl-5.14.2-211.fc17.x86_64 It's smart enough sees that thanks to the symlinks, /bin/perl=/usr/bin/perl. So the package gets installed, with these hashbangs. D) A perl update hits: [root@shorty x86_64]# rpm -q -l -p perl-5.14.2-212.fc17.x86_64.rpm | fgrep bin/perl /usr/bin/perl /usr/bin/perl5.14.2 /usr/bin/perlbug /usr/bin/perlthanks The new perl package contains /usr/bin/perl. At upgrade, dependency resolution is not smart enough to realize that the new package's /bin/perl=/usr/bin/perl, causing a conflict. Having thought about it, I don't think it's unreasonable to do a which $PROG, and stick it into the hashbang. I think that's a perfectly reasonable approach, with portability being the goal. The problem I see here, is that Fedora's bash is compiled with the default PATH placing a symlink, /bin, ahead of /usr/bin, in the PATH list: [root@octopus ~]# strings /bin/bash | grep usr.bin /usr/local/bin:/bin:/usr/bin I think that bash needs to be recompiled, with the last two flipped, in the default shell PATH. Until then, I need to hack each one of my locally-built package's rpm spec scripts, and manually prepend /usr/bin to the PATH. Which sucks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Couldn't we enable 256 colors by default on TERM?
On 06/26/2012 08:50 AM, Chris Adams wrote: Once upon a time, Pádraig Brady p...@draigbrady.com said: The main caveat with per terminal settings is that it might be desired to provide config options per terminal. Though I suppose users can always override TERM in their startup files in the unlikely case they need to change back to 'xterm' for example. I still use plain old xterm (the terminal program), and it allows you to override the TERM variable in a couple of ways. There's a command-line option, and there's the old X resource termName. The newer terminal programs have configuration menus for various things; do any of them set it there? If they don't, I would think it would be relatively easy to add (and hopefully upstreams would accept such patches). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Couldn't we enable 256 colors by default on TERM?
On 06/26/2012 06:54 AM, Pádraig Brady wrote: . The main caveat with per terminal settings is that it might be desired to provide config options per terminal. Though I suppose users can always override TERM in their startup files in the unlikely case they need to change back to 'xterm' for example. Unlikely Pffft!!What else do you resort to every time gnome-terminal won't start because dbus has crashed? John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: small tip regarding git branch bash prompt in F18/Rawhide
On 08/23/2012 08:45 AM, Ville Skyttä wrote: On 2012-08-23 15:12, Jon Ciesla wrote: things in %doc shouldn't be things that affect run-time operation True, but there are other considerations in favour of unversioned dirs such as bookmarkability and general referenceability, consistency with other distros, and general cleanliness. But this stuff deserves a discussion of its own. +1 But an unversioned softlink to the latest would suffice. John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Heads up: My FC18 i686 vhost was bricked by lastest updates.
Caution (it might just be me, but just in case...) I can no longer boot my Fedora 18, i686, virtual host this morning after yum update https://bugzilla.redhat.com/show_bug.cgi?id=861130 I suspect, but can't verify quickly, either systemd or glibc. John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On 01/27/2012 08:10 AM, Harald Hoyer wrote: Hello Testers and rawhide Users, Fedora 17 will locate the entire base operating system in /usr. The directories /bin, /sbin, /lib, /lib64 will only be symlinks: /bin → /usr/bin /sbin → /usr/sbin /lib → /usr/lib /lib64 → /usr/lib64 Mostly worked as described. One issue is that the default user's PATH needs to be cleaned up: /usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/guest/.local/bin:/home/guest/bin No point in having the primary PATH going through softlinks all the time. Probably should be: /usr/local/bin:/usr/bin:/home/guest/.local/bin:/home/guest/bin Everything was being found in /bin before /usr/bin, and this caused an obscure breakage in the graphviz build scripts because it found /bin/tclsh instead of /usr/bin/tclsh. (Where does this default PATH come from??) There may be a similar problem with ldconfig.At the moment ldconfig -p show most libs being resolved from /lib instead of from /usr/lib. Another issue is that I have: /bin/sh: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory [1.796642] Kernel panic - not syncing: attempted to kill init! when trying to boot kernel-3.3.0-0.rc1.git4.1.fc17.i686 from f17-usrmove repo.Reverting to kernel-3.3.0-0.rc1.git3.1.fc17.i686 from the Rawhide repo works ok. John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On 01/28/2012 06:48 AM, Josh Boyer wrote: On Fri, Jan 27, 2012 at 5:57 PM, John Ellsonjohn.ell...@comcast.net wrote: Another issue is that I have: /bin/sh: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory [1.796642] Kernel panic - not syncing: attempted to kill init! when trying to boot kernel-3.3.0-0.rc1.git4.1.fc17.i686 from f17-usrmove repo.Reverting to kernel-3.3.0-0.rc1.git3.1.fc17.i686 from the Rawhide repo works ok. That means your initramfs for the git4.1 kernel is probably broken. It has nothing to do with the kernel itself. There is a patch needed for kernel.spec eventually, but it isn't integrated yet and I think the patch I've seen needs to be updated slightly. josh Is there a workaround, or do I need to wait for a kernel update? I tried to rebuild initramfs using: dracut -f initramfs-3.3.0-0.rc1.git4.1.fc17.i686.img 3.3.0-0.rc1.git4.1.fc17.i686 but that made no difference. John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On 01/27/2012 05:57 PM, John Ellson wrote: On 01/27/2012 08:10 AM, Harald Hoyer wrote: Hello Testers and rawhide Users, Fedora 17 will locate the entire base operating system in /usr. The directories /bin, /sbin, /lib, /lib64 will only be symlinks: /bin → /usr/bin /sbin → /usr/sbin /lib → /usr/lib /lib64 → /usr/lib64 Mostly worked as described. One issue is that the default user's PATH needs to be cleaned up: /usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/guest/.local/bin:/home/guest/bin ... There may be a similar problem with ldconfig.At the moment ldconfig -p show most libs being resolved from /lib instead of from /usr/lib. I'm not against this change, but it would be better if it resulted in a performance gain rather than a performance loss. I wrote a test to stat() the 2000+ files in /usr/bin/*, or /bin/*, 100 times. The time cost of a stat() of /usr/bin/foo was ~ 12.4 microseconds; the time cost of a stat() of /bin/foo was ~17.8 microseconds. So to me, it is important that the default PATHs are changed to minimize the traversal of softlinks. At the moment, having /bin early in the PATH means that a softlink has been *introduced* into most lookups, thus degrading performance. The same issue exists for libs. John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
This karma stuff is a pain!
Can we just generate karma from a comment in bugzilla please? Having to find some other weird place to indicate that a fix works for me is a real pain. John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: This karma stuff is a pain!
On 03/16/2012 05:13 AM, Michael Scherer wrote: Le jeudi 15 mars 2012 à 12:49 -0400, John Ellson a écrit : Can we just generate karma from a comment in bugzilla please? Having to find some other weird place to indicate that a fix works for me is a real pain. Have you tried fedora-easy-karma ? https://fedoraproject.org/wiki/Fedora_Easy_Karma This is supposed to be easy? Run fedora-cert, included with fedora-easy-karma as a dependency, to set up a certificate with your FAS credentials. I'm sure karma is useful to Release-Engineering. I just think the scope is wrong for a bug reporter. Take, for example: https://admin.fedoraproject.org/updates/NetworkManager-0.9.3.995-0.6.git20120314.fc17 The update contains fixes for three problems: 800690, 798102, 802540 I contributed to the first bug, 800690, and duly tested and reported works for me, but I had no involvement in the other two, so I'm not in a position to judge their karma. I think these release updates should automatically gain partial, per-bug karma from works for me in the bug reports. karma for the update in total needs to come from people in a release-engineering role, rather than people in a bug reporting/fixing/testing role. I agree that people using an update testing repository are reasonable candidates for the release-engineering role, but bug reporting/fixing/testing role doesn't require update testing. The bugs fixes might be tested directly from koji, or from some private builds, or even from local patching. I am trying to be constructive here. We're all busy people. I just think that karma is outside of a reasonable workflow for a bug reporter. John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
bug or feature? gdm logins not recorded in lastlog
Before I generate a bug report, could I get a second opinion on whether this is a bug or a feature? Console logins through gdm are not getting recorded in lastlog. (Fedora 16) John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bug or feature? gdm logins not recorded in lastlog
On 04/16/2012 03:16 AM, Tomas Mraz wrote: On Mon, 2012-04-16 at 00:03 -0400, John Ellson wrote: Before I generate a bug report, could I get a second opinion on whether this is a bug or a feature? Console logins through gdm are not getting recorded in lastlog. (Fedora 16) I think it is a bug. It might be solvable by adding the line: sessionrequiredpam_lastlog.so silent nowtmp to the gdm PAM configuration files. Thanks Tomas, that does seem to fix it. Bugzilla #812853 John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review request: nodebrain - a declarative rule-based language for state and event monitoring
Requesting review of a new package: nodebrain https://bugzilla.redhat.com/show_bug.cgi?id=592504 Description: NodeBrain is an interpreter of a declarative rule-based language designed for construction of state and event monitoring applications. It interacts with other monitoring components to perform simple element state monitoring or complex event correlation based on user specified rules. It is extended through the development of node modules (plug-ins) using NodeBrain's C API, and servants (programs written in any language) that interact with NodeBrain via stdin, stdout, and stderr. A small set of plug-ins are distributed with NodeBrain to provide commonly needed features such as peer-to-peer communication, log monitoring, event caching, and a web browser interface for administrators. I will be pleased to return the favor, if I can. John Ellson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFD Unifying graphviz.spec with upstream
> Doubtful. It's a maintenance nightmare OK, but I'm raising this issue to try to get some help on getting a little closer. > Tons of defines and conditionals, which toggle almost everything (BR, > features and subpkgs) Yes,as a means of stating which feature can be built for which distro. This are determined by the available packages from the distro. I do not arbitrarily turn them on or off. If a dependency becomes available, then I can turn the define on, but in that transition nothing is obsoleted. > using highly cryptic macro names, > sections that don't adhere to the packaging guidelines, > dangerous violations of the guidelines, Specific examples please? > workarounds for RHEL 7. Actually there are no workarounds for RHEL7. RHEL7 and RHEL6 package sets are the same. There are workarounds for RHEL4 and RHEL5, but at this point those could all be purged from the spec. There are also workarounds for Fedora <23. Removing those as well would simplify the spec considerably. I am willing to do that. > You may be familiar with the spec file, or you may believe you are, but in my > point of view, the spec file is filled with pitfalls. That will backfire > eventually. Well, this is why I'm asking for help. > Not even the %changelog has been maintained since 2009. Guilty. > And probably the biggest mistake related to conditional subpackage builds is > that you cannot simply flip a #define and disable a subpackage build without > inserting an Obsoletes/Provides pair. As discussed, they are not used in that way. They have been only used to not-enable a feature or subpackage on distros that don't provide the needed dependencies. > So, what may be of some limited use while testing builds, is of no use in > packages released into a public distribution. So as I understand it, you would like a separate .spec file for each distro, to avoid the #define. ? Can we agree to differ on that issue between upstream and public distribution, for now? Can we work on the other issues first? John > On July 20, 2017 at 6:47 AM Michael Schwendt <mschwe...@gmail.com> wrote: > > > On Wed, 19 Jul 2017 13:27:54 -0400 (EDT), John Ellson wrote: > > > Jaroslav Škarvada requested that i move the discussion from: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1410366 > > > > about unifying the graphviz .spec file with upstream, to this list. > > > > > > Perhaps the unification objective is not attainable because of different > > requirements? > > > > > > Upstream, we have single a distro-agnostic (RH and non-RH) graphviz.tar.gz > > portable sources: > > > > http://graphviz.org/Download_source.php > > > > and then for RH, all distros, we have a single graphviz.src.rpm containing > > a universal graphviz.spec. > > > > http://graphviz.org/Download_linux_fedora.php > > > > > > This works well for me, upstream, for building and testing across all > > distributions, but perhaps the .spec file is less optimal when you > > separately maintain versions for each distribution? > > > > Doubtful. It's a maintenance nightmare. Tons of defines and conditionals, > which toggle almost everything (BR, features and subpkgs) using highly > cryptic macro names, sections that don't adhere to the packaging > guidelines, dangerous violations of the guidelines, workarounds for RHEL > 7. You may be familiar with the spec file, or you may believe you are, but > in my point of view, the spec file is filled with pitfalls. That will > backfire eventually. Not even the %changelog has been maintained since > 2009. And probably the biggest mistake related to conditional subpackage > builds is that you cannot simply flip a #define and disable a subpackage > build without inserting an Obsoletes/Provides pair. So, what may be of > some limited use while testing builds, is of no use in packages released > into a public distribution. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
RFD Unifying graphviz.spec with upstream
Jaroslav Škarvada mailto:jskar...@redhat.com requested that i move the discussion from: https://bugzilla.redhat.com/show_bug.cgi?id=1410366 about unifying the graphviz .spec file with upstream, to this list. Perhaps the unification objective is not attainable because of different requirements? Upstream, we have single a distro-agnostic (RH and non-RH) graphviz.tar.gz portable sources: http://graphviz.org/Download_source.php and then for RH, all distros, we have a single graphviz.src.rpm containing a universal graphviz.spec. http://graphviz.org/Download_linux_fedora.php This works well for me, upstream, for building and testing across all distributions, but perhaps the .spec file is less optimal when you separately maintain versions for each distribution? My preference would be to unify to a single .spec file, rather than to ~10 different ones, but maybe you will tell me that that isn't possible. In which case i would probably keep a separate single .spec for upstream builds. Minimally I'd like to reach some agreement on the set of sub-packages and their names? On the topic (from the bug report) of (e.g.) "graphviz-lang-python2" vs "python2-graphviz" would it be possible to discuss an exception? My key issues are that the packages are a subpackages of graphviz, owned by graphviz, supported by graphviz, from a single swig "gv.i" template for all languages.I feel that reversing the naming loses the common connection of these packages. Also I fear that the renaming may not go well since chances are that someone else already has an xxx-graphviz. All feedback considered. John ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFD Unifying graphviz.spec with upstream
I've limited the upstream .spec to el >= 6 and fc >= 23, and then removed a lot of conditionals that are no longer needed (with some loss of generality). Latest upstream spec (pre-configure source) is at: https://github.com/ellson/graphviz/blob/master/graphviz.spec.in and the resulting source rpm is at http://graphviz.org/pub/graphviz/development/SRPMS/graphviz-2.41.20170720.1642-1.src.rpm > On July 20, 2017 at 9:36 AM John Ellson <john.ell...@comcast.net> wrote: > > > Doubtful. It's a maintenance nightmare > OK, but I'm raising this issue to try to get some help on getting a > little closer. > > > Tons of defines and conditionals, which toggle almost everything (BR, > features and subpkgs) > Yes,as a means of stating which feature can be built for which distro. > This are determined by the available packages from the distro. I do not > arbitrarily > turn them on or off. If a dependency becomes available, then I can turn > the define on, but in that transition nothing is obsoleted. > > > using highly cryptic macro names, > > sections that don't adhere to the packaging guidelines, > > dangerous violations of the guidelines, > > Specific examples please? > > > workarounds for RHEL 7. > Actually there are no workarounds for RHEL7. RHEL7 and RHEL6 package sets > are the same. > There are workarounds for RHEL4 and RHEL5, but at this point those could > all be purged from the spec. > > There are also workarounds for Fedora <23. Removing those as well would > simplify the spec considerably. I am willing to do that. > > > You may be familiar with the spec file, or you may believe you are, but > in my point of view, the spec file is filled with pitfalls. That will > backfire eventually. > Well, this is why I'm asking for help. > > > Not even the %changelog has been maintained since 2009. > Guilty. > > > And probably the biggest mistake related to conditional subpackage > builds is that you cannot simply flip a #define and disable a subpackage > build without inserting an Obsoletes/Provides pair. > As discussed, they are not used in that way. They have been only used to > not-enable a feature or subpackage on distros that don't provide the needed > dependencies. > > > So, what may be of some limited use while testing builds, is of no use > in packages released into a public distribution. > So as I understand it, you would like a separate .spec file for each > distro, to avoid the #define. ? > Can we agree to differ on that issue between upstream and public > distribution, for now? Can we work on the other issues first? > > John > > > On July 20, 2017 at 6:47 AM Michael Schwendt <mschwe...@gmail.com> > wrote: > > > > > > On Wed, 19 Jul 2017 13:27:54 -0400 (EDT), John Ellson wrote: > > > > > Jaroslav Škarvada requested that i move the discussion from: > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1410366 > > > > > > about unifying the graphviz .spec file with upstream, to this list. > > > > > > > > > Perhaps the unification objective is not attainable because of > different requirements? > > > > > > > > > Upstream, we have single a distro-agnostic (RH and non-RH) > graphviz.tar.gz portable sources: > > > > > > http://graphviz.org/Download_source.php > > > > > > and then for RH, all distros, we have a single graphviz.src.rpm > containing a universal graphviz.spec. > > > > > > http://graphviz.org/Download_linux_fedora.php > > > > > > > > > This works well for me, upstream, for building and testing across all > distributions, but perhaps the .spec file is less optimal when you separately > maintain versions for each distribution? > > > > > > > Doubtful. It's a maintenance nightmare. Tons of defines and > conditionals, > > which toggle almost everything (BR, features and subpkgs) using highly > > cryptic macro names, sections that don't adhere to the packaging > > guidelines, dangerous violations of the guidelines, workarounds for RHEL > > 7. You may be familiar with the spec file, or you may believe you are, > but > > in my point of view, the spec file is filled with pitfalls. That will > > backfire eventually. Not even the %changelog has been maintained since > > 2009. And probably the biggest mis
