[389-devel] Please review: Issue 49237 - deprecation of old libdb
https://pagure.io/389-ds-base/issue/49237 https://pagure.io/389-ds-base/issue/raw/files/e94d4e8aaa9621f96c4301ee3db12c29876c5c749205f7db7da5492fbe9622a5-0001-Ticket-49237-Drop-support-for-libdb-older-than-4.7.patch https://pagure.io/389-ds-base/issue/raw/files/c87637e957a488a0f786edb18ab3d7c15b38fec3d6895b4a18b17a325e170e16-0002-Remove-unused-parameter-from-back-ldbm-dblayer.c.patch The patches themselves remove support of old libdb (< 4.7). However there is still question about code in ldap/servers/slapd/back-ldbm/upgrade.c I haven't touched it because I have no idea which on-disk libdb formats we can assume that users have. Can we, for example, assume that all existing DS installations which will upgrade to current master branch have at least libdb 4 on-disk format and newer? If yes, the upgrade.c code can be cleaned as well. Regards, Adam -- Adam Tkac ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: Issue 49234 - correctly pair dblayer_release_id2entry and dblayer_get_id2entry
https://pagure.io/389-ds-base/issue/49234 https://pagure.io/389-ds-base/issue/raw/files/571347fd5fc794978b3c77d68a86dc5f18b16343377da683cf5ef20d5844d905-0001-Ticket-49234-Don-t-release-id2entry-when-we-didn-t-g.patch Thanks in advance for review -- Adam Tkac ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[perl-GD] Rebuild due to jpeg8-ABI feature drop
commit d4623a84998640c70b7ddabe6e24e67c263fa8d6
Author: Adam Tkac at...@redhat.com
Date: Mon Jan 21 16:05:30 2013 +0100
Rebuild due to jpeg8-ABI feature drop
Signed-off-by: Adam Tkac at...@redhat.com
perl-GD.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-GD.spec b/perl-GD.spec
index ef708d7..e7e7918 100644
--- a/perl-GD.spec
+++ b/perl-GD.spec
@@ -1,6 +1,6 @@
Name: perl-GD
Version:2.46
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Perl interface to the GD graphics library
Group: Development/Libraries
License:GPL+ or Artistic
@@ -73,6 +73,9 @@ base64 t/test.out.3.png_new
%{_mandir}/man3/*.3pm*
%changelog
+* Mon Jan 21 2013 Adam Tkac atkac redhat com - 2.46-2
+- rebuild due to jpeg8-ABI feature drop
+
* Thu Oct 25 2012 Petr Šabata con...@redhat.com - 2.46-1
- 2.46 bump
- Specify all dependencies
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-PDL] Rebuild due to jpeg8-ABI feature drop
commit 1f3dc53f76acaac25a36292c532d359801b20c8e
Author: Adam Tkac at...@redhat.com
Date: Mon Jan 21 16:06:00 2013 +0100
Rebuild due to jpeg8-ABI feature drop
Signed-off-by: Adam Tkac at...@redhat.com
perl-PDL.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-PDL.spec b/perl-PDL.spec
index 07c6b7a..6036a6f 100644
--- a/perl-PDL.spec
+++ b/perl-PDL.spec
@@ -1,6 +1,6 @@
Name: perl-PDL
Version:2.4.10
-Release:5%{?dist}
+Release:6%{?dist}
Summary:The Perl Data Language
Group: Development/Libraries
License:GPL+ or Artistic
@@ -94,6 +94,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Mon Jan 21 2013 Adam Tkac atkac redhat com - 2.4.10-6
+- rebuild due to jpeg8-ABI feature drop
+
* Fri Dec 21 2012 Adam Tkac atkac redhat com - 2.4.10-5
- rebuild against new libjpeg
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Tk] Rebuild due to jpeg8-ABI feature drop
commit babf8260e77872f335691168a240e45e6dbe496b
Author: Adam Tkac at...@redhat.com
Date: Mon Jan 21 16:06:04 2013 +0100
Rebuild due to jpeg8-ABI feature drop
Signed-off-by: Adam Tkac at...@redhat.com
perl-Tk.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Tk.spec b/perl-Tk.spec
index 52bd379..b95b3ad 100644
--- a/perl-Tk.spec
+++ b/perl-Tk.spec
@@ -4,7 +4,7 @@
Name: perl-Tk
# devel version fix for perl 5.14:
Version:804.030
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Perl Graphical User Interface ToolKit
Group: Development/Libraries
@@ -119,6 +119,9 @@ find __demos/ -type f -exec chmod -x {} \;
%changelog
+* Mon Jan 21 2013 Adam Tkac atkac redhat com - 804.030-3
+- rebuild due to jpeg8-ABI feature drop
+
* Fri Dec 21 2012 Adam Tkac atkac redhat com - 804.030-2
- rebuild against new libjpeg
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
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: 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
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: 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 at...@redhat.com 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
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: 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: Fwd: [Libjpeg-turbo-users] jpeg-9, API/ABI compatibility, and the future role of this project
, 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
[perl-PDL] rebuild against new libjpeg
commit 56f78c75af4d76038105366172152c20611dbdbf
Author: Adam Tkac at...@redhat.com
Date: Fri Dec 21 19:02:20 2012 +0100
rebuild against new libjpeg
Signed-off-by: Adam Tkac at...@redhat.com
perl-PDL.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-PDL.spec b/perl-PDL.spec
index a7915b7..07c6b7a 100644
--- a/perl-PDL.spec
+++ b/perl-PDL.spec
@@ -1,6 +1,6 @@
Name: perl-PDL
Version:2.4.10
-Release:4%{?dist}
+Release:5%{?dist}
Summary:The Perl Data Language
Group: Development/Libraries
License:GPL+ or Artistic
@@ -94,6 +94,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Fri Dec 21 2012 Adam Tkac atkac redhat com - 2.4.10-5
+- rebuild against new libjpeg
+
* Tue Sep 04 2012 Petr Pisar ppi...@redhat.com - 2.4.10-4
- Disable Proj support (bug #839651)
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Tk] rebuild against new libjpeg
commit ba34b0e6e68a9f196992db009f17a9fffa461632
Author: Adam Tkac at...@redhat.com
Date: Fri Dec 21 19:02:47 2012 +0100
rebuild against new libjpeg
Signed-off-by: Adam Tkac at...@redhat.com
perl-Tk.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Tk.spec b/perl-Tk.spec
index 68d7247..52bd379 100644
--- a/perl-Tk.spec
+++ b/perl-Tk.spec
@@ -4,7 +4,7 @@
Name: perl-Tk
# devel version fix for perl 5.14:
Version:804.030
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Perl Graphical User Interface ToolKit
Group: Development/Libraries
@@ -119,6 +119,9 @@ find __demos/ -type f -exec chmod -x {} \;
%changelog
+* Fri Dec 21 2012 Adam Tkac atkac redhat com - 804.030-2
+- rebuild against new libjpeg
+
* Wed Aug 29 2012 Jitka Plesnikova jples...@redhat.com - 804.030-1
- 804.030 bump, update source link
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-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
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
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
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
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 module
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: 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 atkac at 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
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: 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: 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
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=detailaid=3080268group_id=303195atid=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
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: 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
[perl-DBD-SQLite] Fix testsuite to run with the latest sqlite (bugs.debian.org/591111).
commit acf6c396c24366416725a0b0d1dc32c98b80a94b
Author: Adam Tkac at...@redhat.com
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 at...@redhat.com
...-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 nt...@debian.org
+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 atkac redhat com - 1.29-4
+- fix testsuite to run with the latest sqlite (bugs.debian.org/59)
+
* Tue Aug 24 2010 Adam Tkac atkac redhat com - 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
[perl-DBICx-TestDatabase/f14/master] Rebuild to ensure F14 has higher NVR than F13.
Summary of changes: 2f6a8f6... Rebuild to ensure F14 has higher NVR than F13. (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-DBD-SQLite] Rebuild.
commit 5be71f9381be23b134d069133b67b968e189cf3b
Author: Adam Tkac at...@redhat.com
Date: Tue Aug 24 15:11:45 2010 +0200
Rebuild.
Signed-off-by: Adam Tkac at...@redhat.com
perl-DBD-SQLite.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-DBD-SQLite.spec b/perl-DBD-SQLite.spec
index 53cb48c..7c61aad 100644
--- a/perl-DBD-SQLite.spec
+++ b/perl-DBD-SQLite.spec
@@ -1,6 +1,6 @@
Name: perl-DBD-SQLite
Version:1.29
-Release:2%{?dist}
+Release:3%{?dist}
Summary:SQLite DBI Driver
Group: Development/Libraries
@@ -67,6 +67,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Tue Aug 24 2010 Adam Tkac atkac redhat com - 1.29-3
+- rebuild
+
* Mon Jun 28 2010 Tom spot Callaway tcall...@redhat.com - 1.29-2
- fix description/summary
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-DBD-SQLite/f14/master] Rebuild.
Summary of changes: 5be71f9... Rebuild. (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-HTTP-DAV/f14/master] Rebuild.
Summary of changes: ed5de31... Rebuild. (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-STOMP-Client] Rebuild.
commit 363b0436060d015ab0328b9d46242bb8ed3be685
Author: Adam Tkac at...@redhat.com
Date: Tue Aug 24 15:15:56 2010 +0200
Rebuild.
Signed-off-by: Adam Tkac at...@redhat.com
perl-Net-STOMP-Client.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Net-STOMP-Client.spec b/perl-Net-STOMP-Client.spec
index 267cbc1..bcfb739 100644
--- a/perl-Net-STOMP-Client.spec
+++ b/perl-Net-STOMP-Client.spec
@@ -1,6 +1,6 @@
Name: perl-Net-STOMP-Client
Version:0.9.2
-Release:1%{?dist}
+Release:2%{?dist}
Summary:STOMP object oriented client module
License:GPL+ or Artistic
Group: Development/Libraries
@@ -50,6 +50,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Tue Aug 24 2010 Adam Tkac atkac redhat com - 0.9.2-2
+- rebuild
+
* Tue Jun 08 2010 Steve Traylen steve.tray...@cern.ch - 0.9.2-1
- New upstream 0.9.2.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-PAR] Rebuild.
commit e0ac77e5fe991de7063aaa88c8f980184dc70cc7
Author: Adam Tkac at...@redhat.com
Date: Tue Aug 24 15:16:58 2010 +0200
Rebuild.
Signed-off-by: Adam Tkac at...@redhat.com
perl-PAR.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-PAR.spec b/perl-PAR.spec
index 817a62a..fa7d29d 100644
--- a/perl-PAR.spec
+++ b/perl-PAR.spec
@@ -1,6 +1,6 @@
Name: perl-PAR
Version:1.000
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Perl Archive Toolkit
License:GPL+ or Artistic
Group: Development/Libraries
@@ -51,6 +51,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Tue Aug 24 2010 Adam Tkac atkac redhat com - 1.000-2
+- rebuild
+
* Fri Jun 11 2010 Petr Sabata psab...@redhat.com - 1.000-1
- Update to the latest release.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-STOMP-Client/f14/master] Rebuild.
Summary of changes: 363b043... Rebuild. (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-PAR/f14/master] Rebuild.
Summary of changes: e0ac77e... Rebuild. (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-PAR-Packer] Rebuild.
commit 92bee8a02f63b01bcf833c8c5bf6bf61a731c353
Author: Adam Tkac at...@redhat.com
Date: Tue Aug 24 15:18:23 2010 +0200
Rebuild.
Signed-off-by: Adam Tkac at...@redhat.com
perl-PAR-Packer.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-PAR-Packer.spec b/perl-PAR-Packer.spec
index eb69d7d..c4d703e 100644
--- a/perl-PAR-Packer.spec
+++ b/perl-PAR-Packer.spec
@@ -1,6 +1,6 @@
Name: perl-PAR-Packer
Version:1.005
-Release:1%{?dist}
+Release:2%{?dist}
Summary:PAR Packager
License:GPL+ or Artistic
Group: Development/Libraries
@@ -68,6 +68,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Tue Aug 24 2010 Adam Tkac atkac redhat com - 1.005-2
+- rebuild
+
* Fri Jun 11 2010 Petr Sabata psab...@redhat.com - 1.005-1
- Update to the latest release, fixing #602933
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-PAR-Packer/f14/master] Rebuild.
Summary of changes: 92bee8a... Rebuild. (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-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 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 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 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 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 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: 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: 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 li...@sapience.com 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
