[Bug 1283736] New: nosync i686 can not be installed on from x86_64 system
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1283736
Bug ID: 1283736
Summary: nosync i686 can not be installed on from x86_64 system
Product: Fedora
Version: 22
Component: nosync
Assignee: mizdebsk(a)redhat.com
Reporter: hobbes1069(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: java-sig-commits(a)lists.fedoraproject.org,
mizdebsk(a)redhat.com, msimacek(a)redhat.com,
msrb(a)redhat.com
Description of problem:
When trying to upgrade from f21 to f22 I had to remove nosync.i686 before
system-upgrade would complete. After the upgrade finished I attempted a:
dnf install nosync.i686
but no package was found.
Version-Release number of selected component (if applicable):
nosync-1.0-2.fc22.i686
Additional info:
It seems that the i686 package is not available in the x86_64 repository for
some reason. I was able to install the i686 build from koji that matches the
NVR of x86_64.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=UCUZ7p57It&a=cc_unsubscribe
7 years, 11 months
[Bug 1193307] New: tomcat: do not provide javax.el:el-api
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1193307
Bug ID: 1193307
Summary: tomcat: do not provide javax.el:el-api
Product: Fedora
Version: 22
Component: tomcat
Assignee: ivan.afonichev(a)gmail.com
Reporter: msrb(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: ivan.afonichev(a)gmail.com,
java-sig-commits(a)lists.fedoraproject.org,
krzysztof.daniel(a)gmail.com
Description of problem:
tomcat currently provides, among others, mvn(javax.el:el-api). The problem is
that the glassfish-el-api provides it as well. This causes other packages fail
to build, if both tomcat and glassfish-el-api happen to be in the buildroot. I
think that glassfish-el-api should be the one providing javax.el:el-api, as it
is a reference implementation of EL.
Java packaging guidelines should be updated as well.
Version-Release number of selected component (if applicable):
tomcat-8.0.18-1.fc23
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=kgtemPVawE&a=cc_unsubscribe
7 years, 11 months
[Bug 1271243] New: groovy-lib has unnecessary requires
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1271243
Bug ID: 1271243
Summary: groovy-lib has unnecessary requires
Product: Fedora
Version: rawhide
Component: groovy
Assignee: msrb(a)redhat.com
Reporter: msimacek(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: java-sig-commits(a)lists.fedoraproject.org,
mizdebsk(a)redhat.com, msrb(a)redhat.com
Description of problem:
I think the groovy-lib subpackage was introduced to allow packages that use
groovy as embedded language to depend on it without pulling in a ton of
dependencies. But as of now, groovy-lib still pulls in ant, junit, testng etc.,
which I believe are not needed (are optional).
Version-Release number of selected component (if applicable):
groovy-lib-0:2.4.5-1.fc24.noarch
How reproducible:
always
Steps to Reproduce:
1. repoquery --requires groovy-lib
Actual results:
java-headless
jpackage-utils
mvn(bsf:bsf)
mvn(com.beust:jcommander)
mvn(com.thoughtworks.qdox:qdox)
mvn(commons-logging:commons-logging)
mvn(jline:jline)
mvn(junit:junit)
mvn(org.apache.ant:ant)
mvn(org.apache.ant:ant-antlr)
mvn(org.apache.ant:ant-junit)
mvn(org.apache.ant:ant-launcher)
mvn(org.testng:testng)
Expected results:
no requires on ant, junit, etc.
Additional info:
On the other hand, I'd expect objectweb-asm to be among requires, as that is
what groovy uses internally, isn't it?
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=FVkBniC3y2&a=cc_unsubscribe
7 years, 11 months
[Bug 1237344] New: emit requires on javapackages-tools instead of jpackage-utils
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1237344
Bug ID: 1237344
Summary: emit requires on javapackages-tools instead of
jpackage-utils
Product: Fedora
Version: rawhide
Component: javapackages-tools
Severity: medium
Assignee: mizdebsk(a)redhat.com
Reporter: orion(a)cora.nwra.com
QA Contact: extras-qa(a)fedoraproject.org
CC: java-sig-commits(a)lists.fedoraproject.org,
mat.booth(a)redhat.com, mizdebsk(a)redhat.com,
msimacek(a)redhat.com, msrb(a)redhat.com
Description of problem:
Now that javapackages-tools provides/replaces jpackage-utils, it's probably
time to change /etc/java/javapackages-config.json to emit javapackages-tools
instead of jpackage-utils.
Version-Release number of selected component (if applicable):
javapackages-tools-4.5.0-3.fc23.noarch
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=TO46dpI0y1&a=cc_unsubscribe
7 years, 12 months
[Bug 1236297] New: log4j not working
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1236297
Bug ID: 1236297
Summary: log4j not working
Product: Fedora
Version: 22
Component: tomcat
Severity: low
Assignee: ivan.afonichev(a)gmail.com
Reporter: edwardquick(a)hotmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: alee(a)redhat.com, ivan.afonichev(a)gmail.com,
java-sig-commits(a)lists.fedoraproject.org,
krzysztof.daniel(a)gmail.com, me(a)coolsvap.net
Description of problem:
After configuring tomcat to work with log4j, there are no logs.
Version-Release number of selected component (if applicable):
tomcat-7.0.59-4.fc22.noarch
tomcat-log4j-7.0.59-4.fc22.noarch
How reproducible:
Always
Steps to Reproduce:
1. dnf install tomcat tomcat-log4j
2. cp /etc/tomcat/log4j.properties /usr/share/tomcat/lib/log4j.properties
3. cp /usr/share/java/tomcat/log4j.jar /usr/share/tomcat/lib
4. echo "LOGGING_PROPERTIES=/usr/share/tomcat/lib/log4j.properties" >
/etc/tomcat/tomcat.conf
5. systemctl start tomcat
Actual results:
tomcat.log does not exist in /var/log/tomcat
Expected results:
tomcat.log should exist in /var/log/tomcat with debug logging
Additional info:
I followed the information at
https://tomcat.apache.org/tomcat-7.0-doc/logging.html#Using_Log4j and got this
to work by replacing tomcat-juli.jar in /usr/share/tomcat/bin and adding
tomcat-juli-adapaters.jar to /usr/share/tomcat/lib
Here is the tomcat process I ran
[root@fedora22 lib]# ps -ef | grep java
tomcat 4128 31665 4 12:54 pts/0 00:00:02 /usr/lib/jvm/jre/bin/java
-classpath
/usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/lib/java/commons-daemon.jar
-Dcatalina.base=/usr/share/tomcat -Dcatalina.home=/usr/share/tomcat
-Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat/temp
-Djava.util.logging.config.file=/usr/share/tomcat/lib/log4j.properties
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
org.apache.catalina.startup.Bootstrap start
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=52EFloyjfz&a=cc_unsubscribe
8 years
[Bug 1282371] New: jenkins: Remote code execution vulnerability due to unsafe deserialization in Jenkins remoting (SECURITY-218)
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1282371
Bug ID: 1282371
Summary: jenkins: Remote code execution vulnerability due to
unsafe deserialization in Jenkins remoting
(SECURITY-218)
Product: Security Response
Component: vulnerability
Keywords: Security
Severity: high
Priority: high
Assignee: security-response-team(a)redhat.com
Reporter: mprpic(a)redhat.com
CC: bleanhar(a)redhat.com, ccoleman(a)redhat.com,
dmcphers(a)redhat.com,
java-sig-commits(a)lists.fedoraproject.org,
jdetiber(a)redhat.com, jialiu(a)redhat.com,
jkeck(a)redhat.com, joelsmith(a)redhat.com,
jokerman(a)redhat.com, kseifried(a)redhat.com,
lmeyer(a)redhat.com, mizdebsk(a)redhat.com,
mmccomas(a)redhat.com, msrb(a)redhat.com
The following flaw was found in Jenkins:
Unsafe deserialization allows unauthenticated remote attackers to run arbitrary
code on the Jenkins master.
This flaw could allow unauthenticated remote attackers to run arbitrary code on
Jenkins.
Mitigation:
https://jenkins-ci.org/content/mitigating-unauthenticated-remote-code-exe...
External References:
https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+20...
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=cAmrN8IiEj&a=cc_unsubscribe
8 years
[Bug 1282369] New: CVE-2015-5326 jenkins: Stored XSS vulnerability in slave offline status message (SECURITY-214)
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1282369
Bug ID: 1282369
Summary: CVE-2015-5326 jenkins: Stored XSS vulnerability in
slave offline status message (SECURITY-214)
Product: Security Response
Component: vulnerability
Keywords: Security
Severity: low
Priority: low
Assignee: security-response-team(a)redhat.com
Reporter: mprpic(a)redhat.com
CC: bleanhar(a)redhat.com, ccoleman(a)redhat.com,
dmcphers(a)redhat.com,
java-sig-commits(a)lists.fedoraproject.org,
jdetiber(a)redhat.com, jialiu(a)redhat.com,
jkeck(a)redhat.com, joelsmith(a)redhat.com,
jokerman(a)redhat.com, kseifried(a)redhat.com,
lmeyer(a)redhat.com, mizdebsk(a)redhat.com,
mmccomas(a)redhat.com, msrb(a)redhat.com
The following flaw was found in Jenkins:
Users with the permission to take slave nodes offline can enter arbitrary HTML
that gets shown unescaped to users visiting the slave overview page.
This flaw allows admins and users with significant privileges to circumvent XSS
protection.
External References:
https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+20...
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=ModxPFNrI9&a=cc_unsubscribe
8 years