Rebuild of all pkgs which depends on libjpeg.so starts
Hello all, as announced on http://lists.fedoraproject.org/pipermail/devel/2013-January/176354.html, I'm going to rebuild libjpeg-turbo with ".62.0.0" ABI and then start rebuilds of all dependant pkgs. Please excuse intermittent rawhide buildroot breakage which can happen. Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Drop of the "libjpeg-turbo jpeg8 ABI" feature
On Thu, Jan 17, 2013 at 12:37:56PM +0100, Vít Ondruch wrote: > Dne 16.1.2013 17:42, Jaroslav Reznik napsal(a): > >- Original Message - > >>Hello all, > >> > >>after discussion with libjpeg and libjpeg-turbo upstreams I decided > >>to drop the > >>"jpeg8 API/ABI" feature and include only jpeg6 API/ABI. > >Ok, I'm going to switch libjpeg-turbo-jpeg8-ABI to incomplete category, > >thanks. > > Shouldn't be the feature page just deleted? Or archived in some > better category such as "deferred"? There is 256 (nice number ;) > incomplete feature pages, some of them are probably abandoned as > this one. Would be nice to do some cleanup there, to see what is > actively worked on. > > Thank you. +1 However I don't think it should be deleted, it can be moved to category "Dropped" or "Rejected" or something like this. Such category can be good archive of things which shouldn't be done (and why) in case someone brings this idea again. Regards, Adam > > > > >Jaroslav > > > >>The main > >>reason is that > >>libjpeg upstream didn't present any valid argument for post-jpeg6 > >>changes and > >>libjpeg-turbo is not going to port all post-jpeg6 changes. The thread > >>with > >>related discussion is on > >>http://sourceforge.net/mailarchive/message.php?msg_id=30352465 > >> > >>I'm going to build the libjpeg-turbo pkg with jpeg6 API/ABI and then > >>I will > >>start with rebuilds of all dependent packages. This can probably > >>happen during > >>Friday. > >> > >>Any comments are welcome. > >> > >>Regards, Adam > >> > >>-- > >>Adam Tkac, 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 -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: BIND10 - next generation of the popular BIND9 DNS server rewritten from scratch
On Wed, Jan 16, 2013 at 03:59:10PM -0500, Simo Sorce wrote: > On Wed, 2013-01-16 at 21:55 +0100, Adam Tkac wrote: > > On Wed, Jan 16, 2013 at 03:21:41PM -0500, Bill Nottingham wrote: > > > Jaroslav Reznik (jrez...@redhat.com) said: > > > > As decided by FESCo on 2012-12-05 meeting, all proposed Features are > > > > required > > > > to pass through the community review by announcing them on > > > > devel-announce list. > > > > FESCo votes on new features no sooner than a week from the announcement. > > > > > > > > = Features/BIND 10 = > > > > https://fedoraproject.org/wiki/Features/BIND10 > > > > > > > > * Detailed description: > > > > BIND10 suite implements two crucial network services - DNS and DHCP. > > > > The BIND10 is going to replace both widely used ISC BIND9 and ISC DHCP4 > > > > software in the future. It is written from scratch and has modular > > > > design. > > > > > > And... dhcp6? > > > > Ah, with DHCP4 I meant DHCP 4.X.X, not IPv4 DHCP, sorry for bad description. > > BIND10 of course supports both IPv4 and IPv6 DHCP protocols. I removed the > > "4" > > suffix on wiki to avoid confusions. > > > > > I note that the feature page describes this as a parallel installable > > > stack. > > > Is there a reason to keep both versions around in a way we didn't with > > > other bind major upgrades? > > > > Yes because there is _no_ backward compatibility with current bind9. > > Configuration is completely different, management is completely different > > etc... > > People definitely need some time for testing and transition to bind10. > > It is not only a matter of configuration, is bind10 going to be > pluggable ? FreeIPA with bind-dynd-ldap depends on bind9 and will > require some major work to port it to bind10 ... or something else. > In the meanwhile it will depend on bind9 being available in the > distribution. Yes, it is going to be pluggable but it doesn't have any API for modules, yet. Upstream is currently busy with work on core DNS/DHCP daemons. But they design bind10 with plugins in mind. Btw about transition time, it definitely won't happen in ~1 year. I guess transition can take ~5 years, so you don't have to bother that bind9 will dissapear during next 5 - 10 Fedora releases... Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: BIND10 - next generation of the popular BIND9 DNS server rewritten from scratch
On Wed, Jan 16, 2013 at 03:21:41PM -0500, Bill Nottingham wrote: > Jaroslav Reznik (jrez...@redhat.com) said: > > As decided by FESCo on 2012-12-05 meeting, all proposed Features are > > required > > to pass through the community review by announcing them on devel-announce > > list. > > FESCo votes on new features no sooner than a week from the announcement. > > > > = Features/BIND 10 = > > https://fedoraproject.org/wiki/Features/BIND10 > > > > * Detailed description: > > BIND10 suite implements two crucial network services - DNS and DHCP. > > The BIND10 is going to replace both widely used ISC BIND9 and ISC DHCP4 > > software in the future. It is written from scratch and has modular design. > > And... dhcp6? Ah, with DHCP4 I meant DHCP 4.X.X, not IPv4 DHCP, sorry for bad description. BIND10 of course supports both IPv4 and IPv6 DHCP protocols. I removed the "4" suffix on wiki to avoid confusions. > I note that the feature page describes this as a parallel installable stack. > Is there a reason to keep both versions around in a way we didn't with > other bind major upgrades? Yes because there is _no_ backward compatibility with current bind9. Configuration is completely different, management is completely different etc... People definitely need some time for testing and transition to bind10. Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Drop of the "libjpeg-turbo jpeg8 ABI" feature
On Wed, Jan 16, 2013 at 09:38:29AM -0700, Kevin Fenzi wrote: > On Wed, 16 Jan 2013 17:14:26 +0100 > Adam Tkac wrote: > > > Hello all, > > > > after discussion with libjpeg and libjpeg-turbo upstreams I decided > > to drop the "jpeg8 API/ABI" feature and include only jpeg6 API/ABI. > > The main reason is that libjpeg upstream didn't present any valid > > argument for post-jpeg6 changes and libjpeg-turbo is not going to > > port all post-jpeg6 changes. The thread with related discussion is on > > http://sourceforge.net/mailarchive/message.php?msg_id=30352465 > > > > I'm going to build the libjpeg-turbo pkg with jpeg6 API/ABI and then > > I will start with rebuilds of all dependent packages. This can > > probably happen during Friday. > > > > Any comments are welcome. > > Just a few. ;) > > 1. Are you expecting to do all the rebuilds in one day so they all land > in rawhide at the same time? If not, perhaps a side tag? Yes, rebuild will happen during one day. > 2. Do you have a list of affected packages? # repoquery --alldeps --whatrequires 'libjpeg.so.8()(64bit)' |wc -l 373 > 3. Many folks are going to be at fudcon friday, so the chances of > people being around to fix their packages, etc are low. Perhaps early > next week would be better to land this? I will use my provenpackager privileges and I will rebuild pkgs myself, as I did for jpeg6->jpeg8 ABI bump. I think it's good that people are away because buildroots will be broken for some time so people won't be affected :) Separate tag is not needed, I think. Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Drop of the "libjpeg-turbo jpeg8 ABI" feature
Hello all, after discussion with libjpeg and libjpeg-turbo upstreams I decided to drop the "jpeg8 API/ABI" feature and include only jpeg6 API/ABI. The main reason is that libjpeg upstream didn't present any valid argument for post-jpeg6 changes and libjpeg-turbo is not going to port all post-jpeg6 changes. The thread with related discussion is on http://sourceforge.net/mailarchive/message.php?msg_id=30352465 I'm going to build the libjpeg-turbo pkg with jpeg6 API/ABI and then I will start with rebuilds of all dependent packages. This can probably happen during Friday. Any comments are welcome. Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: [Libjpeg-turbo-users] jpeg-9, API/ABI compatibility, and the future role of this project
On Wed, Jan 16, 2013 at 01:02:57PM +0100, Michael Stahl wrote: > On 15/01/13 20:04, Xose Vazquez Perez wrote: > > On 01/15/2013 01:01 PM, Adam Tkac wrote: > > > >> Another interesting thread is > >> http://sourceforge.net/mailarchive/message.php?msg_id=30352453 > >> > >> We are currently discussing drop of the > >> https://fedoraproject.org/wiki/Features/libjpeg-turbo-jpeg8-ABI feature > >> because > >> SmartScale encoding (only reason of the jpeg7 and jpeg 8 ABI bumps) was > >> rejected > >> by ISO and actually doesn't bring any benefit over widely used png/webp > >> codecs. > >> > >> So Fedora will probably stick with old jpeg6 API/ABI unless IJG maintainer > >> reveals some new facts about SmartScale. All facts are currently against > >> SmartScale (image quality/size, compression/decompression speed). > > > > Upstream Tracker shows 0% of binary compatibility with previous > > releases: http://upstream-tracker.org/versions/libjpeg.html > > > > I hope other distributions don't use that release. > > FWIW i'm afraid i've had to build jpeg8 from source already to get a > certain binary [1] built on Ubuntu to run on Fedora 17... > > [1] actually a git repo full of binaries: > https://wiki.documentfoundation.org/Bibisect I read the link and it seems libjpeg62 is sufficient (i.e. jpeg6 ABI) for bibisect. So you should not need jpeg8 ABI. Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: [Libjpeg-turbo-users] jpeg-9, API/ABI compatibility, and the future role of this project
e SmartScale for any other purpose (apparently I'm > not the only one who struggles with this: > http://hardwarebug.org/2010/02/01/ijg-swings-again-and-misses/). And it > hasn't been proven that the use of this extension for lossless encoding > is significantly better than, for instance, PNG. In fact, from my > admittedly quick & dirty testing, it seems to be worse: > > Using jpeg-8d: > > time ./cjpeg -rgb -block 1 -arithmetic <~/test_images/nightshot_iso_100.ppm > > >nightshot_iso_100.jpg > real 0m7.025s > user 0m6.468s > sys 0m0.087s > Original size: 22127633, Compressed size: 7537012, Ratio: 2.936 > > Using the new color transform in jpeg-9: > > time ./cjpeg -rgb1 -block 1 -arithmetic > > <~/test_images/nightshot_iso_100.ppm >nightshot_iso_100.jpg > real 0m7.316s > user 0m6.753s > sys 0m0.081s > Original size: 22127633, Compressed size: 7554020, Ratio: 2.929 > > Using ImageMagick 6.7.9 to compress as PNG: > > time convert -quality 6 ~/test_images/nightshot_iso_100.ppm > > nightshot_iso_100.png > real 0m2.647s > user 0m1.689s > sys 0m0.114s > Original size: 22127633, Compressed size: 7157427, Ratio: 3.092 > > Maybe I'm missing something? Anyhow, until/unless there is community > support behind SmartScale, it is unlikely that it will ever be adopted > in libjpeg-turbo (I don't have any need for it in my own work, so it > would pretty much have to be a funded development sort of deal.) Thus, > the implementation of the libjpeg v7+ API and ABI would remain just > that: an emulation and not a feature-complete implementation of jpeg-7 > or jpeg-8. Without provable metrics to indicate its usefulness, it's > unlikely that the SmartScale format will garner community support or > gain official adoption as a standard. I don't see any of that happening > as long as the current IJG maintainers take the impolitic attitude that > anyone (including the ISO standards committee) who doesn't recognize the > brilliance of SmartScale is "corrupt" or "ignorant." > > I guess what I'm saying is-- libjpeg-turbo may have reached a point at > which there isn't really a whole lot more we can add to it feature-wise > without either adopting the unproven SmartScale technology or diverging > from IJG to implement some other format, like JPEG XR. Personally, I > feel that both would be out of scope for what is still, at the end of > the day, a turbo baseline JPEG library. I've always believed that new > formats should be implemented by a new library. The libjpeg API is > dated and really ill-equipped to handle new formats, which is why these > API/ABI incompatibilities keep popping up with the IJG's software. > > However, I want this project to be whatever the community wants it to > be. I don't think we're well-positioned to be a haven for new formats, > but if enough people are interested in one that they want to either pay > for the implementation or contribute code, I'm definitely open to that. > "Keep things the way they are" is also a perfectly acceptable answer, > as is "continue focusing on baseline and coming up with new ways to make > it faster." > > Comments encouraged. > > DRC > --end-- > > FYI: libjpeg 9 was released today > http://www.h-online.com/open/news/item/Libjpeg-9-improves-lossless-JPEG-compression-1783311.html -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg-turbo API/ABI bump in F19 (transition from jpeg6 to jpeg8 API/ABI)
On Thu, Oct 18, 2012 at 02:51:01PM -0700, Adam Williamson wrote: > On Thu, 2012-10-18 at 16:43 +0200, Adam Tkac wrote: > > On Thu, Oct 18, 2012 at 10:35:56AM -0400, Bill Nottingham wrote: > > > Adam Tkac (at...@redhat.com) said: > > > > I've just created > > > > https://fedoraproject.org/wiki/Features/libjpeg-turbo-jpeg8-ABI page > > > > which > > > > contains plan how to successfully move from current jpeg6 API/ABI to > > > > more recent > > > > jpeg8 API/ABI for Fedora 19. > > > > > > > > All packages which depends on libjpeg.so will have to be rebuilt. Since > > > > I have > > > > provenpackager privileges, I will cook some script which will rebuild > > > > all > > > > pkgs automatically so no action will be required from maintainers. > > > > > > > > If there are no objections against this approach, I will start with > > > > this task > > > > next week. > > > > > > Ouch. I can see a need for a compat library for some period of time here - > > > the jpeg6 API has certainly been around for quite a long while. > > > > Hm, you are probably right. Since libjpeg is widely used, there might be > > some proprietary > > apps which require it. > > Yeah, I'm with Bill. I note you listed this as the 'contingency plan' > for the feature: > > Contingency Plan > > Create libjpeg-turbo-compat and libjpeg-turbo-compat-devel libraries > with jpeg6 API/ABI and ship them in distro. > > I'd suggest you should just make it a plan from the start to have the > -compat library available as part of the feature (so, really, just drop > step 4 of 'scope'), and have the 'contingency plan' be 'abandon ship and > go back to building with the jpeg6 API'. I agree with this plan and modified the feature page appropriately. Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg-turbo API/ABI bump in F19 (transition from jpeg6 to jpeg8 API/ABI)
On Thu, Oct 18, 2012 at 10:35:56AM -0400, Bill Nottingham wrote: > Adam Tkac (at...@redhat.com) said: > > I've just created > > https://fedoraproject.org/wiki/Features/libjpeg-turbo-jpeg8-ABI page which > > contains plan how to successfully move from current jpeg6 API/ABI to more > > recent > > jpeg8 API/ABI for Fedora 19. > > > > All packages which depends on libjpeg.so will have to be rebuilt. Since I > > have > > provenpackager privileges, I will cook some script which will rebuild all > > pkgs automatically so no action will be required from maintainers. > > > > If there are no objections against this approach, I will start with this > > task > > next week. > > Ouch. I can see a need for a compat library for some period of time here - > the jpeg6 API has certainly been around for quite a long while. Hm, you are probably right. Since libjpeg is widely used, there might be some proprietary apps which require it. In my opinion we can just ship compat libjpeg.so.* without development files for some time. Or do we need devel files as well? Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
libjpeg-turbo API/ABI bump in F19 (transition from jpeg6 to jpeg8 API/ABI)
Hello all, I've just created https://fedoraproject.org/wiki/Features/libjpeg-turbo-jpeg8-ABI page which contains plan how to successfully move from current jpeg6 API/ABI to more recent jpeg8 API/ABI for Fedora 19. All packages which depends on libjpeg.so will have to be rebuilt. Since I have provenpackager privileges, I will cook some script which will rebuild all pkgs automatically so no action will be required from maintainers. If there are no objections against this approach, I will start with this task next week. Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Where document service which is disabled after F16->F17 upgrade via yum
Hello all, named service is disabled after F16->F17 update via yum due to initscripts->systemd conversion. It wasn't possible to keep it enabled when was due to too many differences between initscripts and systemd unit files. As written in https://bugzilla.redhat.com/show_bug.cgi?id=808889, this backward incompatibility should be documented somewhere but I'm not sure where. Can you please point me where should I document it? Thank you in advance. Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is FAS (Fedora Account System) broken?
On 11/12/2011 09:58 PM, Toshio Kuratomi wrote: > On Fri, Nov 11, 2011 at 08:10:09PM +0100, Gregor Tätzner wrote: >> Am Freitag, 11. November 2011, 10:47:12 schrieb Adam Tkac: >>> Hello, >>> >>> today I tried to upload new bind tarball via `fedpkg new-sources` >>> command but it failed with >>> "pycurl.error: (60, 'Peer certificate cannot be authenticated with given >>> CA certificates')" error. >> I have a similar problem when working with git - F16 updates-testing: >> git fetch >> error: Peer certificate cannot be authenticated with given CA certificates >> while >> accessing https://brum...@github.com...fatal: HTTP request failed >> > These seem to be a problem with the F16 nss update that is in > updates-testing. Downgrading from that should make this work. > > > https://admin.fedoraproject.org/updates/FEDORA-2011-15612 > > -Toshio It was nss issue, thanks for the hint! A -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is FAS (Fedora Account System) broken?
On 11/11/2011 12:11 PM, Michael Schwendt wrote: > On Fri, 11 Nov 2011 10:17:20 + (UTC), AR (Andre) wrote: > >> Adam Tkac redhat.com> writes: >> >>> today I tried to upload new bind tarball via `fedpkg new-sources` >>> command but it failed with >>> "pycurl.error: (60, 'Peer certificate cannot be authenticated with given >>> CA certificates')" error. >> I saw the same error trying to use fedora-easy-karma in F16. >> >> https://bugzilla.redhat.com/show_bug.cgi?id=752990 > Is this including updates from > https://admin.fedoraproject.org/updates/FEDORA-2011-15056 > ? > > Can you reproduce after downgrading the packages mentioned in there? This update is out for quite time and yesterday I was able to upload & build git pkg. None of those pkgs were updated today and per my /var/log/yum.log no related package was updated. Regards, Adam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Is FAS (Fedora Account System) broken?
Hello,
today I tried to upload new bind tarball via `fedpkg new-sources`
command but it failed with
"pycurl.error: (60, 'Peer certificate cannot be authenticated with given
CA certificates')" error.
I though there is problem with my ~/.fedora* certificates but after
inspection all fedora* commands (fedora-cert -v, fedora-cert -n,
fedora-packager-setup) fails with the same error, example:
$ fedora-packager-setup
Setting up Fedora packager environment
You need a client certificate from the Fedora Account System, lets get
one now
FAS Username: atkac
FAS Password:
Traceback (most recent call last):
File "/usr/bin/fedora-packager-setup", line 148, in
main()
File "/usr/bin/fedora-packager-setup", line 112, in main
fedora_cert.create_user_cert()
File "/usr/lib/python2.7/site-packages/fedora_cert/__init__.py", line
96, in create_user_cert
cert = fas.user_gencert()
File "/usr/lib/python2.7/site-packages/fedora/client/fas2.py", line
565, in user_gencert
request = self.send_request('user/dogencert', auth=True)
File "/usr/lib/python2.7/site-packages/fedora/client/baseclient.py",
line 344, in send_request
auth_params=auth_params, retries=retries)
File "/usr/lib/python2.7/site-packages/fedora/client/proxyclient.py",
line 380, in send_request
request.perform()
pycurl.error: (60, 'Peer certificate cannot be authenticated with given
CA certificates')
Is anyone experiencing same issue? I'm using up2date F16 system.
Regards, Adam
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for dnssec-triggerd alpha testers!
On 09/20/2011 05:19 PM, Dan Williams wrote: > On Sat, 2011-09-17 at 14:00 -0400, Paul Wouters wrote: >> Hi developers of NM and Fedora, >> >> We are trying to get DNSSEC validation on the end nodes. One way of doing >> that is to run a caching resolver on every host, but that strains the >> DNS infrastructure because all DNS caches would be circumvented. Since >> DNSSEC data is signed, you can obtain it via "insecure channels" and then >> validate it. So we want to try and use the DHCP obtained DNS caches as much >> as possible. >> >> However, there are many networks out there that mess with DNS, and sometimes >> we have to accept fake DNS to get past hotspot/login pages. Sometimes the >> DNS proxies are broken for DNSSEC and we would prefer to run the queries >> ourselves to the authoritative nameservers without using the broken caching >> middle layer. >> >> This is where "dnssec-trigger" comes in. Users run a local validating >> resolver with DNSSEC support (unbound) that can be dynamically reconfigured >> to use different forwarders. dnssec-triggerd checks the DNS path by sending >> a query to a root name server (via the caching resolver or directly) and >> determines if the DHCP obtained DNS servers can be used, or if unbound should >> attempt it directly. Or in the worst case, if DNS should be disabled >> completely >> because it is proven untrusted. >> >> dnssec-trigger consists of NetworkManager hooks, a daemon that rewrites >> resolv.conf and signals unbound, and a gnome applet to show the user the >> DNSSEC status and to warn the user if the network is (too?) unsafe to use. > We can do a much better job of NM integration here. We've already got a > DNS local-caching plugin for dnsmasq, but that doesn't do IPv6 as well. > We can easily create one for unbound. I tried to do one for bind, but > bind's config format is arcane enough that I gave up trying to get it to > do what I needed (local caching nameserver). NM handles rewriting > resolv.conf too, so that would no longer be required here. Another way is to use unbound/bind default configuration files and don't pass NM-generated configs. This way you (and other NM developers) doesn't have to know unbound/bind configuration details. Next advantage is that enthusiastic users and admins can modify unbound/bind configuration without touching NM. By default, both bind and unbound are installed as DNSSEC-validating local resolvers so NM can only spawn unbound/bind. > > Also, I saw mention of "DHCP obtained DNS caches" at the top of the > mail; can somebody provide a pointer to how that works? It's something > we should also expose via NM. NM already lets clients access all the > DHCP-provided options via the D-Bus interface, but if this requires the > DHCP client to request specific options from the server, that's > something NM would want to know as well. With "DHCP obtained DNS caches" Paul probably meant the nameservers which you got via DHCP (aka ISP's nameservers). Those servers perform caching so local unbound/bind will use them and there won't be increased DNS traffic over the Internet due bypassing those caches. >> We'd love to hear from Fedora people how well this integrates and works in >> various hotspot scenarios. We'd love to hear from NM developers to see if >> the hooking have all been done in proper ways. > Yeah, a DNS plugin would be the best way to go here. I've already > implemented a local caching DNS plugin for dnsmasq, including reverse > resolution for IPv4 addresses so that stuff like VPN IP lookups work > correctly when they are in-use. I can provide pointers on how to set up > a new DNS plugin, but the existing ones are here: > > http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/dns-manager I just checked the NetworkManager/src/dns-manager/nm-dns-bind.c and this plugin already does nearly everything what we need (it spawns named and catches important info from DHCP). With little hacking I'm sure we can modify it to serve us as we need. Regards, Adam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for dnssec-triggerd alpha testers!
On 09/17/2011 08:00 PM, Paul Wouters wrote: > Hi developers of NM and Fedora, > > We are trying to get DNSSEC validation on the end nodes. One way of doing > that is to run a caching resolver on every host, but that strains the > DNS infrastructure because all DNS caches would be circumvented. Since > DNSSEC data is signed, you can obtain it via "insecure channels" and then > validate it. So we want to try and use the DHCP obtained DNS caches as much > as possible. > > However, there are many networks out there that mess with DNS, and sometimes > we have to accept fake DNS to get past hotspot/login pages. Sometimes the > DNS proxies are broken for DNSSEC and we would prefer to run the queries > ourselves to the authoritative nameservers without using the broken caching > middle layer. > > This is where "dnssec-trigger" comes in. Users run a local validating > resolver with DNSSEC support (unbound) that can be dynamically reconfigured > to use different forwarders. dnssec-triggerd checks the DNS path by sending > a query to a root name server (via the caching resolver or directly) and > determines if the DHCP obtained DNS servers can be used, or if unbound should > attempt it directly. Or in the worst case, if DNS should be disabled > completely > because it is proven untrusted. > > dnssec-trigger consists of NetworkManager hooks, a daemon that rewrites > resolv.conf and signals unbound, and a gnome applet to show the user the > DNSSEC status and to warn the user if the network is (too?) unsafe to use. > > We'd love to hear from Fedora people how well this integrates and works in > various hotspot scenarios. We'd love to hear from NM developers to see if > the hooking have all been done in proper ways. > Hello Paul, this is a great idea and work. We talked (inside Red Hat) about similar approach how to secure the clients but this proposal is better, ready for use, and I like it. The only one question for discussion is if we should "disable DNSSEC when it is proven untrusted". Previously, I tended to use similar approach but after discussion with security guys I think we shouldn't go this way. The main problem is how to differ between misconfigured ISP's proxy/server which strips DNSSEC data (good example is bind 9.3, still widely used, and it's default "dnssec-enable no;" setting) and MITM attack which strips DNSSEC data. Due this I think we should always enforce DNSSEC, user should explicitly modify unbound or riggerd configuration to disable DNSSEC. Otherwise we can end with same situation as with X.509 certs on the Internet - when cert is bad, everyone automatically accept it and there is no security benefit. Another argument for enforcing DNSSEC is that in future (well, I believe :) ) DNS will be used as storage for X.509 certs, SSHFP records and other stuff. If we adopt "leisure" approach (automatic disabling of DNSSEC or ability to "click" somewhere on the applet to disable DNSSEC) then we can end in the same situation as we are currently with X.509 certs. Everyone will simply click on "disable DNSSEC" button or, when MITM attack will be in progress, DNSSEC will be automatically disabled. This will degrade DNSSEC benefits. When we enforce DNSSEC there will be definitely some users which will end with "broken" DNS but this is a great opportunity how to really secure end nodes. Comments are welcomed. Regards, Adam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: advice on libjpeg
Hello Ankur, our current libjpeg-turbo build in Fedora is 100% API/ABI compatible with former ijg libjpeg 6b. I would recommend to simply package the application and try to build it against libjpeg-turbo. If something fails, feel free to send me a mail with details and I will try to help you. Regards, Adam On 08/09/2011 04:28 PM, Ankur Sinha wrote: > Hello, > > One of the packages[2] I am trying to package requires libjpeg from the > ijg[1]. Since fedora is using libjpeg-turbo, I wanted to know if libjpeg > and libjpeg are installable in parallel? Should I package libjpeg as a > build dep, or should I be trying to patch the source to use > libjpeg-turbo? > > [1] http://libjpeg.sourceforge.net/ > [2] http://ingenium.home.xs4all.nl/dicom.html > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
systemd & vnc - how to properly handle /etc/sysconfig/vncservers
Hello all, I'm trying to package systemd service file for tigervnc server and to find a solution how to make it backward-compatible with current format of the /etc/sysconfig/vncservers. Current /etc/sysconfig/vncservers has following options (example): VNCSERVERS="1:user1 2:user2" VNCSERVERARGS[1]="-arg1 -arg2" VNCSERVERARGS[2]="-arg3 -arg4" With arguments above traditional SysV initscript starts Xvnc instances for displays :1 and :2 which run under appropriate user (user1 and user2 in this example) and passes arguments to Xvnc. If I understand systemd correctly it's a bad idea to try start multiple instances of the Xvnc via one systemd service file - I'm fine with this, admin will have to create multiple service files for multiple Xvnc instances. However is there any way how to extract correct bits from the sysconfig file? I think it's easy with the VNCSERVERARGS[num] variable but I don't have any idea how to extract proper user from the VNCSERVERS variable. Does systemd support some kind of regex matching for the $ variables got from sysconfig files? Any idea how to handle the VNCSERVERS argument in backward-compatible way is welcomed, otherwise I will simply drop sysconfig support at all in the service file and admin will have to create /etc/systemd/system/ service files with appropriate params. Thanks in advance for your comments. Regards, Adam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: something changed with provides/requires (probably new rpm???)
On Mon, Jan 24, 2011 at 11:07:40PM +0100, Adrian Reber wrote: > On Mon, Jan 24, 2011 at 09:50:57PM +0100, Michael Schwendt wrote: > > > Is this a bug in the spec file or in rpm? > > > > $ rpmls -p bind-libs-lite-9.7.3-0.4.b1.fc15.i686.rpm > > lrwxrwxrwx /usr/lib/libdns-export.so.69 > > -rw-r--r-- /usr/lib/libdns-export.so.69.1.0 > > lrwxrwxrwx /usr/lib/libirs-export.so.60 > > -rw-r--r-- /usr/lib/libirs-export.so.60.0.0 > > lrwxrwxrwx /usr/lib/libisc-export.so.62 > > -rw-r--r-- /usr/lib/libisc-export.so.62.1.0 > > lrwxrwxrwx /usr/lib/libisccfg-export.so.62 > > -rw-r--r-- /usr/lib/libisccfg-export.so.62.0.0 > > > > They ought to be chmod +x. > > Thanks! That helped. > > Adrian This is now fixed in bind-9.7.3-0.5.rc1.fc15. Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Arithmetic coding in Fedora libjpeg (bug #639531)
On Sun, Oct 03, 2010 at 01:52:28PM +0530, Mukund Sivaraman wrote: > Hi all > > In reply to Gregory Maxwell: > >> It's well known around the Internet that to achieve compatibility you > >> should be conservative in what you send and liberal in what you > >> accept. Applied to JPEG: Use only Huffman coding when encoding ? > >> except maybe if you know that all recipients can handle arithmetic > >> coding ? but support both encodings when decoding. > > >Absolutely. This is an excellent argument and I think is sufficient to > >justify the inclusion alone. > > Thank you everyone for the replies. I did not know earlier that Fedora > was switching to libjpeg-turbo. I have created a new bug now: > > https://bugzilla.redhat.com/show_bug.cgi?id=639672 > Add support for decoding arithmetic coded files in libjpeg-turbo > > It contains a patch against upstream libjpeg-turbo HEAD, and the patch > has been submitted upstream too: > > https://sourceforge.net/tracker/?func=detail&aid=3080268&group_id=303195&atid=1278160 > > This patch has been tested against some arithmetic coded images. > > I wish libjpeg-turbo also accepts to include creating arithmetic coded > images too, as the project is not really going to affect creation of > such images if an application wants to do so. But this can be saved > for another argument, and doesn't stand in the way of decode support. We decided to accept arithmetic method into libjpeg-turbo upstream as soon as Fedora legal says it's fine. Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-DBD-SQLite] Fix testsuite to run with the latest sqlite (bugs.debian.org/591111).
commit acf6c396c24366416725a0b0d1dc32c98b80a94b
Author: Adam Tkac
Date: Tue Aug 24 15:35:41 2010 +0200
Fix testsuite to run with the latest sqlite (bugs.debian.org/59).
Signed-off-by: Adam Tkac
...-clean-temporary-files-in-child-processes.patch | 49
perl-DBD-SQLite.spec |7 ++-
2 files changed, 55 insertions(+), 1 deletions(-)
---
diff --git a/0001-Don-t-clean-temporary-files-in-child-processes.patch
b/0001-Don-t-clean-temporary-files-in-child-processes.patch
new file mode 100644
index 000..6ef1d4b
--- /dev/null
+++ b/0001-Don-t-clean-temporary-files-in-child-processes.patch
@@ -0,0 +1,49 @@
+From 89c8a661e61bbf0fb1d1e5050262390649e13f2a Mon Sep 17 00:00:00 2001
+From: Niko Tyni
+Date: Mon, 23 Aug 2010 08:15:15 +0300
+Subject: [PATCH] Don't clean temporary files in child processes
+
+As of SQLite 3.7.0, write locks try to stat() the database
+file and fail with a 'Disk I/O error' if it is missing. This
+breaks those tests that fork child processes (namely 08_busy.t
+and t/28_schemachange.t) because the child process removes
+the database file in the END block.
+
+The fix is to disable the clean() function for child processes.
+
+See <http://bugs.debian.org/59>
+---
+ t/lib/Test.pm |3 +++
+ 1 files changed, 3 insertions(+), 0 deletions(-)
+
+diff --git a/t/lib/Test.pm b/t/lib/Test.pm
+index 80e50ce..8d1be25 100644
+--- a/t/lib/Test.pm
b/t/lib/Test.pm
+@@ -7,6 +7,7 @@ use Exporter ();
+ use File::Spec ();
+ use Test::More ();
+
++my $parent;
+ use vars qw{$VERSION @ISA @EXPORT @CALL_FUNCS};
+ BEGIN {
+ $VERSION = '1.29';
+@@ -15,6 +16,7 @@ BEGIN {
+
+ # Allow tests to load modules bundled in /inc
+ unshift @INC, 'inc';
++ $parent = $$;
+ }
+
+ # Always load the DBI module
+@@ -22,6 +24,7 @@ use DBI ();
+
+ # Delete temporary files
+ sub clean {
++ return if $$ != $parent;
+ unlink( 'foo' );
+ unlink( 'foo-journal' );
+ }
+--
+1.7.1
+
diff --git a/perl-DBD-SQLite.spec b/perl-DBD-SQLite.spec
index 7c61aad..8f10c0f 100644
--- a/perl-DBD-SQLite.spec
+++ b/perl-DBD-SQLite.spec
@@ -1,6 +1,6 @@
Name: perl-DBD-SQLite
Version:1.29
-Release:3%{?dist}
+Release:4%{?dist}
Summary:SQLite DBI Driver
Group: Development/Libraries
@@ -8,6 +8,7 @@ License:GPL+ or Artistic
URL:http://search.cpan.org/dist/DBD-SQLite/
Source0:
http://search.cpan.org/CPAN/authors/id/A/AD/ADAMK/DBD-SQLite-%{version}.tar.gz
patch0: perl-DBD-SQLite-bz543982.patch
+Patch1: 0001-Don-t-clean-temporary-files-in-child-processes.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
# if sqlite >= 3.1.3 then
@@ -35,6 +36,7 @@ libraries.
%prep
%setup -q -n DBD-SQLite-%{version}
%patch0 -p1
+%patch1 -p1
%build
CFLAGS="$RPM_OPT_FLAGS" %{__perl} Makefile.PL INSTALLDIRS=vendor
@@ -67,6 +69,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Tue Aug 24 2010 Adam Tkac - 1.29-4
+- fix testsuite to run with the latest sqlite (bugs.debian.org/59)
+
* Tue Aug 24 2010 Adam Tkac - 1.29-3
- rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Wrong packages in F14/rawhide composes
On Tue, Aug 24, 2010 at 01:54:25PM +0100, Paul Howarth wrote: > On 24/08/10 13:45, Adam Tkac wrote: > > Hello, > > > > it seems there are some issues with recent mass rebuilds for perl > > 5.12.0 in F14/rawhide. > > > > Some packages were rebuilt against new perl and then were built again. > > However koji exposes only the older build. > > > > This is list of affected packages which I discovered during work on > > FES ticket https://fedorahosted.org/fedora-engineering-services/ticket/35: > > > > nagios, perl-DBD-SQLite, perl-HTTP-DAV, perl-Net-STOMP-Client, > > perl-PAR and perl-PAR-Packer. > > > > For example when I visit koji via https://kojiweb.fedoraproject.org/koji > > web interface and search for example for "nagios" package, then I can > > see there is "nagios-3.2.1-5.fc14" package with dist-f14 tag. However > > when I run "$ koji latest-pkg dist-f14 nagios" I get: > > > > Build Tag Built by > > > > nagios-3.2.1-4.fc14 dist-f14 mmaslano > > > > This is really odd, what would be the best way to fix this issue? > > Rebuild of affected packages? > > Yes, because the "newer" builds have probably been built against the > older perl. Right you are, thanks for the pointing out the root cause. I will rebuild discussed packages. Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Wrong packages in F14/rawhide composes
Hello, it seems there are some issues with recent mass rebuilds for perl 5.12.0 in F14/rawhide. Some packages were rebuilt against new perl and then were built again. However koji exposes only the older build. This is list of affected packages which I discovered during work on FES ticket https://fedorahosted.org/fedora-engineering-services/ticket/35: nagios, perl-DBD-SQLite, perl-HTTP-DAV, perl-Net-STOMP-Client, perl-PAR and perl-PAR-Packer. For example when I visit koji via https://kojiweb.fedoraproject.org/koji web interface and search for example for "nagios" package, then I can see there is "nagios-3.2.1-5.fc14" package with dist-f14 tag. However when I run "$ koji latest-pkg dist-f14 nagios" I get: Build Tag Built by nagios-3.2.1-4.fc14 dist-f14 mmaslano This is really odd, what would be the best way to fix this issue? Rebuild of affected packages? Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Engineering Services - Help Wanted!
On Fri, Aug 13, 2010 at 09:48:56AM -0500, Mike McGrath wrote: > Do you like fixing things but don't care what? Hello, may I ask you about FES workflow? Should FES members (with provenpackager perms, for example) push fixes directly to git and close bugs in bugzilla or should they rather put patches into bugzilla and let package maintainers push the patches? Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Integrity protection of fetches
On Fri, Aug 06, 2010 at 12:54:23PM +0200, Till Maas wrote: > On Fri, Aug 06, 2010 at 04:31:00AM -0500, Mike McGrath wrote: > > On Fri, 6 Aug 2010, Till Maas wrote: > > > > > On Thu, Aug 05, 2010 at 04:32:36PM -0500, Mike McGrath wrote: > > > > On Thu, 5 Aug 2010, Till Maas wrote: > > > > > > > > Yes ssh is secure if used properly. To get the proper known_hosts > > > > > entry, > > > > > one has to download https://admin.fedoraproject.org/ssh_known_hosts > > > > > btw. > > > > > > > > > > > > > We also use SSHFP records for those of you that want to enable > > > > VerifyHostKeyDNS yes in their ~/.ssh/config files. Not all of our hosts > > > > have it but many of our 'user' based external hosts do (pkgs, > > > > fedorapeople, fedorahosted, etc) > > > > > > Afaik the SSHFP records are not protected against tampering by an MITM > > > attacker. > > > > > > > They're better then ssh alone. They're only used for the first initation. > > So you'd have to be MITM'ed on the first connection in which case you're > > right, they wouldn't protect against that. > > Afaik using the SSHFP records make SSH not warn the user that the host > key is not verified. If SSH would e.g. warn that the host key is > unknown, but at least matches the SSHFP record, then it might be a > little better. But actually it makes MITM attacks easier, because if one > tampers the DNS response and the SSH connection, then the user does not SSH considers SSHFP valid only when it is verified via DNSSEC. So it's not possible to perform DNS spoofing (or MITM) when DNSSEC is used. When ssh receives SSHFP record which is not verified then it falls back to "standard" (i.e. yes/no method) verification. > even get a warning on the first attempt, making the situation even > worse IMHO. > > And SSH is only vulnerable to MITM attacks on the first connection in > general and I guess that SSHFP records are not used anymore after the > first connection. What would they be good for when the host key is > already known to SSH? SSHFP records are useless when fingerprint is already known. Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg-turbo conflicts in rawhide
On Thu, Jul 01, 2010 at 09:55:08PM +0800, Chen Lei wrote: > 2010/7/1 Adam Tkac : > > On Tue, Jun 29, 2010 at 11:31:45PM -0400, Rich Mattes wrote: > >> Hi all, > > > > Hello, > > > >> I'm trying to build a package that has a BuildRequires: libjpeg-devel in > >> Rawhide [1]. I get a message in root.log that libjpeg-turbo-devel > >> obsoletes libjpeg-devel, so yum pulls in libjpeg-turbo-devel instead. > >> Unfortunately, when it pulls in dependencies for my other BuildRequires, > >> it's trying to pull in libjpeg and libjpeg-turbo, and I get a conflict > >> since they both provide libjpeg.so.62.0.0 > >> > >> The only thing I can think of is that one of the packages I'm requiring > >> has an explicit dep on libjpeg (I'm about to investigate which). For > >> the time being, is there any to work around this? > > > > I read this thread and > > https://bugzilla.redhat.com/show_bug.cgi?id=609224 and I see two > > reasonable solutions for this problem: > > > > 1. Add Obsoletes/Provides libjpeg directly to libjpeg-turbo package > > which contains only libjpeg.so.62*. I believe this will solve both > > update and buildroot problems. However it also means all users of > > libjpeg programs (djpeg, cjpeg and friends) will need to manually > > install libjpeg-turbo-tools > > > > 2. Merge both libjpeg-turbo-utils and libjpeg-turbo to one package, as > > done in libjpeg. > > > > I must admit I like the first solution. People usually needs only > > libjpeg.so, not programs. People which need libjpeg programs can > > easily install libjpeg-turbo-tools package themselves, this > > "incompatibility" seems acceptable for me in development branch. > > > > What is your opinion about this proposal? > > > > Regards, Adam > > > > -- > Only three packages in the rawhide depend on -utils: > > renrot > gallery2-jpegtran > gocr Thanks for your inspection. Those packages can be very easily fixed by adding "Requires: /usr/bin/djpeg" to them. This change will be compatible with both former "monolitic" libjpeg and new libjpeg-turbo-utils. I will do this myself. Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg-turbo conflicts in rawhide
On Tue, Jun 29, 2010 at 11:31:45PM -0400, Rich Mattes wrote: > Hi all, Hello, > I'm trying to build a package that has a BuildRequires: libjpeg-devel in > Rawhide [1]. I get a message in root.log that libjpeg-turbo-devel > obsoletes libjpeg-devel, so yum pulls in libjpeg-turbo-devel instead. > Unfortunately, when it pulls in dependencies for my other BuildRequires, > it's trying to pull in libjpeg and libjpeg-turbo, and I get a conflict > since they both provide libjpeg.so.62.0.0 > > The only thing I can think of is that one of the packages I'm requiring > has an explicit dep on libjpeg (I'm about to investigate which). For > the time being, is there any to work around this? I read this thread and https://bugzilla.redhat.com/show_bug.cgi?id=609224 and I see two reasonable solutions for this problem: 1. Add Obsoletes/Provides libjpeg directly to libjpeg-turbo package which contains only libjpeg.so.62*. I believe this will solve both update and buildroot problems. However it also means all users of libjpeg programs (djpeg, cjpeg and friends) will need to manually install libjpeg-turbo-tools 2. Merge both libjpeg-turbo-utils and libjpeg-turbo to one package, as done in libjpeg. I must admit I like the first solution. People usually needs only libjpeg.so, not programs. People which need libjpeg programs can easily install libjpeg-turbo-tools package themselves, this "incompatibility" seems acceptable for me in development branch. What is your opinion about this proposal? Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Drop static libjpeg.a library
Hello, As part of the libjpeg-turbo F14 feature (https://fedoraproject.org/wiki/Features/libjpeg-turbo) I would like to drop the libjpeg.a static library. No package in the Fedora uses it so I don't see any reason for its existence. I would like to ask you if you know any external project which will be broken by this step. Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg for F14
On Tue, Jun 01, 2010 at 01:35:20PM +0100, Ilyes Gouta wrote: > Hi, Hello, > I'm still interested in seeing a linjpeg-turbo merger with ijg's own > code base. I'd say that the most performance boost brought in by > libjpeg-turbo is due to the specialized SIMD routines, which > theoretically can be easily merged. libjpeg-turbo has also some > weaknesses such as (as provided from the project's homepage): You are right, it will be better to join forces together with IJG. But as I wrote earlier, libjpeg-turbo is at my opinion far more ahead than IJG's source and is developed in more open-source manner. Additionally, as Tom Lane wrote, current maintainer of the IJG libjpeg doesn't care about API/ABI compatibility much. > 1. Worse chroma upsampling quality, where libjpeg-turbo is favoring > speed over accuracy when upsamling the chroma components This is not enabled by default, you have to explicitly specify this behavior (TJ_FASTUPSAMPLE parameter). > 2. JPEG's standard restart marker aren't properly handled, in favor of > a faster huffman decoding It is handled properly. When libjpeg-turbo hits restart marker then it must use slower huffman decoder which means 15% - 20% performance drop but is still much faster than IJG's libjpeg. > 3. Asymetric performance gain between 32bit and 64bit arch., which > means specific, per arch. code paths and not algorithmic and > architecture wise tweaks that could benefit all the architectures. Yes, usage of SSE is the main reason why libjpeg-turbo is much more faster than libjpeg. But as written on http://libjpeg-turbo.virtualgl.org/About/Performance, 32bit is slower due small number of registers; those registers are allocated by compiler, it's not assembler code, libjpeg-turbo is currently using same ASM code for both x86 and x64. Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg for F14
On Mon, May 31, 2010 at 12:51:56PM -0400, Orcan Ogetbil wrote: > On Mon, May 31, 2010 at 12:16 PM, Adam Tkac wrote: > > On Mon, May 31, 2010 at 05:33:38PM +0200, Adam Tkac wrote: > >> > >> I'm going to create a Fedora feature for this task. > > > > Done. You can check > > http://fedoraproject.org/wiki/Features/libjpeg-turbo. > > > > Thanks. Is there an SRPM we can give it a test? Yes, I just created it, check http://atkac.fedorapeople.org/libjpeg-turbo. I also updated the feature page because no package linked against current libjpeg needs to be rebuilt, libjpeg-turbo is API/ABI compatible. You can simply build & install libjpeg-turbo and you should immediately see performance benefits. If you prefer to test libjpeg-turbo in more conservative way you can build SRPM and then extract libjpeg.so from it (`rpm2cpio libjpeg-turbo.rpm | cpio -id`) and simply LD_PRELOAD it. Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg for F14
On Mon, May 31, 2010 at 06:58:37PM +0100, Ilyes Gouta wrote: > Hi Adam, Hello Ilyes, > > it also contains bunch of > > pure algorithmic enhancements so even if target platform doesn't > > support MMX/SSE libjpeg-turbo is around 25% faster than original libjpeg. > > Can you please give some details on this point? Yes, of course. This topic was discussed on tigervnc-devel ML, check those threads: http://www.mail-archive.com/tigervnc-de...@lists.sourceforge.net/msg00225.html http://www.mail-archive.com/tigervnc-de...@lists.sourceforge.net/msg00403.html As said there, libjpeg-turbo has nearly same performance as Intel's IPP. Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg for F14
On Mon, May 31, 2010 at 05:33:38PM +0200, Adam Tkac wrote: > > I'm going to create a Fedora feature for this task. Done. You can check http://fedoraproject.org/wiki/Features/libjpeg-turbo. Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg for F14
On Tue, May 25, 2010 at 04:47:13PM +0100, Richard W.M. Jones wrote: > On Tue, May 25, 2010 at 04:40:15PM +0100, Ilyes Gouta wrote: > > How about this: since libjpeg is picking momentum and there are > > actually people updating the code base, why not push for a > > libjpeg-turbo merge into the original ijg's code and get Fedora to > > rebase on that unique source instead? > > The problem, as I said before, is that the libjpeg upstream is not > being developed in an open manner. This is pretty big issue. > I've emailed Adam Tkac to bring his attention to this thread (he's > involved with libjpeg-turbo) and hopefully he'll bring some more up to > date information about this matter. Sorry for late response, this mail got lost in my queue. libjpeg-turbo is a fork of the original libjpeg-6b release created and maintained by VirtualGL and TigerVNC developers. Main focus is on performance and API+ABI compatibility with libjpeg. Although libjpeg-turbo contains MMX/SSE acceleration it also contains bunch of pure algorithmic enhancements so even if target platform doesn't support MMX/SSE libjpeg-turbo is around 25% faster than original libjpeg. When SSE is used then libjpeg and libjpeg-turbo performance is simply incomparable. And there are still number of areas for optimizations, for example on we are currently using only half of SSE registers on 64bit platforms. About the merge of this code with the original ijg's code. Yes, I must admit it is possible but personally I don't like it much. In my opinion libjpeg-turbo is far more ahead than libjpeg so it's easier for us to incorporate libjpeg changes to libjpeg-turbo. And I'm not able to find CVS/SVN/git repository of the libjpeg code. In my opinion if will be great benefit for Fedora to simply replace libjpeg by libjpeg-turbo. It works fine on secondary architectures and if processor doesn't support MMX/SSE then it falls back to non-ASM code (which is still faster than libjpeg code, as I wrote above). Btw this library is used since Fedora 11 in tigervnc package for JPEG compression/decompression and it works without any problem on all supported platforms (x86, x86_64, ppc, ppc64) and also on s390(x). So, if I summarize pros and cons for libjpeg-turbo: +: _really_ faster than libjpeg more portable more open than IJG code API/ABI compatible with libjpeg (AFAIK) works on all platforms (not only on SSE capable platforms) -: not developed by IJG :) I'm going to create a Fedora feature for this task. Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: chrony as default NTP client?
On Thu, May 06, 2010 at 01:10:36PM +0200, Miroslav Lichvar wrote: > On Wed, May 05, 2010 at 09:39:52PM -0400, Tom Lane wrote: > > Mail Lists writes: > > > On 05/05/2010 09:35 AM, Miroslav Lichvar wrote: > > >> With the latest improvements in the chrony package related to > > >> NetworkManager and name resolving I think it is now good enough to > > >> replace ntpd in the default configuration and the configurations > > >> supported by system-config-date. > > > > > I think this is a terrible idea. > > > > Yes. I certainly wouldn't use it, and especially object to the proposed > > strong-arm tactics of eliminating all configuration support for ntpd. > > The case for making chrony default is weak enough, and the case for > > throwing roadblocks in the way of people who prefer ntpd is nonexistent. > > I'm not suggesting to remove the ntp support from s-c-d, just to add a > support for chrony and change the dependency to a name provided by > both packages and marking chrony as default in the comps. I would suggest to have only one NTP client in the s-c-d. In my opinion users which use s-c-d won't know what is different between ntpd and chrony. Selection will be only confusing. In my opinion complains about security bugs and stability are quite invalid. It will mean that we should automatically reject all new alternative programs as suspicious and full of bugs. They might be less stable that their widely used friends but they also might be more stable. I don't see this as a valid argument. Maintainer's decisions should be respected in this cases because he is generally the person who knows the package, in this case NTP, well. Especially when he actively maintains it for more than four years. It of course doesn't mean he should drop ntp from distro. It will be here for people who prefer it. "Default" means "this is generally the best", not that "this is the fastest" or "this has the most features" of "this is the most accurate". Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
