libsodium soname change brought into action
Hi, libsodium 0.5.0 will land in rawhide soon. SONAME change: libsodium.so.4 --> libsodium.so.10 Thanks. Yours sincerely, Christopher Meng Noob here. http://cicku.me -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
libgssglue still alive ? was Re: DISTRIBUTION tag seems wrong
On Tue, 2014-05-20 at 18:08 -0700, Adam Williamson wrote: > Well, you can't, really. Especially 5). For instance, > libgssglue-0.4-2.fc19.x86_64 has so far been a "component_of" Fedora > 19 > and Fedora 20, and is currently a "component_of" Fedora Rawhide. > Steve, didn't we kill libgssglue ? Is it really still in rawhide ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Schedule for Wednesday's (today's) FESCo Meeting (2014-05-21)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 17:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2014-05-21 17:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1178 Fedora 21 scheduling strategy .fesco 1178 https://fedorahosted.org/fesco/ticket/1178 #topic #1221 Product working group activity reports .fesco 1221 https://fedorahosted.org/fesco/ticket/1221 #topic #1250 F21 Self Contained Changes .fesco 1250 https://fedorahosted.org/fesco/ticket/1250#comment:26 Self Contained Changes for 2014-05-21 meeting: * Review Board 2.0 - http://fedoraproject.org/wiki/Changes/ReviewBoard2 discussed at https://lists.fedoraproject.org/pipermail/devel/2014-May/199143.html Review Board is a powerful tool for managing patch reviews. * Serf 0.4.5 - http://fedoraproject.org/wiki/Changes/Serf_0.4.5 discussed at https://lists.fedoraproject.org/pipermail/devel/2014-May/199148.html Serf is a decentralized solution for service discovery and orchestration that is lightweight, highly available, and fault tolerant. This change is to package serf for Fedora users. * SSSD GPO-Based Access Control - fedoraproject.org/wiki/Changes/SssdGpoBasedAccessControl discussed at https://lists.fedoraproject.org/pipermail/devel/2014-May/199145.html This change will enhance SSSD, by adding support for centrally managed host-based access control in an Active Directory (AD) environment, using Group Policy Objects (GPOs). * Web Application Authentication - fedoraproject.org/wiki/Changes/Web_App_Authentication discussed at https://lists.fedoraproject.org/pipermail/devel/2014-May/199144.html On operating system level, there are numerous authentication and identity lookup mechanisms, some of them using sssd. With new Apache modules and new sssd, some of those mechanisms become more easily consumable by web applications. Various web application environments and frameworks can then consume results of the authentication and information retrieval using environment variables similar to REMOTE_USER. #topic #1291 System Wide Change: BerkeleyDB 6 - https://fedoraproject.org/wiki/Changes/BerkeleyDB_6 .fesco 1291 https://fedorahosted.org/fesco/ticket/1291 = New business = #topic #1309 F21 System Wide Change: Web Assets - http://fedoraproject.org/wiki/Changes/Web_Assets .fesco 1309 https://fedorahosted.org/fesco/ticket/1309 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: PkgDB2 is now in production
On Mon, May 19, 2014 at 04:27:22PM +0200, Pierre-Yves Chibon wrote: > On Mon, May 19, 2014 at 03:22:31PM +0100, Sérgio Basto wrote: > > On Sáb, 2014-05-17 at 09:27 +0200, Pierre-Yves Chibon wrote: > > > On Fri, 2014-05-16 at 10:44 +0800, Christopher Meng wrote: > > > > There are many broken redirect links, please fix asap. > > > > > > It's not that there are many broken redirect it's that we didn't put in > > > place any redirect atm :) > > It's fixed in git: https://github.com/fedora-infra/fedora-packages/pull/86 > it 'just' need a new release :) > It's those links are broken here[1] as well. http://fedoraproject.org/wiki/Using_the_package_database#Bugzilla_Acls -- Matthias Runge -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Mommy, why do I have duplicate packages installed?
Hi all, If you've been using GNOME 3.12 and updating packages with gnome-software, you might have run into an issue with the update process leaving behind a lot of duplicate packages: https://bugzilla.gnome.org/show_bug.cgi?id=730451 This turned out to be an issue with PackageKit's Fedora packaging. It had an rpm postun script for restarting the PackageKit daemon after an update, but if PackageKit itself was driving the update as is the case with updates done through gnome-software, it interrupted the whole transaction. I've now built fixed packages for both the f20-gnome-3-12 copr and rawhide. How To Make Everything Work Again = 1) Run 'package-cleanup --dupes' -- if you are affected, it prints out a number of packages. If the command is not installed, install yum-utils first. 2) Find a good time for the next step. In some cases, it can uninstall half of your system, so don't run it 5 minutes before you have to give a presentation! 3) Run 'package-cleanup --cleandupes' 4) Update to PackageKit-0.9.2-3.fc20 with either yum or dnf: yum update 'PackageKit*' dnf update 'PackageKit*' 5) All done, can now resume to using gnome-software and PackageKit updates. -- Hope this helps, Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: koji: page encrypted but downloads not
On Tue, 20 May 2014 22:47:12 +0200 Reindl Harald wrote: > simple example: > > https://koji.fedoraproject.org/koji/buildinfo?buildID=516900 > > the page itself is encrypted > > *but* all the download-links are not > http://kojipkgs.fedoraproject.org//packages/gcc/4.8.2/18.fc20/src/gcc-4.8.2-18.fc20.src.rpm > > why? Well, until very recently, kojipkgs didn't offer https at all. We can look at switching the default, but then it means koji uses https to talk to kojipkgs (which I assure you it does more than any external downloading does), which might mean more overhead and slower builds. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: koji: page encrypted but downloads not
Am 21.05.2014 16:55, schrieb Kevin Fenzi: > On Tue, 20 May 2014 22:47:12 +0200 > Reindl Harald wrote: > >> simple example: >> >> https://koji.fedoraproject.org/koji/buildinfo?buildID=516900 >> >> the page itself is encrypted >> >> *but* all the download-links are not >> http://kojipkgs.fedoraproject.org//packages/gcc/4.8.2/18.fc20/src/gcc-4.8.2-18.fc20.src.rpm >> >> why? > > Well, until very recently, kojipkgs didn't offer https at all. > > We can look at switching the default, but then it means koji uses https > to talk to kojipkgs (which I assure you it does more than any external > downloading does), which might mean more overhead and slower builds no need to change the defaults IMHO it should not be that complicated to add the https:// prefix only for webpage-output without changing internal defaults or if that won't work for now if add the https:// in case of a wget command would work at all signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Hadoop + log4j2 = fullstop
I've been working on updating the hadoop package to the latest 2.4.0 release and at this point I've resolved all the issues but I'm now blocked by the log4j2 update. log4j2 breaks the hadoop build pretty severely, and it doesn't seem the log4j2 team has spent much time thinking about how to provide backwards compatibility to existing log4j1.2 users. From my investigation of log4j2: log4j.properties file is no longer read at all configuration file is now in XML or JSON configuration file name is log4j2.[xml|json|jsn] V2 isn't backwards compatible with V1. There's a shim for v1 api but it will only work for a limited set of cases, and for some cases it does work for it turns some operations into noop calls. This is a pretty major change and even the compatibility layer, if it will work for a project, does not seem to guarantee like functionality and minimally will require a re-do of all log4j configuration files a project ships. I'm not sure many sizable upstream projects would undertake/accept such a drastic change very quickly. The list of projects currently blocked by this update are: hadoop hbase oozie hive apache-log4j-extras amplab-tachyon I would be surprised if there aren't a lot more. I understand Fedora is always pushing for the latest versions, but for some fundamental packages can there be compatibility packages introduced at the same time as an incompatible update? Package maintainers of dependent packages will still need to touch their packages and determine if the new version will work for them. Providing a compat package will also allow packages to update to their newer versions while not held up on trying to integrate changes from a compatibility breaking dependency update. Rob -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-java] Hadoop + log4j2 = fullstop
On 21 May 2014 17:03, Robert Rati wrote: > I've been working on updating the hadoop package to the latest 2.4.0 > release and at this point I've resolved all the issues but I'm now blocked > by the log4j2 update. log4j2 breaks the hadoop build pretty severely, and > it doesn't seem the log4j2 team has spent much time thinking about how to > provide backwards compatibility to existing log4j1.2 users. From my > investigation of log4j2: > > log4j.properties file is no longer read at all > configuration file is now in XML or JSON > configuration file name is log4j2.[xml|json|jsn] > V2 isn't backwards compatible with V1. There's a shim for v1 api but it > will only work for a limited set of cases, and for some cases it does work > for it turns some operations into noop calls. > > This is a pretty major change and even the compatibility layer, if it will > work for a project, does not seem to guarantee like functionality and > minimally will require a re-do of all log4j configuration files a project > ships. I'm not sure many sizable upstream projects would undertake/accept > such a drastic change very quickly. > > The list of projects currently blocked by this update are: > hadoop > hbase > oozie > hive > apache-log4j-extras > amplab-tachyon > > I would be surprised if there aren't a lot more. I understand Fedora is > always pushing for the latest versions, but for some fundamental packages > can there be compatibility packages introduced at the same time as an > incompatible update? Package maintainers of dependent packages will still > need to touch their packages and determine if the new version will work for > them. Providing a compat package will also allow packages to update to > their newer versions while not held up on trying to integrate changes from > a compatibility breaking dependency update. > > Rob > -- > Yes, there are precedents for compat packages. For example there are both jdom and jdom2 packages in Fedora for this reason. There also used to be a xml-commons-apis12 compat package (not any more though, we were able to finally retire it in favour of xml-commons-apis.) -- Mat Booth http://fedoraproject.org/get-fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
pkgdb2 package/owner CSV list
Hi, Before pkgdb2 it was possible to retrieve a plain text CSV list of package/owners pairs. What is the corrent URL to achieve the same with pgkdb2 or has this feature been lost? Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: pkgdb2 package/owner CSV list
On Wed, 21 May 2014 18:18:12 +0200 Ralf Corsepius wrote: > Hi, > > Before pkgdb2 it was possible to retrieve a plain text CSV list of > package/owners pairs. > > What is the corrent URL to achieve the same with pgkdb2 or has this > feature been lost? Well, there is: https://admin.fedoraproject.org/pkgdb/api/bugzilla and https://admin.fedoraproject.org/pkgdb/api/vcs But they aren't CSV lists exactly. Are one of those what you are looking for? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: pkgdb2 package/owner CSV list
On 05/21/2014 06:25 PM, Kevin Fenzi wrote: On Wed, 21 May 2014 18:18:12 +0200 Ralf Corsepius wrote: Hi, Before pkgdb2 it was possible to retrieve a plain text CSV list of package/owners pairs. What is the corrent URL to achieve the same with pgkdb2 or has this feature been lost? Well, there is: https://admin.fedoraproject.org/pkgdb/api/bugzilla Thanks. This seems to be what I was looking for and https://admin.fedoraproject.org/pkgdb/api/vcs But they aren't CSV lists exactly. Are one of those what you are looking for? I was looking for a replacement for what used to be returned by https://admin.fedoraproject.org/pkgdb/lists/bugzilla?tg_format=plain Without having checked details yet, the *bugzilla URL above seems to return the same file format as the old URL did. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Summary/Minutes for today's FESCo meeting (2014-05-21)
=== #fedora-meeting: FESCO (2014-05-21) === Meeting started by t8m at 17:00:01 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-05-21/fesco.2014-05-21-17.00.log.html . Meeting summary --- * init process (t8m, 17:00:09) * #1178 Fedora 21 scheduling strategy (t8m, 17:02:38) * #1221 Product working group activity reports (t8m, 17:04:41) * See the notes in the ticket (t8m, 17:05:11) * #1250 F21 Self Contained Changes (t8m, 17:08:36) * AGREED: All self contained Changes for 2014-05-21 FESCo meeting are approved (+9, -0, 0:0) (t8m, 17:12:06) * See https://fedorahosted.org/fesco/ticket/1250#comment:26 for the list of them (t8m, 17:12:43) * #1291 System Wide Change: BerkeleyDB 6 - https://fedoraproject.org/wiki/Changes/BerkeleyDB_6 (t8m, 17:13:06) * ACTION: sgallagh to talk to hhorak directly (sgallagh, 17:18:37) * AGREED: The definitive decision is deferred to next week (t8m, 17:19:18) * #1309 F21 System Wide Change: Web Assets - http://fedoraproject.org/wiki/Changes/Web_Assets (t8m, 17:19:38) * AGREED: F21 System Wide Change: Web Assets is approved (+9, -0, 0:0) (t8m, 17:23:45) * Next week chair (t8m, 17:24:04) * ACTION: abadger1999 will chair the meeting next week (t8m, 17:26:03) * Open floor (t8m, 17:26:11) Meeting ended at 17:35:01 UTC. Action Items * sgallagh to talk to hhorak directly * abadger1999 will chair the meeting next week Action Items, by person --- * abadger1999 * abadger1999 will chair the meeting next week * sgallagh * sgallagh to talk to hhorak directly * **UNASSIGNED** * (none) People Present (lines said) --- * t8m (52) * sgallagh (16) * dgilmore (15) * pjones (9) * zodbot (9) * abadger1999 (8) * mattdm (8) * nirik (7) * mitr (5) * notting (5) * jwb (2) * jsmith (1) * mmaslano (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot - 17:00:01 #startmeeting FESCO (2014-05-21) 17:00:01 Meeting started Wed May 21 17:00:01 2014 UTC. The chair is t8m. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:01 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:08 #meetingname fesco 17:00:09 The meeting name has been set to 'fesco' 17:00:09 #chair abadger1999 dgilmore mattdm mitr notting nirik pjones t8m sgallagh mmaslano jwb 17:00:09 #topic init process 17:00:09 Current chairs: abadger1999 dgilmore jwb mattdm mitr mmaslano nirik notting pjones sgallagh t8m 17:00:17 Hello, party people. 17:00:17 I'm here but I have a hard stop in one hour 17:00:20 Hi all 17:00:38 * notting is here 17:00:41 morning 17:00:44 sgallagh, hopefully we will be able to finish by that time 17:01:10 Hello 17:01:33 Greetings 17:01:51 * jsmith lurks 17:01:54 dgilmore, mattdm, around? 17:02:01 t8m: yep 17:02:11 hi 17:02:11 * mattdm is here 17:02:18 ok, let's start 17:02:38 #topic #1178 Fedora 21 scheduling strategy 17:02:44 .fesco 1178 17:02:46 t8m: #1178 (Fedora 21 scheduling strategy) – FESCo - https://fedorahosted.org/fesco/ticket/1178 17:03:19 Anything else to discuss today regarding to scheduling? 17:03:29 ive announced to devel-aanounce the dates for mass rebuild and side tag completion 17:03:30 Actually, I think I just forgot to remove the 'meeting' keyword last week. 17:03:39 I think we are good 17:04:27 OK, moving on 17:04:41 #topic #1221 Product working group activity reports 17:04:48 .fesco 1221 17:04:50 t8m: #1221 (Product working group activity reports) – FESCo - https://fedorahosted.org/fesco/ticket/1221 17:05:05 there are some notes in the ticket 17:05:11 #info See the notes in the ticket 17:05:15 :) 17:05:49 I don't think cloud has any cross-project things to note... as mentioned there we're working on some of the issues around ostree and mirroring 17:06:48 In Server, we know we need to sync up with release engineering and work out the install media situation 17:06:56 thats going to take a lot of focus and effort 17:07:44 sgallagh: from what I can tell its nothing different to what we make today, you need to work with the anaconda guys to support your use cases 17:07:44 jwb, nothing from workstation group? 17:07:58 not this week 17:08:08 ok 17:08:11 moving on 17:08:18 dgilmore: I'm not sure we need any anaconda changes either. We can discuss that later. 17:08:26 sgallagh: sure 17:08:36 #topic #1250 F21 Self Contained Changes 17:08:44 .fesco 1250 17:08:45 t8m: #1250 (F21 Self Contained Changes) – FESCo - https://fedorahosted.org/fesco/ticket/1250 17:09:04 Review Board 2.0 - http://fedoraproject.org/wiki/Changes/ReviewBoard2 17:09:12 Serf 0.4.5 - ​http://fedoraproject.org/wiki/Changes/Serf_0.4.5 17:09:30 +1 to all of them 17:09:41 SSSD GPO-Based Access Control - http://fedoraproject.org/wiki/Changes/SssdGpoBasedAccessControl 17:09
Re: Hadoop + log4j2 = fullstop
Alexander Kurtakov Red Hat Eclipse team - Original Message - > From: "Robert Rati" > To: "Fedora Big Data SIG" , "Development > discussions related to Fedora" > , "Fedora Java Development List" > > Sent: Wednesday, May 21, 2014 7:03:42 PM > Subject: Hadoop + log4j2 = fullstop > > I've been working on updating the hadoop package to the latest 2.4.0 > release and at this point I've resolved all the issues but I'm now > blocked by the log4j2 update. log4j2 breaks the hadoop build pretty > severely, and it doesn't seem the log4j2 team has spent much time > thinking about how to provide backwards compatibility to existing > log4j1.2 users. From my investigation of log4j2: > > log4j.properties file is no longer read at all > configuration file is now in XML or JSON > configuration file name is log4j2.[xml|json|jsn] > V2 isn't backwards compatible with V1. There's a shim for v1 api but it > will only work for a limited set of cases, and for some cases it does > work for it turns some operations into noop calls. > > This is a pretty major change and even the compatibility layer, if it > will work for a project, does not seem to guarantee like functionality > and minimally will require a re-do of all log4j configuration files a > project ships. I'm not sure many sizable upstream projects would > undertake/accept such a drastic change very quickly. > > The list of projects currently blocked by this update are: > hadoop > hbase > oozie > hive > apache-log4j-extras > amplab-tachyon > > I would be surprised if there aren't a lot more. I understand Fedora is > always pushing for the latest versions, but for some fundamental > packages can there be compatibility packages introduced at the same time > as an incompatible update? Nothing stops compatibility packages from appearing. But it's the people that need it that have to drive it. Everyone is time constrained so whoever needs something must do it. It's really is as simple as that. Alexander Kurtakov Red Hat Eclipse team > Package maintainers of dependent packages > will still need to touch their packages and determine if the new version > will work for them. Providing a compat package will also allow packages > to update to their newer versions while not held up on trying to > integrate changes from a compatibility breaking dependency update. > > Rob > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-java] Hadoop + log4j2 = fullstop
So, who needed log4j2? It is massively incompatible with log4j1.2 and isn't a simple port job. I would argue if log4j2 was actually needed, it should have been introduced as a separate log4j2 package and allow projects to port to it as they have time/need. This update log4j to an incompatible version with no compat package provided at the same time is not the way to handle such an upgrade. Giving advanced notice that the world will come crumbling down and you'll have to deal with it is not enough. Rob On 05/21/2014 02:01 PM, Aleksandar Kurtakov wrote: Alexander Kurtakov Red Hat Eclipse team - Original Message - From: "Robert Rati" To: "Fedora Big Data SIG" , "Development discussions related to Fedora" , "Fedora Java Development List" Sent: Wednesday, May 21, 2014 7:03:42 PM Subject: Hadoop + log4j2 = fullstop I've been working on updating the hadoop package to the latest 2.4.0 release and at this point I've resolved all the issues but I'm now blocked by the log4j2 update. log4j2 breaks the hadoop build pretty severely, and it doesn't seem the log4j2 team has spent much time thinking about how to provide backwards compatibility to existing log4j1.2 users. From my investigation of log4j2: log4j.properties file is no longer read at all configuration file is now in XML or JSON configuration file name is log4j2.[xml|json|jsn] V2 isn't backwards compatible with V1. There's a shim for v1 api but it will only work for a limited set of cases, and for some cases it does work for it turns some operations into noop calls. This is a pretty major change and even the compatibility layer, if it will work for a project, does not seem to guarantee like functionality and minimally will require a re-do of all log4j configuration files a project ships. I'm not sure many sizable upstream projects would undertake/accept such a drastic change very quickly. The list of projects currently blocked by this update are: hadoop hbase oozie hive apache-log4j-extras amplab-tachyon I would be surprised if there aren't a lot more. I understand Fedora is always pushing for the latest versions, but for some fundamental packages can there be compatibility packages introduced at the same time as an incompatible update? Nothing stops compatibility packages from appearing. But it's the people that need it that have to drive it. Everyone is time constrained so whoever needs something must do it. It's really is as simple as that. Alexander Kurtakov Red Hat Eclipse team Package maintainers of dependent packages will still need to touch their packages and determine if the new version will work for them. Providing a compat package will also allow packages to update to their newer versions while not held up on trying to integrate changes from a compatibility breaking dependency update. Rob -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- java-devel mailing list java-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-java] Hadoop + log4j2 = fullstop
- Original Message - > From: "Robert Rati" > To: "Aleksandar Kurtakov" , "Development discussions > related to Fedora" > > Cc: "Fedora Big Data SIG" , "Fedora Java > Development List" > > Sent: Wednesday, May 21, 2014 9:06:07 PM > Subject: Re: [fedora-java] Hadoop + log4j2 = fullstop > > So, who needed log4j2? It is massively incompatible with log4j1.2 and > isn't a simple port job. I would argue if log4j2 was actually needed, > it should have been introduced as a separate log4j2 package and allow > projects to port to it as they have time/need. This update log4j to an > incompatible version with no compat package provided at the same time is > not the way to handle such an upgrade. Giving advanced notice that the > world will come crumbling down and you'll have to deal with it is not > enough. Now this it the wrong question. Questioning the right of someone doing the update and maintaining something for others to use is unfair at least. The one that *does* decides. Others are free to *do* themself. I can write an essay why keeping old software around is bad and how often it hurts people that care for the whole distro. It's pretty easy for others caring for just their own thing to dismiss this work and any explanation would simply be not understood until they try to look at the bigger picture. I really recommend you joining in the big effort to keep the Java ecosystem in good shape on fedora to feel the pain and understand why so many don't want to deal with such things. P.S. 1. Just trying to get explanation for something or make the build system work with latest build systems around once new major release is available upstream will show you what I speak for. P.S. 2. Two of my packages are failing because of this. I still haven't investigated it but if moving to log4j2 is not easy it's my problem not log4j maintainer one (who by the way is awesome guy and provides more support than people can ask for, making the question even more unfair). Alexander Kurtakov Red Hat Eclipse team > > Rob > > On 05/21/2014 02:01 PM, Aleksandar Kurtakov wrote: > > > > > > Alexander Kurtakov > > Red Hat Eclipse team > > > > - Original Message - > >> From: "Robert Rati" > >> To: "Fedora Big Data SIG" , "Development > >> discussions related to Fedora" > >> , "Fedora Java Development List" > >> > >> Sent: Wednesday, May 21, 2014 7:03:42 PM > >> Subject: Hadoop + log4j2 = fullstop > >> > >> I've been working on updating the hadoop package to the latest 2.4.0 > >> release and at this point I've resolved all the issues but I'm now > >> blocked by the log4j2 update. log4j2 breaks the hadoop build pretty > >> severely, and it doesn't seem the log4j2 team has spent much time > >> thinking about how to provide backwards compatibility to existing > >> log4j1.2 users. From my investigation of log4j2: > >> > >> log4j.properties file is no longer read at all > >> configuration file is now in XML or JSON > >> configuration file name is log4j2.[xml|json|jsn] > >> V2 isn't backwards compatible with V1. There's a shim for v1 api but it > >> will only work for a limited set of cases, and for some cases it does > >> work for it turns some operations into noop calls. > >> > >> This is a pretty major change and even the compatibility layer, if it > >> will work for a project, does not seem to guarantee like functionality > >> and minimally will require a re-do of all log4j configuration files a > >> project ships. I'm not sure many sizable upstream projects would > >> undertake/accept such a drastic change very quickly. > >> > >> The list of projects currently blocked by this update are: > >> hadoop > >> hbase > >> oozie > >> hive > >> apache-log4j-extras > >> amplab-tachyon > >> > >> I would be surprised if there aren't a lot more. I understand Fedora is > >> always pushing for the latest versions, but for some fundamental > >> packages can there be compatibility packages introduced at the same time > >> as an incompatible update? > > > > Nothing stops compatibility packages from appearing. But it's the people > > that need it that have to drive it. Everyone is time constrained so > > whoever needs something must do it. > > It's really is as simple as that. > > > > Alexander Kurtakov > > Red Hat Eclipse team > > > >> Package maintainers of dependent packages > >> will still need to touch their packages and determine if the new version > >> will work for them. Providing a compat package will also allow packages > >> to update to their newer versions while not held up on trying to > >> integrate changes from a compatibility breaking dependency update. > >> > >> Rob > >> -- > >> devel mailing list > >> devel@lists.fedoraproject.org > >> https://admin.fedoraproject.org/mailman/listinfo/devel > >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > > -- > > java-devel mailing list > > java-de...@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/java-devel >
xz-compressed kernel modules
Rawhide has xz-compressed kernel modules. I think this is a good thing as it saves a lot of disk space in VMs. It did however necessitate a change in supermin (used by libguestfs). Upstream already supported xz-compressed modules -- the patch was contributed by Arch Linux which has been using them for a long time. However it was not turned on in Fedora because it needs a statically linked liblzma (we're building a tiny, static init to bootstrap a VM). So I've taken co-maint of xz and added the xz-static subpackage. [Discussion: https://bugzilla.redhat.com/show_bug.cgi?id=547011 ] I've added this to Rawhide. It's waiting in updates-testing for F20, and could do with some testing and karma: https://admin.fedoraproject.org/updates/FEDORA-2014-6534/xz-5.1.2-9alpha.fc20,supermin-5.1.8-5.fc20 I've not done anything for F19. Please let me know if xz-compressed modules will be turned on there. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: xz-compressed kernel modules
On Wed, May 21, 2014 at 3:43 PM, Richard W.M. Jones wrote: > > Rawhide has xz-compressed kernel modules. I think this is a good > thing as it saves a lot of disk space in VMs. > > It did however necessitate a change in supermin (used by libguestfs). > Upstream already supported xz-compressed modules -- the patch was > contributed by Arch Linux which has been using them for a long time. > However it was not turned on in Fedora because it needs a statically > linked liblzma (we're building a tiny, static init to bootstrap a VM). My apologies. I was unaware of supermin when I enabled it. > So I've taken co-maint of xz and added the xz-static subpackage. > [Discussion: https://bugzilla.redhat.com/show_bug.cgi?id=547011 ] > > I've added this to Rawhide. Thanks for jumping on this so quickly. > It's waiting in updates-testing for F20, and could do with some > testing and karma: > https://admin.fedoraproject.org/updates/FEDORA-2014-6534/xz-5.1.2-9alpha.fc20,supermin-5.1.8-5.fc20 > > I've not done anything for F19. Please let me know if xz-compressed > modules will be turned on there. We won't be enabling the compression for the stable releases. This is an F21 and future change only. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Schedule for Thursday's FPC Meeting (2014-05-2 16:00 UTC)
Following is the list of topics that will be discussed in the FPC meeting Thursday at 2014-05-22 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. rktime): 2014-05-22 09:00 Thu US/Pacific PDT 2014-05-22 12:00 Thu US/Eastern EDT 2014-05-22 16:00 Thu UTC <- 2014-05-22 17:00 Thu Europe/London BST 2014-05-22 18:00 Thu Europe/Paris CEST 2014-05-22 18:00 Thu Europe/Berlin CEST 2014-05-22 21:30 Thu Asia/Calcutta IST --new day-- 2014-05-23 00:00 Fri Asia/Singapore SGT 2014-05-23 00:00 Fri Asia/Hong_Kong HKT 2014-05-23 01:00 Fri Asia/Tokyo JST 2014-05-23 02:00 Fri Australia/Brisbane EST Links to all tickets below can be found at: https://fedorahosted.org/fpc/report/12 = Followups = (approval and retirement sections already passed, /opt exception passed) #topic #339 software collections in Fedora .fpc 339 https://fedorahosted.org/fpc/ticket/339 #topic #382 Go Packaging Guidelines Draft .fpc 382 https://fedorahosted.org/fpc/ticket/382 #topic #400 Exception for bundled library FoX in exciting .fpc 400 https://fedorahosted.org/fpc/ticket/400 (needs to be reworded to match new .desktop wording) #topic #414 Please consider requiring AppData for all desktop applications .fpc 414 https://fedorahosted.org/fpc/ticket/414 (dots in name, utility of ruby without rails) #topic #419 ruby193 in SCL .fpc 419 https://fedorahosted.org/fpc/ticket/419 (needs fakesystemd, or another solution) #topic #425 systemd or systemd-units should not be required if a spec file does a %systemd_post command .fpc 425 https://fedorahosted.org/fpc/ticket/425 = New business = #topic #424 Bundling exception request for nodejs-weak-map .fpc 424 https://fedorahosted.org/fpc/ticket/424 #topic #426 Need policy and macros for binfmt.d file handling .fpc 426 https://fedorahosted.org/fpc/ticket/426 #topic #427 Bundling exception requests for new julia package .fpc 427 https://fedorahosted.org/fpc/ticket/427 #topic #428 Exception for bundling css in infrastructure application .fpc 428 https://fedorahosted.org/fpc/ticket/428 #topic #429 Bundling exception request for apitrace: libbacktrace .fpc 429 https://fedorahosted.org/fpc/ticket/429 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://fedorahosted.org/fpc/report/12 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fpc, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-java] Hadoop + log4j2 = fullstop
On 05/21/2014 08:06 PM, Robert Rati wrote: > So, who needed log4j2? It is massively incompatible with log4j1.2 and > isn't a simple port job. I would argue if log4j2 was actually needed, > it should have been introduced as a separate log4j2 package and allow > projects to port to it as they have time/need. This update log4j to an > incompatible version with no compat package provided at the same time is > not the way to handle such an upgrade. Giving advanced notice that the > world will come crumbling down and you'll have to deal with it is not > enough. 1. This change was announced [1] in advance and I didn't hear any concerns from anyone until the change was implemented. hadoop and all other packages were mentioned in the announcement as possibly being affected by the update. 2. The original announcement [1] and follow-up messages contain some of the reasons for updating to 2.0. But there are other reasons as well -- log4j 2.0 was blocking mybatis package update [3]. 3. As I already said on IRC multiple times, I am going to introduce a compat package log4j12 before 6 Jun 2014. If that's too late then feel free to package it yourself. 4. I shared my general opinions about Java compat packages and update procedures on java-devel [2] and I didn't hear any concerns about them. Recent log4j update follows the procedure and best practices I presented there, like keeping the name log4j instead using log4j2. [1] https://lists.fedoraproject.org/pipermail/devel/2014-May/198934.html [2] https://lists.fedoraproject.org/pipermail/java-devel/2013-October/005000.html [3] https://bugzilla.redhat.com/show_bug.cgi?id=1091042 -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-java] Hadoop + log4j2 = fullstop
Il 22/05/2014 06:55, Mikolaj Izdebski ha scritto: On 05/21/2014 08:06 PM, Robert Rati wrote: So, who needed log4j2? It is massively incompatible with log4j1.2 and isn't a simple port job. I would argue if log4j2 was actually needed, it should have been introduced as a separate log4j2 package and allow projects to port to it as they have time/need. This update log4j to an incompatible version with no compat package provided at the same time is not the way to handle such an upgrade. Giving advanced notice that the world will come crumbling down and you'll have to deal with it is not enough. 1. This change was announced [1] in advance and I didn't hear any concerns from anyone until the change was implemented. hadoop and all other packages were mentioned in the announcement as possibly being affected by the update. 2. The original announcement [1] and follow-up messages contain some of the reasons for updating to 2.0. But there are other reasons as well -- log4j 2.0 was blocking mybatis package update [3]. but mybatis use them both see https://github.com/mybatis/mybatis-3/blob/mybatis-3.2.7/pom.xml regards 3. As I already said on IRC multiple times, I am going to introduce a compat package log4j12 before 6 Jun 2014. If that's too late then feel free to package it yourself. 4. I shared my general opinions about Java compat packages and update procedures on java-devel [2] and I didn't hear any concerns about them. Recent log4j update follows the procedure and best practices I presented there, like keeping the name log4j instead using log4j2. [1] https://lists.fedoraproject.org/pipermail/devel/2014-May/198934.html [2] https://lists.fedoraproject.org/pipermail/java-devel/2013-October/005000.html [3] https://bugzilla.redhat.com/show_bug.cgi?id=1091042 <>-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
