Re: [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276
On 17 June 2013 03:13, Sérgio Basto ser...@serjux.com wrote: we had updated dpkg some major versions sine bug opened, how I know if dpkg is now ready for aarch64 ? I've discovered you can trigger builds for the ARM Koji instance with your account: koji --server=http://arm.koji.fedoraproject.org/kojihub build --scratch f19 dpkg.src.rpm Regards, --Simone -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). http://xkcd.com/229/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/lib/java
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sun, Jun 16, 2013 at 08:48:38PM +0200, gil wrote:
hi,
I would like to report this:
in my F18 there is something of wrong...
/usr/lib/java/
java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/
in each java folder
file:///usr/lib/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/jansi-native-linux.jar
file:///usr/lib/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/jffi.jar
file:///usr/lib/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/jss4.jar
file:///usr/lib/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/java/swt.jar
regards
gil
Problem looks to be that %{_libdir}/java/java is a misplaced symlink
to its parent %{_libdir}/java/
Gerard.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
iQIcBAEBCAAGBQJRvrESAAoJEG7cfkpivEoVjlIP/12r+7ulsY6fYEuee4rIiXlY
UOX4pvqEQ12w3WYINZlAfolhY08PqJTMIoV6aNWTqYtOuUI2pFdqE5/sgSXJmrYS
FLIifV+3ueGpPVhPzCpr+BmtTgCgdi50htFItv9beZuSeJ1y2Y5LsnklPI4+bOZM
nnWyQ6CixNS7drFl9lmkd4VLiW0leb+ZgSgtz34eZUqdb3suBESRDRQxgOz7cbsR
rBjs+e8fz39C0cKp/fTU/2e1XxfArSH5qz2x1hiLJXD0VRy0n3U+Buw+IiOx0zzf
eR6rMpBE8jXTokaEAlTiLJG9xGVqTGkENL70xVPo9OO8Ftu4rTEoo+T/It0J28xD
Iz194SA94i86WrsFYY5dJm4LDUOe4Bvim+2Wy2XvvKCbv8j1NewqOTcUoU1axqCA
D0tg7XbfeEBs+JFnGxiLhnPdI3NZ4H7euL9okQf/oN05VUzKG9fLmg2S7aL0OvwA
/UIHUgEF5YWtFpsmxHxYuTuu8JJf3/HufwHQRFPfbyFAPnm/RcZduNDEaeC3Dprm
wy4APMBuJzY1a2lJQCtTKP9RnXXQKxlf0KquLf8zpNZZVruT0PZ9wjD7wVhQsz6r
5bE4Gn6yuMPT9OHolgpImTphUK4ireFrB8S3YoWXVNjy7i40JD48VVn+8J5zAenW
rIg2KT2LDshrQkfG8VsC
=odD1
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276
On Mon, 17 Jun 2013 08:44:52 +0200
Simone Caronni negativ...@gmail.com wrote:
On 17 June 2013 03:13, Sérgio Basto ser...@serjux.com wrote:
we had updated dpkg some major versions sine bug opened, how I know
if dpkg is now ready for aarch64 ?
I've discovered you can trigger builds for the ARM Koji instance with
your account:
koji --server=http://arm.koji.fedoraproject.org/kojihub build
--scratch f19 dpkg.src.rpm
the fedora-packager package provides wrappers for the koji command for
all secondary architectures in Fedora in the form ${arch}-koji, where
arch can be arm, ppc and s390, so you can use
arm-koji build --scratch f19 your.src.rpm
Dan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276
On 17 June 2013 09:04, Dan Horák d...@danny.cz wrote:
the fedora-packager package provides wrappers for the koji command for
all secondary architectures in Fedora in the form ${arch}-koji, where
arch can be arm, ppc and s390, so you can use
arm-koji build --scratch f19 your.src.rpm
Oh, thanks, I did not know.
--Simone
--
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).
http://xkcd.com/229/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Magic paths for service registration
On 06/12/2013 06:44 PM, drago01 wrote: If you count extensions then /usr/share/gnome-shell/extensions might qualify as well. Are these extensions commonly used to start daemons are interact with the network? Presumably, there are extensions for downloading weather data or stock exchange information, but this seems fairly restricted and low risk (especially if they use HTTPS, so that the data source would have to be compromised to attack installations). -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] CANCELLED: 2013-06-17 Fedora QA Meeting (blocker meeting still on)
Last week was pretty much taken up with F19 stuff and I don't see anything urgent that needs discussing aside from F19 business, so it seems sensible to just go straight to F19 blocker review again today. We will aim to do a blocker review meeting at 16:00 - I'll send out a separate announcement for that. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] 2013-06-17 @ 16:00 UTC - F19 Final Blocker Bug Review #6
# F19 Final Blocker Review meeting #6 # Date: 2013-06-17 # Time: 16:00 UTC (12:00 EDT, 09:00 PDT) # Location: #fedora-blocker-review on irc.freenode.net We're cancelling the QA meeting for 2013-06-17, but we should still get together and do some blocker review at 16:00 - we have all the blockers and FEs proposed since Wednesday to go through! We can also take a look at F19 business in general, including the problems with composing TC4. We'll be running through the final blockers and freeze exception bugs. The current list is available at: http://qa.fedoraproject.org/blockerbugs/current We'll be reviewing the bugs to determine ... 1. Whether they meet the final release criteria [1] and should stay on the list 2. Whether they are getting the attention they need [1] http://fedoraproject.org/wiki/Fedora_19_Final_Release_Criteria For guidance on Blocker and FreezeException bugs, please refer to - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process For the blocker review meeting protocol, see - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Magic paths for service registration
On Mon, Jun 17, 2013 at 9:37 AM, Florian Weimer fwei...@redhat.com wrote: On 06/12/2013 06:44 PM, drago01 wrote: If you count extensions then /usr/share/gnome-shell/extensions might qualify as well. Are these extensions commonly used to start daemons are interact with the network? No. They are either used to modify the UI or to get data from some webservice / website and display it in some way. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)
On Monday 17 June 2013 02:13:06 Sérgio Basto wrote:
Hi,
I'm trying follow this (aarch64 support) but
https://bugzilla.redhat.com/show_bug.cgi?id=922257#c1
could/should be closed now, as this is done automatically from %
configure, so no need update it anymore ?
we had updated dpkg some major versions sine bug opened, how I know if
dpkg is now ready for aarch64 ?
When I fixed one of my packages (libhocr), I chose a different fix:
* Added: BuildRequires: autoconf, automake, libtool, pkgconfig
* In %prep added: autoreconf --install --force
IMO this is better then the new rpm kludge:
* In autotools based projects, the tarball contain *many* generated files.
(e.g: configure, config.h.in, config.{guess,sub}, INSTALL, etc.}
* The only reason they are in the tarball is to enable build without
the autotools suite (e.g: on other platforms)
* As such, these files are not [and should not be] committed to version
control systems.
* So although they are packages in the source tarball, they are no
part of the package real source -- they just happen to
come from the platform of the one who maintain the source tarball.
(via make dist)
* The autoreconf solution let autotools handle this complete problem
without trying to mess in its internals (rpm replacing only some files).
* As an example how wrong it is for rpm macros to interfere with the
internal logic of autotools, you could have a look in %GNUconfigure
macro in /usr/lib/rpm/macros. This one, tries to second guess
autoconf behavior, but it still search for configure.in files.
(For those who don't know -- while these files are still supported,
most modern packages correctly renamed them to configure.ac).
In the Fedora spirit of everything buildable from clean sources, I think
the autoreconf solution should be globally adopted (regardless of aarch64):
* It doesn't use generated files as input to the build process.
* It delegates the actual management to where it belongs.
Bye,
--
Oron Peled Voice: +972-4-8228492
o...@actcom.co.il http://users.actcom.co.il/~oron
In theory, there is no difference between theory and practice. In practice,
there is.
-- Yogi Berra
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
bugzilla.redhat.com vs upstream bug trackers
I'm wondering what the current guidelines for filing bugs on bugzilla.redhat.com are. https://fedoraproject.org/wiki/Bugs_and_feature_requests welcomes filing enhancement requests, but some package maintainers disagree and require filing bugs upstream. I would like to avoid creating accounts in gazillion upstream bug trackers, so bugzilla.redhat.com as a single point of contact is very helpful to me. Is the web page I mentioned outdated, or are package maintainers expected to handle upstream bug tracker interactions? -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)
Am Montag, den 17.06.2013, 11:39 +0300 schrieb Oron Peled:
On Monday 17 June 2013 02:13:06 Sérgio Basto wrote:
Hi,
I'm trying follow this (aarch64 support) but
https://bugzilla.redhat.com/show_bug.cgi?id=922257#c1
could/should be closed now, as this is done automatically from %
configure, so no need update it anymore ?
we had updated dpkg some major versions sine bug opened, how I know if
dpkg is now ready for aarch64 ?
When I fixed one of my packages (libhocr), I chose a different fix:
* Added: BuildRequires: autoconf, automake, libtool, pkgconfig
* In %prep added: autoreconf --install --force
IMO this is better then the new rpm kludge:
* In autotools based projects, the tarball contain *many* generated files.
(e.g: configure, config.h.in, config.{guess,sub}, INSTALL, etc.}
* The only reason they are in the tarball is to enable build without
the autotools suite (e.g: on other platforms)
* As such, these files are not [and should not be] committed to version
control systems.
* So although they are packages in the source tarball, they are no
part of the package real source -- they just happen to
come from the platform of the one who maintain the source tarball.
(via make dist)
* The autoreconf solution let autotools handle this complete problem
without trying to mess in its internals (rpm replacing only some files).
* As an example how wrong it is for rpm macros to interfere with the
internal logic of autotools, you could have a look in %GNUconfigure
macro in /usr/lib/rpm/macros. This one, tries to second guess
autoconf behavior, but it still search for configure.in files.
(For those who don't know -- while these files are still supported,
most modern packages correctly renamed them to configure.ac).
In the Fedora spirit of everything buildable from clean sources, I think
the autoreconf solution should be globally adopted (regardless of aarch64):
* It doesn't use generated files as input to the build process.
* It delegates the actual management to where it belongs.
Bye,
--
Oron Peled Voice: +972-4-8228492
o...@actcom.co.il http://users.actcom.co.il/~oron
In theory, there is no difference between theory and practice. In practice,
there is.
-- Yogi Berra
Hi Oron!
I completely agree to this. Using `autoreconf -fi` in %build or %prep
should be mandatory in packages using autotools. This will surely avoid
lots of possible problems caused by just injecting config.{guess,sub} by
%configure.
Cheers,
Björn
signature.asc
Description: This is a digitally signed message part
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Please test dracut-029-1.fc19!!
https://admin.fedoraproject.org/updates/FEDORA-2013-10871/dracut-029-1.fc19 Thank you! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
On Tue, 2013-06-11 at 07:47 +0200, Stef Walter wrote: even special locations for *particularly* braindamaged applications (pidgin). Hmmm, we should probably fix that one to use the central stuff. David, if we've missed any others in Fedora 19, could you file RHBZ bugs? I will, yes. I'm inferring that you *don't* need me to file a bug for pidgin because you're already looking at it? Is that (still) correct? -- dwmw2 smime.p7s Description: S/MIME cryptographic signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 17 Jun 2013 09:04:02 +0200
Dan Horák d...@danny.cz wrote:
On Mon, 17 Jun 2013 08:44:52 +0200
Simone Caronni negativ...@gmail.com wrote:
On 17 June 2013 03:13, Sérgio Basto ser...@serjux.com wrote:
we had updated dpkg some major versions sine bug opened, how I
know if dpkg is now ready for aarch64 ?
I've discovered you can trigger builds for the ARM Koji instance
with your account:
koji --server=http://arm.koji.fedoraproject.org/kojihub build
--scratch f19 dpkg.src.rpm
the fedora-packager package provides wrappers for the koji command for
all secondary architectures in Fedora in the form ${arch}-koji, where
arch can be arm, ppc and s390, so you can use
arm-koji build --scratch f19 your.src.rpm
but you can not yet build aarch64 in koji
Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlG+9SAACgkQkSxm47BaWff1RwCfV7Y8ehblXK/PvqdXWnXi8IfW
IfYAoK9++/dGMjVCZbzPdMrxHxMyMQax
=PNg5
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Soname bump libpng (rawhide) - new libraries libpng.16.so and libpng16.so.16.2.0
On 06/13/2013 01:26 PM, Petr Hracek wrote: On 05/30/2013 07:48 PM, Kalev Lember wrote: 2013-05-30 10:07, Petr Hracek skrev: Ok, well. It seems that libpng15 compatibility package is built in rawhide. What are the next steps? Tagged already built libpng(1.6) package? I do not want to break rawhide completely and I would like to avoid all mistakes which can be done from my side. If I understand whole process then I can tagged libpng package again Yes, I believe it should now be fine to tag the libpng 1.6 build back into rawhide. It seems to have been tagged with trashcan in the mean time, but if you tag it with f20 again, koji should be smart enough to figure out that it's in use again and will stop the garbage collection process for that build. http://fedoraproject.org/wiki/Koji/GarbageCollection and create a lot of bugzillas for support libpng1.6, right? No, I don't think you should create any bugzilla tickets at this point. I would advise the following course of action: 1) Re-add libpng 1.6 back into rawhide. 2) There seems to be one package that requires libpng 1.5 pkgconfig file -- gdk-pixbuf2 -- I will rebuild it. $ repoquery --whatrequires 'pkgconfig(libpng15)' 3) Find someone (provenpackager / rel-eng) to rebuild all other libpng15 using packages (repoquery --whatrequires libpng15). This should be easy in the sense that it shouldn't require any build ordering -- just fire off 500 rebuilds. 4) Give it a few days -- package maintainers need time to fix up any failed builds. 5) Do another 'repoquery --whatrequires libpng15' to see what packages failed to rebuild and haven't been fixed up by that time, and possibly file bugzilla tickets then, if you want to. 6) There is likely going to be a F20 mass rebuild at a later time, where all the remaining packages hopefully get rebuilt. 7) Retire the libpng15 package (or keep it alive for F20 and retire in F21, if it turns out there are still packages needing it). Hope this helps, Kalev Hello Kalev, well on the Monday I will tag libpng 1.6 back again into rawhide. If possible I will make some rebuilds either with help of some proven packager or with rel-eng. I do not want to do that before weekend. Finally I have tagged libpng (with 1.6 version) again into rawhide. There is already libpng15 compatibility package. -- Best regards / S pozdravem Petr Hracek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20130617 changes
Compose started at Mon Jun 17 08:15:02 UTC 2013 Broken deps for x86_64 -- [aries-blueprint] aries-blueprint-0.3.1-5.fc19.noarch requires asm2 [aries-proxy] aries-proxy-0.3-4.fc19.noarch requires asm2 [cxf] 1:cxf-rt-2.6.6-1.fc19.noarch requires asm2 [drbd] drbd-heartbeat-8.4.2-2.fc19.x86_64 requires heartbeat [ekiga] ekiga-4.0.1-1.fc19.x86_64 requires libedata-book-1.2.so.17()(64bit) [gdb-heap] gdb-heap-0.5-12.fc19.x86_64 requires glibc(x86-64) = 0:2.17 [gnuplot] gnuplot-4.6.2-2.fc20.x86_64 requires libgd.so.2()(64bit) gnuplot-minimal-4.6.2-2.fc20.x86_64 requires libgd.so.2()(64bit) [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [kawa] 1:kawa-1.11-5.fc19.x86_64 requires servlet25 [koji] koji-vm-1.8.0-1.fc20.noarch requires python-virtinst [kscreen] 1:kscreen-0.0.92-1.fc20.x86_64 requires libkscreen.so.0()(64bit) 1:kscreen-0.0.92-1.fc20.x86_64 requires libkscreen(x86-64) = 1:0.0.92 [kyua-cli] kyua-cli-0.5-3.fc19.x86_64 requires liblutok.so.0()(64bit) kyua-cli-tests-0.5-3.fc19.x86_64 requires liblutok.so.0()(64bit) [lancet] lancet-1.0.1-6.fc19.noarch requires ant-nodeps = 0:1.7.1 [nodejs-better-assert] nodejs-better-assert-1.0.0-1.fc20.noarch requires npm(callsite) = 0:1.0.0 [openbox] gdm-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel gnome-panel-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel [openlierox] openlierox-0.59-0.11.beta10.fc20.x86_64 requires libgd.so.2()(64bit) [ovirt-engine] ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires classpathx-mail [ovirt-guest-agent] ovirt-guest-agent-gdm-plugin-1.0.6-6.fc19.x86_64 requires libgdmsimplegreeter.so.1()(64bit) [oyranos] oyranos-libs-0.4.0-7.fc19.i686 requires libraw.so.5 oyranos-libs-0.4.0-7.fc19.x86_64 requires libraw.so.5()(64bit) [perl-Bio-ASN1-EntrezGene] perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) [perl-Bio-SamTools] perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) [perl-PDL] perl-PDL-2.4.10-6.fc19.x86_64 requires libgd.so.2()(64bit) [python-TraitsBackendQt] python-TraitsBackendQt-3.5.0-5.fc19.noarch requires python-TraitsGUI [python-flask-admin] python-flask-admin-1.0.5-3.fc20.noarch requires python-wtf-peewee [qpid-cpp] qpid-qmf-0.22-1.1.fc20.i686 requires python-qpid = 0:0.22 qpid-qmf-0.22-1.1.fc20.x86_64 requires python-qpid = 0:0.22 [ruby-RMagick] ruby-RMagick-2.13.1-11.fc20.1.x86_64 requires ImageMagick = 0:6.8.3.9 [rubygem-openshift-origin-common] rubygem-openshift-origin-common-1.8.10-1.fc20.noarch requires rubygem(safe_yaml) [rubygem-openshift-origin-node] rubygem-openshift-origin-node-1.9.15-1.fc20.noarch requires rubygem(safe_yaml) rubygem-openshift-origin-node-1.9.15-1.fc20.noarch requires openshift-origin-node-proxy [rubygem-qpid] rubygem-qpid-0.16.0-14.fc20.x86_64 requires libqpidtypes.so.1()(64bit) rubygem-qpid-0.16.0-14.fc20.x86_64 requires libqpidmessaging.so.3()(64bit) rubygem-qpid-0.16.0-14.fc20.x86_64 requires libqpidcommon.so.5()(64bit) rubygem-qpid-0.16.0-14.fc20.x86_64 requires libqpidclient.so.5()(64bit) [rubygem-qpid_messaging] rubygem-qpid_messaging-0.20.2-1.fc19.x86_64 requires libqpidtypes.so.1()(64bit) rubygem-qpid_messaging-0.20.2-1.fc19.x86_64 requires libqpidmessaging.so.3()(64bit) rubygem-qpid_messaging-0.20.2-1.fc19.x86_64 requires libqpidcommon.so.5()(64bit) rubygem-qpid_messaging-0.20.2-1.fc19.x86_64 requires libqpidclient.so.5()(64bit) [sagemath] sagemath-core-5.9-5.fc20.i686 requires libgd.so.2 sagemath-core-5.9-5.fc20.x86_64 requires libgd.so.2()(64bit) [scala] scala-2.9.2-2.fc19.noarch requires osgi(org.scala-ide.scala.library) [shim-signed] shim-0.2-4.4.fc20.x86_64 requires shim-unsigned = 0:0.3-2.fc20 [spacewalk-web] spacewalk-dobby-1.9.22-2.fc19.noarch requires perl(Spacewalk::Setup) [spring] spring-94.1-1.fc20.x86_64 requires libassimp.so.2()(64bit) [sumwars] sumwars-0.5.6-12.fc20.x86_64 requires libenet-1.3.7.so()(64bit) [tex-simplecv] tex-simplecv-doc-1.6-12.fc19.noarch requires texlive-texmf-doc [texlive] 2:texlive-dvipng-bin-svn30088.0-24.20130531_r30819.fc20.x86_64 requires libgd.so.2()(64bit) [zarafa] libmapi-7.0.13-1.fc19.i686 requires libicalss.so.0 libmapi-7.0.13-1.fc19.i686 requires libical.so.0 libmapi-7.0.13-1.fc19.x86_64 requires libicalss.so.0()(64bit) libmapi-7.0.13-1.fc19.x86_64 requires libical.so.0()(64bit) php-mapi-7.0.13-1.fc19.x86_64 requires php(zend-abi)
Re: bugzilla.redhat.com vs upstream bug trackers
Florian Weimer wrote: I would like to avoid creating accounts in gazillion upstream bug trackers, so bugzilla.redhat.com as a single point of contact is very helpful to me. Is the web page I mentioned outdated, or are package maintainers expected to handle upstream bug tracker interactions? It is (imo) generally the package maintainer's discretion. Obviously, if it's something they are interested in or is important, it likely is in their best interest to help move feature requests upstream. If not, well, then that burden is probably best left to you (or some other interested party). -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 968425] perl-XML-Writer-0.623 is available
https://bugzilla.redhat.com/show_bug.cgi?id=968425 --- Comment #8 from Petr Pisar ppi...@redhat.com --- Done. -- 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=wbqniArq0ea=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: bugzilla.redhat.com vs upstream bug trackers
On 06/17/2013 12:40 PM, Rex Dieter wrote: Florian Weimer wrote: I would like to avoid creating accounts in gazillion upstream bug trackers, so bugzilla.redhat.com as a single point of contact is very helpful to me. Is the web page I mentioned outdated, or are package maintainers expected to handle upstream bug tracker interactions? It is (imo) generally the package maintainer's discretion. Obviously, if it's something they are interested in or is important, it likely is in their best interest to help move feature requests upstream. If not, well, then that burden is probably best left to you (or some other interested party) It's package maintainers responsibility to act as the liason between upstream and Fedora thus reporters only need to report in our Bugzilla instance. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-19 Branched report: 20130617 changes
Compose started at Mon Jun 17 09:15:03 UTC 2013 Broken deps for x86_64 -- [avgtime] avgtime-0-0.5.git20120724.fc19.x86_64 requires libphobos-ldc.so.60()(64bit) [derelict] derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires ogg derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires OGG derelict-ogg-3-13.20130516gitd8aa11d.fc19.x86_64 requires ogg derelict-ogg-3-13.20130516gitd8aa11d.fc19.x86_64 requires OGG derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires ogg derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires OGG derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires ogg derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires OGG derelict-pq-3-13.20130516gitd8aa11d.fc19.i686 requires pq derelict-pq-3-13.20130516gitd8aa11d.fc19.i686 requires PQ derelict-pq-3-13.20130516gitd8aa11d.fc19.x86_64 requires pq derelict-pq-3-13.20130516gitd8aa11d.fc19.x86_64 requires PQ derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.i686 requires pq derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.i686 requires PQ derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires pq derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires PQ derelict-tcod-3-13.20130516gitd8aa11d.fc19.i686 requires tcod derelict-tcod-3-13.20130516gitd8aa11d.fc19.i686 requires TCOD derelict-tcod-3-13.20130516gitd8aa11d.fc19.x86_64 requires tcod derelict-tcod-3-13.20130516gitd8aa11d.fc19.x86_64 requires TCOD derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.i686 requires tcod derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.i686 requires TCOD derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires tcod derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires TCOD [dragonegg] dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19 [dsqlite] dsqlite-1.0-4.fc19.i686 requires libphobos-ldc.so.60 dsqlite-1.0-4.fc19.x86_64 requires libphobos-ldc.so.60()(64bit) [dustmite] dustmite-1-8.20121031git1fb3ac4.fc18.x86_64 requires libphobos-ldc.so.60()(64bit) [freeipa] freeipa-server-strict-3.2.1-1.fc19.x86_64 requires pki-ca = 0:10.0.2 freeipa-server-strict-3.2.1-1.fc19.x86_64 requires 389-ds-base = 0:1.3.1.0 [gl3n] gl3n-0.20120813-4.fc19.i686 requires libphobos-ldc.so.60 gl3n-0.20120813-4.fc19.x86_64 requires libphobos-ldc.so.60()(64bit) [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [kawa] 1:kawa-1.11-5.fc19.x86_64 requires servlet25 [koji] koji-vm-1.8.0-1.fc19.noarch requires python-virtinst [libkolab] php-kolab-0.4.1-3.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-kolab-0.4.1-3.fc19.x86_64 requires php(api) = 0:20100412-x86-64 [nodejs-tilelive] nodejs-tilelive-4.4.3-2.fc19.noarch requires npm(optimist) 0:0.4 [openbox] gdm-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel gnome-panel-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel [ovirt-engine] ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires classpathx-mail [ovirt-guest-agent] ovirt-guest-agent-gdm-plugin-1.0.6-6.fc19.x86_64 requires libgdmsimplegreeter.so.1()(64bit) [perl-Bio-ASN1-EntrezGene] perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) [perl-Bio-SamTools] perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) [python-TraitsBackendQt] python-TraitsBackendQt-3.5.0-5.fc19.noarch requires python-TraitsGUI [scala] scala-2.9.2-2.fc19.noarch requires osgi(org.scala-ide.scala.library) [spacewalk-web] spacewalk-dobby-1.9.22-2.fc19.noarch requires perl(Spacewalk::Setup) [stoken] stoken-devel-0.2-4.fc19.i686 requires pkgconfig(libtomcrypt) stoken-devel-0.2-4.fc19.x86_64 requires pkgconfig(libtomcrypt) [tango] tango-2-12.20120821git7b92443.fc19.i686 requires libphobos-ldc.so.60 tango-2-12.20120821git7b92443.fc19.x86_64 requires libphobos-ldc.so.60()(64bit) [zarafa] php-mapi-7.0.13-1.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-mapi-7.0.13-1.fc19.x86_64 requires php(api) = 0:20100412-x86-64 Broken deps for i386 -- [avgtime] avgtime-0-0.5.git20120724.fc19.i686 requires libphobos-ldc.so.60 [derelict] derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires ogg derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires OGG derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires ogg derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686
Re: bugzilla.redhat.com vs upstream bug trackers
On Mon, Jun 17, 2013 at 4:52 AM, Florian Weimer wrote: I would like to avoid creating accounts in gazillion upstream bug trackers, Aha! Should the package maintainers play the middle man in the gazillion upstream bug tracker accounts? This sounds neither very thoughtful nor quite efficient. so bugzilla.redhat.com as a single point of contact is very helpful to me. I wish life was that easy! Is the web page I mentioned outdated, or are package maintainers expected to handle upstream bug tracker interactions? Basically, if it is RPM packaging specific enhancement/bug, or if upstream uses bugzilla.redhat.com as their primary bugtracker (some do), then definitely bugzilla.redhat.com. Otherwise, common sense (and thoughtfulness :) ). Cheers, Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
On 06/17/2013 01:00 PM, Orcan Ogetbil wrote: On Mon, Jun 17, 2013 at 4:52 AM, Florian Weimer wrote: I would like to avoid creating accounts in gazillion upstream bug trackers, Aha! Should the package maintainers play the middle man in the gazillion upstream bug tracker accounts? This sounds neither very thoughtful nor quite efficient. It's your responsibility as an maintainer in the distribution to be in contact with upstream, subscribed to their mailing lists, have an account in their upstream tracker and participate in their upstream community so yes that comes with the territory of being a responsible maintainer in the distribution... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
On Mon, 17 Jun 2013 13:02:04 +, Jóhann B. Guðmundsson wrote: On 06/17/2013 01:00 PM, Orcan Ogetbil wrote: On Mon, Jun 17, 2013 at 4:52 AM, Florian Weimer wrote: I would like to avoid creating accounts in gazillion upstream bug trackers, Aha! Should the package maintainers play the middle man in the gazillion upstream bug tracker accounts? This sounds neither very thoughtful nor quite efficient. It's your responsibility as an maintainer in the distribution to be in contact with upstream, subscribed to their mailing lists, have an account in their upstream tracker and participate in their upstream community so yes that comes with the territory of being a responsible maintainer in the distribution... Let's not argue about it again and again, please. What works well for some packages and some software projects, isn't always feasible. https://fedoraproject.org/wiki/Package_maintainer_responsibilities#Work_with_upstream Oh, and btw, we need more (co-)maintainers for packages. -- Michael Schwendt Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.5-301.fc19.x86_64 loadavg: 0.02 0.09 0.07 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
* Jóhann B. Guðmundsson [17/06/2013 12:49] : It's package maintainers responsibility to act as the liason between upstream and Fedora thus reporters only need to report in our Bugzilla instance. Even when upstream has requested that their bug tracker be the only one used? Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
On Mon, Jun 17, 2013 at 10:52 AM, Florian Weimer fwei...@redhat.com wrote: I'm wondering what the current guidelines for filing bugs on bugzilla.redhat.com are. https://fedoraproject.org/wiki/Bugs_and_feature_requests welcomes filing enhancement requests, but some package maintainers disagree and require filing bugs upstream. The only way I can read https://fedoraproject.org/wiki/Package_maintainer_responsibilities#Deal_with_reported_bugs_in_a_timely_manner is that bugzilla.redhat.com should be used and not ignored. OTOH that's the written policy, not the actual state, which is that some package maintainers disagree - usually, for what is, from an individual point of view, a good reason. In general I'd say that packages where the maintainer that don't have the time, interest or willingness to handle bugzilla.redhat.com reports, should get comaintainers if at all possible. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
Emmanuel Seyman píše v Po 17. 06. 2013 v 15:39 +0200: * Jóhann B. Guðmundsson [17/06/2013 12:49] : It's package maintainers responsibility to act as the liason between upstream and Fedora thus reporters only need to report in our Bugzilla instance. Even when upstream has requested that their bug tracker be the only one used? Well, I think Red Hat Bugzilla should always be the default option. We really can't require users to report in other bugzillas. Of course, if someone is more experienced, more into testing, and want to help developers/packagers, then they can do whatever works better for them. For example, I know that our maintainers of GNOME appreciate bugs reported directly to GNOME bugzilla because there is a little or zero delta between upstream and Fedora. So if it's a bug that doesn't influence Fedora release or something, I report it directly to GNOME bugzilla. If it's something I found during focused testing of Fedora or if it might be a release blocker, I always report it to the Red Hat bugzilla, too. But I do believe that the general rule should be to report bugs in RH bugzilla. And that's what we should advertise among users and what maintainers should be ready for. Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
On 17.06.2013 13:22, David Woodhouse wrote: On Tue, 2013-06-11 at 07:47 +0200, Stef Walter wrote: even special locations for *particularly* braindamaged applications (pidgin). Hmmm, we should probably fix that one to use the central stuff. David, if we've missed any others in Fedora 19, could you file RHBZ bugs? I will, yes. I'm inferring that you *don't* need me to file a bug for pidgin because you're already looking at it? Is that (still) correct? Would be helpful to file a bug ... to make sure we're talking about the samething.. Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: icedtea-web installed and enabled by default in Fedora 19
Florian Weimer (fwei...@redhat.com) said: I noticed that icedtea-web (the Java browser plugin implementation for OpenJDK) is installed and enabled by default (as part of the GNOME Desktop set). This is a bit surprising, considering that the rest of the world tries to move away from Java browser plugin technology (and even browser plugin technology in general). We cannot really remove installed packages after the release, so I'm wondering if we still can fix this prior to release. We could, I suppose. What do people think? (It's just one line in comps.) Nearly all live images drop it for space reasons. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
On 06/17/2013 01:39 PM, Emmanuel Seyman wrote: * Jóhann B. Guðmundsson [17/06/2013 12:49] : It's package maintainers responsibility to act as the liason between upstream and Fedora thus reporters only need to report in our Bugzilla instance. Even when upstream has requested that their bug tracker be the only one used? Yes it's the distribution maintainers responsibility to forward that request upstream if that is the case followed by notifying the reporter they have done so with a link to the upstream report in the relevant bug report in bugzilla.redhat.com. We do not forward reporters to upstream bugzilla's so if packagers/maintainers refuse to use our own bug tracker ( Like the Red Hat's Gnome developers do ) we spread the word amongst report not to file *any* report against Gnome because it wont be look at anyway. We have ca 15000 components in distribution so we dont waist time and energy having reporters file reports on components in the distribution which wont be looked at anyway regardless if you are only using the upstream tracker or simply dont respond to bug reports et all. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)
On Mon, Jun 17, 2013 at 2:59 AM, Björn Esser bjoern.es...@gmail.com wrote:
I completely agree to this. Using `autoreconf -fi` in %build or %prep
should be mandatory in packages using autotools. This will surely avoid
lots of possible problems caused by just injecting config.{guess,sub} by
%configure.
That would only work if the autotools had perfect backwards
compatibility. They don't. I maintain multiple packages where
autoreconf -fi with modern autotools fails due to use of obsolete
macros.
--
Jerry James
http://www.jamezone.org/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
On Mon, 2013-06-17 at 14:34 +, Jóhann B. Guðmundsson wrote: refuse to use our own bug tracker ( Like the Red Hat's Gnome developers do ) Stop saying that, it's not true. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: icedtea-web installed and enabled by default in Fedora 19
- Original Message - Florian Weimer (fwei...@redhat.com) said: I noticed that icedtea-web (the Java browser plugin implementation for OpenJDK) is installed and enabled by default (as part of the GNOME Desktop set). This is a bit surprising, considering that the rest of the world tries to move away from Java browser plugin technology (and even browser plugin technology in general). We cannot really remove installed packages after the release, so I'm wondering if we still can fix this prior to release. We could, I suppose. What do people think? (It's just one line in comps.) Nearly all live images drop it for space reasons. I think given all the trouble this plugin has caused recently, it wouldn't be wise to install it for everyone. If you need it, great, install it, but if a users doesn't need it, it's really just creating a level of risk we probably don't want. Fedora currently has a reputation for being pretty secure, I think this could damage that reputation. Thanks. -- Josh Bressers / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)
On 2013-06-17 16:43, Jerry James wrote:
On Mon, Jun 17, 2013 at 2:59 AM, Björn Esser bjoern.es...@gmail.com wrote:
I completely agree to this. Using `autoreconf -fi` in %build or %prep
should be mandatory in packages using autotools. This will surely avoid
lots of possible problems caused by just injecting config.{guess,sub} by
%configure.
That would only work if the autotools had perfect backwards
compatibility. They don't. I maintain multiple packages where
autoreconf -fi with modern autotools fails due to use of obsolete
macros.
--
Jerry James
http://www.jamezone.org/
Isn't the proper solution then to patch the config files to get rid of
the obsolete macros? Such patches should certainly be acceptable upstream.
That said, this and related questions have been discussed in several
threads over the years. The sad fact is that it hasn't been possible to
find an agreement how to cope with autotools and that we thus havn't
much about them in the guidelines.
What are the chances finding common ground now?
--alec
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: icedtea-web installed and enabled by default in Fedora 19
Josh Bressers (bress...@redhat.com) said: - Original Message - Florian Weimer (fwei...@redhat.com) said: I noticed that icedtea-web (the Java browser plugin implementation for OpenJDK) is installed and enabled by default (as part of the GNOME Desktop set). This is a bit surprising, considering that the rest of the world tries to move away from Java browser plugin technology (and even browser plugin technology in general). We cannot really remove installed packages after the release, so I'm wondering if we still can fix this prior to release. We could, I suppose. What do people think? (It's just one line in comps.) Nearly all live images drop it for space reasons. I think given all the trouble this plugin has caused recently, it wouldn't be wise to install it for everyone. If you need it, great, install it, but if a users doesn't need it, it's really just creating a level of risk we probably don't want. Fedora currently has a reputation for being pretty secure, I think this could damage that reputation. The one issue I can see with removing it is that the plugin finder you then get in Firefox if you hit a Java site doesn't work to actually get you the Fedora version. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: icedtea-web installed and enabled by default in Fedora 19
On Jun 17, 2013 8:03 AM, Bill Nottingham nott...@redhat.com wrote: The one issue I can see with removing it is that the plugin finder you then get in Firefox if you hit a Java site doesn't work to actually get you the Fedora version. I would keep it if people really use it. I'm on the opposite side, where if I'm doing anything Android related (or other various things) I must use sun jdk/jre. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
poppler soname bump in rawhide
Hi, I plan to rebase poppler in rawhide to poppler-0.22.4 at the beginning of the next week (24th of June). There are several changes (new parameters of some functions and new private members of some classes (Stream, Gfx, DCTStream and TextWord)) and 1 soname bump (libpoppler.so.34 to libpoppler.so.37). Regards Marek ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
On 06/17/2013 02:52 PM, Colin Walters wrote: On Mon, 2013-06-17 at 14:34 +, Jóhann B. Guðmundsson wrote: refuse to use our own bug tracker ( Like the Red Hat's Gnome developers do ) Stop saying that, it's not true. What's not true that Red Hat Gnome developers having been trying to push Fedora reporters upstream for years and that their attitude is not well known in the QA community? Yeah sure maybe not all of you ( and reporters quickly learn who respond to bug reports and who dont ) but here's this development cycle remarks of it... [1] From Martin... Please developers have a look at the following bugs (if you didn't yet) as one of motivations for users to attend Test Days is that found bugs will be fixed soon via updates after installation. Note, after almost 3 months there are lot of NEW bugs in Red Hat Bugzilla in contrast to many RESOLVED in Gnome Bugzilla. If you need any help with triaging bugs and testing bugfixes, feel free to contact me. And Adam... Desktop team...I know you have this thing about not reading RH bugs...but it really does mean you miss out on what looks like some valuable information. Can't it be re-considered? Couldn't you at least task someone to take a sweep through the Test Day bugs? Maybe you should accept the truth that is instead of accusing others of lying here. JBG 1. https://lists.fedoraproject.org/pipermail/desktop/2013-June/008096.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
General/Bugzilla: mail-headers Precedence: bulk / Auto-Submitted: auto-generated
Hi where to file a bug for the redhat bugzilla? on our mailserver i see a auto-reply h.rei...@thelounge.net - bugzi...@redhat.com with the two mail-headers below which are *highly* recommended for any software which is generating emails a sane autoresponder would supress replies as well as for Precedence: list which is used from any mailing-list software except Oracle ___ Precedence: bulk Auto-Submitted: auto-generated ___ http://tools.ietf.org/html/rfc3834#section-5 http://www.redmine.org/projects/redmine/repository/revisions/2655/diff http://stackoverflow.com/questions/154718/precedence-header-in-email signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
Am 17.06.2013 15:00, schrieb Orcan Ogetbil: On Mon, Jun 17, 2013 at 4:52 AM, Florian Weimer wrote: I would like to avoid creating accounts in gazillion upstream bug trackers, Aha! Should the package maintainers play the middle man in the gazillion upstream bug tracker accounts? This sounds neither very thoughtful nor quite efficient. i expect a *package maintain er* has already a account in the upstream tracker of packages he maintains - nobody says he needs a gazillion accounts, but usually he has for the packages he maintains the ordinary user has a few thousand packages installed so bugzilla.redhat.com as a single point of contact is very helpful to me. I wish life was that easy! it should be that easy answering in a bugreport file the bugreport upstream is the best way after the third time never ever get any bugrpeort from this person Basically, if it is RPM packaging specific enhancement/bug does not matter from the viewpoint of a *ordinary user* nor is he able to know if it is the case or if upstream uses bugzilla.redhat.com as their primary bugtracker does not matter from the viewpoint of a *ordinary user* signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: icedtea-web installed and enabled by default in Fedora 19
From my point of view the java-plugin is a big security hole and should be kicked from default installations ASAP. 2013/6/17 Dan Mashal dan.mas...@gmail.com On Jun 17, 2013 8:03 AM, Bill Nottingham nott...@redhat.com wrote: The one issue I can see with removing it is that the plugin finder you then get in Firefox if you hit a Java site doesn't work to actually get you the Fedora version. I would keep it if people really use it. I'm on the opposite side, where if I'm doing anything Android related (or other various things) I must use sun jdk/jre. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Mit freundlichen Grüßen Heiko Adams Die Bildzeitung – dieses Drecksblatt, dass so widerlich ist, dass man toten Fisch beleidigt, wenn man ihn darin einwickelt! (Volker Pispers) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: icedtea-web installed and enabled by default in Fedora 19
On 17.06.2013 17:18, Heiko Adams wrote: From my point of view the java-plugin is a big security hole and should be kicked from default installations ASAP. Then, why not fix it? Mateusz Marzantowicz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)
On Mon, 17 Jun 2013 10:59:06 +0200, Björn Esser wrote:
I completely agree to this. Using `autoreconf -fi` in %build or %prep
should be mandatory in packages using autotools.
One problem with that is, one cannot blindly run autoreconf -fi and
expect it to be 100% compatible with the multitude of Autotools' based
projects. Typically one will need to update the configure script, m4
macros as well as Makefile.{am,in} templates. And if one doesn't verify
the build framework, one can miss files where regenerating them drops
stuff (as one example, config.h.in files where someone has inserted
stuff the wrong way).
--
Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.5-301.fc19.x86_64
loadavg: 0.13 0.12 0.08
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
Le lundi 17 juin 2013 à 10:52 +0200, Florian Weimer a écrit : I'm wondering what the current guidelines for filing bugs on bugzilla.redhat.com are. https://fedoraproject.org/wiki/Bugs_and_feature_requests welcomes filing enhancement requests, but some package maintainers disagree and require filing bugs upstream. I would like to avoid creating accounts in gazillion upstream bug trackers, If only more bug trackers would accept openid, this would make the issue less problematic for all. There is a plugin for that : https://wiki.mozilla.org/Bugzilla:OpenID_Auth_Plugin So is there any reason to not offer it, or I can start filling bug to request it ? -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: icedtea-web installed and enabled by default in Fedora 19
On 06/17/2013 05:03 PM, Bill Nottingham wrote: The one issue I can see with removing it is that the plugin finder you then get in Firefox if you hit a Java site doesn't work to actually get you the Fedora version. Hmm. Our Firefox has a pretty clear fingerprint over HTTPS (no user agent branding and lack of ECC support), so perhaps Mozilla could use this information to provide a better recommendation to users? -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: icedtea-web installed and enabled by default in Fedora 19
Because IMHO Java itself is the security problem but it's easier to remove the plugin because there are AFAIK no packages which require it and are relevant to normal desktop users.http://www.dict.cc/englisch-deutsch/vector.html 2013/6/17 Mateusz Marzantowicz mmarzantow...@osdf.com.pl On 17.06.2013 17:18, Heiko Adams wrote: From my point of view the java-plugin is a big security hole and should be kicked from default installations ASAP. Then, why not fix it? Mateusz Marzantowicz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Mit freundlichen Grüßen Heiko Adams Die Bildzeitung – dieses Drecksblatt, dass so widerlich ist, dass man toten Fisch beleidigt, wenn man ihn darin einwickelt! (Volker Pispers) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: General/Bugzilla: mail-headers Precedence: bulk / Auto-Submitted: auto-generated
On Mon, 17 Jun 2013 14:59:19 +0200 Reindl Harald h.rei...@thelounge.net wrote: Hi where to file a bug for the redhat bugzilla? In bugzilla.redhat.com ;) https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzillaversion=4.4 kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
- Original Message - Am 17.06.2013 15:00, schrieb Orcan Ogetbil: On Mon, Jun 17, 2013 at 4:52 AM, Florian Weimer wrote: I would like to avoid creating accounts in gazillion upstream bug trackers, Aha! Should the package maintainers play the middle man in the gazillion upstream bug tracker accounts? This sounds neither very thoughtful nor quite efficient. i expect a *package maintain er* has already a account in the upstream tracker of packages he maintains - nobody says he needs a gazillion accounts, but usually he has for the packages he maintains the ordinary user has a few thousand packages installed so bugzilla.redhat.com as a single point of contact is very helpful to me. I wish life was that easy! it should be that easy answering in a bugreport file the bugreport upstream is the best way after the third time never ever get any bugrpeort from this person I really don't want to repeat this neverending thread again but it's all about attitude of maintainer. If you get file the bugreport upstream DOT - without explanation, without reason. Yes - it's definitely the last report from that person. If you politely ask to report bug upstream, as it's really upstream job, you don't want to be man in the middle, but you CC on the bug and offer a help in case of problems or just say - if you can't report upstream, we will help you, you will actually get one more contributor. And I'd say it's our job too. And yeah, I'm not saying it's easy - different bug reporting tools, different workflows. Especially for very specific ones without any documentation, maintainer should be that one who offers help first. My 1 CZK. Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
On 06/17/2013 03:29 PM, Michael Scherer wrote: Le lundi 17 juin 2013 à 10:52 +0200, Florian Weimer a écrit : I'm wondering what the current guidelines for filing bugs on bugzilla.redhat.com are. https://fedoraproject.org/wiki/Bugs_and_feature_requests welcomes filing enhancement requests, but some package maintainers disagree and require filing bugs upstream. I would like to avoid creating accounts in gazillion upstream bug trackers, If only more bug trackers would accept openid, this would make the issue less problematic for all. No it would not. This can be solved technically and I have already explain how to do so in the past at least between two mozilla bugzilla instances and there was some bugzilla maintainer from Red Hat ( we are not running our own bugzilla instance so we cannot hack as we please but are forced to abide to what ever internal RH bugzilla admins have set that nobody in the community knows about ) looking into it but then he quit and that effort died with him as I understood it from James at that time. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
On Mon, Jun 17, 2013 at 7:49 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: It's package maintainers responsibility to act as the liason between upstream and Fedora thus reporters only need to report in our Bugzilla instance. I think that this is a fantasy that is not going to happen unless every package maintainer's primary employment is maintaining said packages (not necessarily employed by Red Hat). I'm sure that I'm representative of many packagers out there - I'm not paid to maintain packages in Fedora, in fact any open source I get to use at work is because I've been successful at asking for forgiveness instead of permission. I maintain packages in Fedora because it allows me to get what I want to do done, whether at work or at home. Since I've done the work of making these packages, why not share them with the Fedora community? It drives me absolutely bonkers when people open bugs on the RedHat bugzilla and then insist that I do the work of coordinating with upstream because they are too busy or they don't want to create a bunch of accounts in the upstream bugtracker. I mean it drives me absolutely bonkers to the point I have trouble remaining polite. In fact I've completely ignored a bug in RedHat's bugzilla for months because of the reporter's attitude that their time was so much more valuable than mine that I can't read the bug, much less post a response without resorting to nasty four-letter words. The work that I do in maintaining my packages is my contribution back to the community that has given me so much already. For most bug reports, I'm willing to take a little bit of time and see if there's a new release I've missed or if the bug has been already identified upstream and there's a patch that can be applied. But to expect me to take a significant amount of time to work with upstream to find the bug and patch it is unrealistic because: 1) There's a 99.999% chance that I don't have the resources (either hardware or software) to reproduce the bug. 2) There's a 100% chance that I don't have the time between work and family obligations. 3) Even though I'm an excellent programmer, well versed in C and Python, and decent in Perl, Ruby, et. al. I probably don't have the familiarity with the codebase to even know where to start looking for a bug. 4) Most software is complex enough that even configuration problems are best handled by upstream because I'd be familiar with a small set of configuration scenarios, but everyone's situation is unique and understanding what exactly a configuration option does (especially in edge cases) often requires an understanding of the code behind it. All of this means that I'm a speedbump in the way of getting the bug fixed, at least until there's a patch that needs to be applied to the package, or a new release to upgrade to. -- Jeff Ollie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
On Mon, 17 Jun 2013 17:29:55 +0200 Michael Scherer m...@zarb.org wrote: Le lundi 17 juin 2013 à 10:52 +0200, Florian Weimer a écrit : I'm wondering what the current guidelines for filing bugs on bugzilla.redhat.com are. https://fedoraproject.org/wiki/Bugs_and_feature_requests welcomes filing enhancement requests, but some package maintainers disagree and require filing bugs upstream. I would like to avoid creating accounts in gazillion upstream bug trackers, If only more bug trackers would accept openid, this would make the issue less problematic for all. There is a plugin for that : https://wiki.mozilla.org/Bugzilla:OpenID_Auth_Plugin So is there any reason to not offer it, or I can start filling bug to request it ? In bugzilla.redhat.com? Feel free to request it, but I don't think it will be much of a priority. ;( Upstream bugzilla has moved to 'persona' instead of openid, and this openid plugin is pretty dead/unmaintained sadly. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: icedtea-web installed and enabled by default in Fedora 19
On Mon, 17 Jun 2013 17:09:57 +0200, Dan Mashal wrote: if I'm doing anything Android related (or other various things) I must use sun jdk/jre. Is it filed/tracked/known? Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
On Mon, 2013-06-17 at 15:16 +, Jóhann B. Guðmundsson wrote: Maybe you should accept the truth that is instead of accusing others of lying here. I was not accusing you of lying, merely of perpetuating what I consider an inaccurate characterization of reality. Could the team do more? Of course. Do some Red Hat GNOME maintaners almost completely ignore RH Bugzilla? Probably. But there are others who do respond to bugs? Yes, even a brief investigation with a list of email addresses and the Bugzilla search page would show that. Could we do with less hyperbole? Definitely. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
* Michael Schwendt [17/06/2013 17:20] : But if the original reporter refuses to join the upstream ticket for answering questions or providing further details, that can easily become tedious or even a dead end. In the case I'm facing now, the problem is trying to submit patches that have been submitted in brc without taking credit for the real reporter's work and/or making upstream's life harder by having them work in two different bug trackers. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
On 06/17/2013 03:42 PM, Jeffrey Ollie wrote: On Mon, Jun 17, 2013 at 7:49 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: It's package maintainers responsibility to act as the liason between upstream and Fedora thus reporters only need to report in our Bugzilla instance. I think that this is a fantasy that is not going to happen unless every package maintainer's primary employment is maintaining said packages (not necessarily employed by Red Hat). I'm sure that I'm representative of many packagers out there - I'm not paid to maintain packages in Fedora, in fact any open source I get to use at work is because I've been successful at asking for forgiveness instead of permission. I'm not getting paid to work on Fedora and consider myself lucky for the very few thanks I get for my work. I maintain packages in Fedora because it allows me to get what I want to do done, whether at work or at home. Since I've done the work of making these packages, why not share them with the Fedora community? Because if you cannot properly maintain the component in the distribution the community is better of without it. It drives me absolutely bonkers when people open bugs on the RedHat bugzilla and then insist that I do the work of coordinating with upstream because they are too busy or they don't want to create a bunch of accounts in the upstream bugtracker. I mean it drives me absolutely bonkers to the point I have trouble remaining polite. In fact I've completely ignored a bug in RedHat's bugzilla for months because of the reporter's attitude that their time was so much more valuable than mine that I can't read the bug, much less post a response without resorting to nasty four-letter words. The work that I do in maintaining my packages is my contribution back to the community that has given me so much already. For most bug reports, I'm willing to take a little bit of time and see if there's a new release I've missed or if the bug has been already identified upstream and there's a patch that can be applied. But to expect me to take a significant amount of time to work with upstream to find the bug and patch it is unrealistic because: 1) There's a 99.999% chance that I don't have the resources (either hardware or software) to reproduce the bug. Then you should not be maintaining that component 2) There's a 100% chance that I don't have the time between work and family obligations. We do not need unresponsive or poor maintained packages in the distribution and if there is really need or demand for the component you maintain, co-maintainers will appear or people to pick it up if you drop it so if you dont have the time to properly maintain your component(s) in the distribution then either find yourself co-maintainers or drop the package. 3) Even though I'm an excellent programmer, well versed in C and Python, and decent in Perl, Ruby, et. al. I probably don't have the familiarity with the codebase to even know where to start looking for a bug. If you aren't familiar with the component you are packaging and maintaining why are you doing it et all? 4) Most software is complex enough that even configuration problems are best handled by upstream because I'd be familiar with a small set of configuration scenarios, but everyone's situation is unique and understanding what exactly a configuration option does (especially in edge cases) often requires an understanding of the code behind it. All of this means that I'm a speedbump in the way of getting the bug fixed, at least until there's a patch that needs to be applied to the package, or a new release to upgrade to. It's component's owner responsibility to be in touch and contact with upstream and the man in the middle role of the packager/maintainer can never be entirely gotten rid of. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
On 06/17/2013 03:47 PM, Colin Walters wrote: Maybe you should accept the truth that is instead of accusing others of lying here. I was not accusing you of lying, merely of perpetuating what I consider an inaccurate characterization of reality. Could the team do more? Of course. Do some Red Hat GNOME maintaners almost completely ignore RH Bugzilla? Probably. But there are others who do respond to bugs? Yes, even a brief investigation with a list of email addresses and the Bugzilla search page would show that. Could we do with less hyperbole? Definitely. We as a community in whole cannot deal with issues like these ( and others ) until we have the means to properly health ( reports vs resolve + the time it took ) monitor a component in the distribution. Once we have that the QA community could do the triaging work to reduce the reports while it was being advertised in the community if some other maintainers could step up and assist if the component maintainership was in bad shape We probably could implement some kind of time,share process at that time as well to prevent maintainers to overload themselves which has a tendency to lead to maintainers either burning out or simply ignore all work and us loosing reporters and what not. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
On Mon, 2013-06-17 at 15:55 +, Jóhann B. Guðmundsson wrote: [...] In a community of volunteers there are two ways to treat someone's work when you are no satisfied with it: a) tell him/her, his/her work matters and push him/her to improve where you think it should be improved (eventually by getting your hands dirty to show the way). b) tell him/her that his/her work sucks but he/she is not following what you believe should be the way. I do not believe you grow a nice and healthy community by doing the second and your last email was, imho, really oriented to the option b. Please be careful with the wording you use, that's also what's implied by be nice to each other. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
On Mon, Jun 17, 2013 at 10:55 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 06/17/2013 03:42 PM, Jeffrey Ollie wrote: 3) Even though I'm an excellent programmer, well versed in C and Python, and decent in Perl, Ruby, et. al. I probably don't have the familiarity with the codebase to even know where to start looking for a bug. If you aren't familiar with the component you are packaging and maintaining why are you doing it et all? I think that's a bit unfair. While it's certainly helpful, it's not a requirement, to be a programmer in order to be a packager. I know very little C, some python, but I've learned quite a bit about building and packaging over the last few years. You often end up with packages that you need for various reasons, but that doesn't mean you're intimately familiar with all of them. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
On Mon, 17 Jun 2013 15:55:57 +, Jóhann B. Guðmundsson wrote: Because if you cannot properly maintain the component in the distribution the community is better of without it. Such rude comments don't meet the be excellent to eachother guidelines anymore, I'm afraid. Stop here, please. [Jeffrey Ollie] 1) There's a 99.999% chance that I don't have the resources (either hardware or software) to reproduce the bug. Then you should not be maintaining that component Hmmm, I find what Jeffrey has written above is phrased in an unfortunate way and may be misunderstood. But actually, for some types of software there is a higher rate of bugs which one cannot reproduce (or one isn't told how to reproduce the issue - e.g. ABRT makes it easy for users to dump such reports into bugzilla), and the backtrace isn't sufficient either to draw conclusions, and the reporter doesn't mention that other programs crash in the same way due to hardware instabilities. Enough upstreams ignore forwarded bug reports which lack details and where _they_ feel that they won't be able to reproduce the issue and where _they_ don't see a connection to mistakes in the code. In other cases they would ask with NEEDINFO queries, but downstream (in Fedora bz), the reporter doesn't respond. Spending time on such tickets is a waste of time. 2) There's a 100% chance that I don't have the time between work and family obligations. We do not need unresponsive or poor maintained packages in the distribution and if there is really need or demand for the component you maintain, co-maintainers will appear or people to pick it up if you drop it so if you dont have the time to properly maintain your component(s) in the distribution then either find yourself co-maintainers or drop the package. You forget upstream's part. The software (and the packages) may work well enough for enough users to justify offering them in the package collection. The next release may fix lurking bugs, because one single user has shown enough interest and effort in helping with getting a bug fixed. The user may be the Fedora packager, but it's better if more users support the software (and packages) like that. -- Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.5-301.fc19.x86_64 loadavg: 0.01 0.05 0.05 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
Le 17/06/2013 17:37, Jóhann B. Guðmundsson a écrit : No it would not. This can be solved technically and I have already explain how to do so in the past at least between two mozilla bugzilla instances and there was some bugzilla maintainer from Red Hat ( we are not running our own bugzilla instance so we cannot hack as we please but are forced to abide to what ever internal RH bugzilla admins have set that nobody in the community knows about ) looking into it but then he quit and that effort died with him as I understood it from James at that time. JBG If using Red Hat Bugzilla instance is the problem, then it's worth taking a look at having our own bugtracker. In fact, it's already been examined by our awesome infrastructure team and i personnally believe that we should help them fixing that. https://fedoraproject.org/wiki/Infrastructure_Fedora_bug_tracker Best regards, H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
Is the source code of the Red Hat Bugzilla instance published somewhere? A quick search didn't turn it up. Eric On Mon, Jun 17, 2013 at 11:45 AM, Eric Smith space...@gmail.com wrote: Is the source code of the Red Hat Bugzilla instance published somewhere? A quick search didn't turn it up. Eric On Mon, Jun 17, 2013 at 11:19 AM, Haïkel Guémar karlthe...@gmail.com wrote: Le 17/06/2013 17:37, Jóhann B. Guðmundsson a écrit : No it would not. This can be solved technically and I have already explain how to do so in the past at least between two mozilla bugzilla instances and there was some bugzilla maintainer from Red Hat ( we are not running our own bugzilla instance so we cannot hack as we please but are forced to abide to what ever internal RH bugzilla admins have set that nobody in the community knows about ) looking into it but then he quit and that effort died with him as I understood it from James at that time. JBG If using Red Hat Bugzilla instance is the problem, then it's worth taking a look at having our own bugtracker. In fact, it's already been examined by our awesome infrastructure team and i personnally believe that we should help them fixing that. https://fedoraproject.org/wiki/Infrastructure_Fedora_bug_tracker Best regards, H. -- 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
Re: icedtea-web installed and enabled by default in Fedora 19
On 06/17/2013 10:03 AM, Bill Nottingham wrote: The one issue I can see with removing it is that the plugin finder you then get in Firefox if you hit a Java site doesn't work to actually get you the Fedora version. The one issue I see is that it's darn near impossible to find the package if you don't already know its name. -- Ian Pilcher arequip...@gmail.com Sometimes there's nothing left to do but crash and burn...or die trying. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
On Jun 17, 2013 9:04 AM, Jóhann B. Guðmundsson wrote: On 06/17/2013 01:00 PM, Orcan Ogetbil wrote: On Mon, Jun 17, 2013 at 4:52 AM, Florian Weimer wrote: I would like to avoid creating accounts in gazillion upstream bug trackers, Aha! Should the package maintainers play the middle man in the gazillion upstream bug tracker accounts? This sounds neither very thoughtful nor quite efficient. It's your responsibility as an maintainer in the distribution to be in contact with upstream, subscribed to their mailing lists, have an account in their upstream tracker and participate in their upstream community so yes that comes with the territory of being a responsible maintainer in the distribution.. The emphasis of my sentence was playing the middle man, rather than gazillion upstream trackers. Sorry for not being clear. As a package maintainer, being the medium to transfer messages back and forth between upstream and the user is an extremely inefficient way to get things done. We are package maintainers, not email clients or web browsers. Please don't be so cruel to us :) Orcan (Attempting to send this from android, I hope I did the formatting right.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd-itk broken over release because httpd updated without dependencies caring and maintainer refuse fixing
Thank you. I have done it - https://fedorahosted.org/fesco/ticket/1125. 16.06.2013 18:55, Kalev Lember wrote: 2013-06-16 16:47, Pavel Alexeev skrev: [snip] So, is there any chance to force apply these patches (as provenpackager I can do it itself)? Or I only may wait next apache release or apply again such ugly hacks with sources? Disclaimer: I am not familiar with the issue at hand, and I'm not taking any sides here. The general policy is that provenpackagers do not override primary maintainers. As a provenpackager, I would never commit something to apache knowing that its maintainer doesn't want it. The body that oversees package maintainers is FESCo. File a ticket with the FESCo trac if there are unsolvable issues between maintainers. https://fedorahosted.org/fesco/ Hope this helps, Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
On 06/17/2013 05:19 PM, Haïkel Guémar wrote: If using Red Hat Bugzilla instance is the problem, then it's worth taking a look at having our own bugtracker. In fact, it's already been examined by our awesome infrastructure team and i personnally believe that we should help them fixing that. https://fedoraproject.org/wiki/Infrastructure_Fedora_bug_tracker If we move we should remove epel since it's RHEL specific ( it belongs in RH Bugzilla ) well any arguments containing RHEL are moot Fedora != RHEL The argument could be made we should use that instance instead of all tracker instances on fedora hosted and I would recommend we stick with mozilla ( since many upstream use it ) and or apply for [1] and move to atlassian jira maybe since we have a strong java team. 1. http://www.atlassian.com/software/views/open-source-license-request -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
On 06/05/2013 03:37 PM, Stef Walter wrote: What does work, and has been tested is logging in as root and simply typing this: realm join mydomain.com I filed https://bugzilla.redhat.com/show_bug.cgi?id=975182 because of confusing error messages when there is no pre-existing AD computer acct: realm join --user=przemek mydomain ... Password for przemek: ... Enter przemek's password: Failed to join domain: User specified does not have administrator privileges ! Insufficient permissions to join the domain mydomain realm: Couldn't join realm: Insufficient permissions to join the domain The error message is incorrect---I do have the required privileges: the real reason is that at this point the domain has to have a computer account created for this computer, and it didn't. If I create the computer account in Windows AD and retry, the operation succeeds: realm join --user=przemek mydomain ... Password for przemek: ... Enter przemek's password: DNS update failed: NT_STATUS_UNSUCCESSFUL Using short domain name -- MYDOMAIN Joined 'myhost' to dns domain 'mydomain' DNS Update for myhost failed: ERROR_DNS_GSS_ERROR * LANG=C LOGNAME=root /usr/bin/net -s /var/cache/realmd/realmd-smb-conf.3WTOYW -U przemek ads keytab create Enter przemek's password: * /usr/bin/systemctl enable sssd.service ln -s '/usr/lib/systemd/system/sssd.service' '/etc/systemd/system/multi-user.target.wants/sssd.service' * /usr/bin/systemctl restart sssd.service * /usr/bin/sh -c /usr/sbin/authconfig --update --enablesssd --enablesssdauth --enablemkhomedir --nostart /usr/bin/systemctl enable oddjobd.service * Successfully enrolled machine in realm -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
On 17.06.2013 20:44, Przemek Klosowski wrote: On 06/05/2013 03:37 PM, Stef Walter wrote: What does work, and has been tested is logging in as root and simply typing this: realm join mydomain.com I filed https://bugzilla.redhat.com/show_bug.cgi?id=975182 because of confusing error messages when there is no pre-existing AD computer acct: Thanks for the bug. But I think this is a WONTFIX (or can't fix). Details in the bug. Please correct me if I've missed something. Cheers, Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
EPEL Fedora 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 609 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2011-4701/supybot-gribble-0.83.4.1-10.el6 421 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6 79 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-0823/openstack-keystone-2012.2.3-5.el6 17 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-6024/rubygem-passenger-3.0.21-1.el6 17 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-6034/heat-jeos-9-1.el6 12 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-6079/gallery3-3.0.8-1.el6 11 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-6090/ssmtp-2.61-20.el6 9 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-10387/owncloud-4.5.12-1.el6 9 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-10392/perl-Module-Signature-0.73-1.el6 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-10418/python-feedparser-5.1.2-2.el6 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-10445/fail2ban-0.8.10-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing dvisvgm-1.3-1.el6 icoutils-0.31.0-2.el6 iperf3-3.0-0.4.b5.el6 perl-Locale-Maketext-Gettext-1.27-12.el6 perl-String-Similarity-1.04-8.el6 perl-qpid-0.22-1.el6 php-pecl-redis-2.2.3-1.el6 pysnmp-4.2.4-1.el6 python-grokmirror-0.3.4-1.el6 python-qpid-0.22-1.el6 youtube-dl-2013.05.23-1.el6 Details about builds: dvisvgm-1.3-1.el6 (FEDORA-EPEL-2013-10495) DVI to SVG converter Update Information: This is a small feature release with the following changes: * Basic evaluation of hyperref specials has been added. dvisvgm does not support internal links to locations on different pages yet. * The new command-line option --linkmark can be used to select the way how to mark hyperlinked areas. * The handling of TFM files has been improved. Especially, malformed files are handled more reliably now. * Support for Japanese Font Metric (JFM) files has been added. For further information see http://dvisvgm.sourceforge.net ChangeLog: * Mon Jun 17 2013 Martin Gieseking martin.giesek...@uos.de 1.3-1 - Updated to release 1.3. - Removed the stuff releated to the formerly bundled potrace library. It's no longer present in the tarball. icoutils-0.31.0-2.el6 (FEDORA-EPEL-2013-10494) Utility for extracting and converting Microsoft icon and cursor files Update Information: This is a small bugfix release which fixes some build issues. Also, the manpages have been improved. ChangeLog: * Mon Jun 17 2013 Martin Gieseking martin.giesek...@uos.de 0.31.0-2 - Dropped BuildRequires: perl-Carp * Mon Jun 17 2013 Martin Gieseking martin.giesek...@uos.de 0.31.0-1 - Updated to version 0.31.0. - Dropped patches as they have been applied upstream. * Thu May 16 2013 Richard W.M. Jones rjo...@redhat.com 0.30.0-3 - Documentation fixes (RHBZ#948882). * Sat Mar 23 2013 Martin Gieseking martin.giesek...@uos.de 0.30.0-2 - Rebuilt with recent autoconf for https://bugzilla.redhat.com/show_bug.cgi?id=925575 iperf3-3.0-0.4.b5.el6 (FEDORA-EPEL-2013-10493) Measurement tool for TCP/UDP bandwidth performance Update Information: latest beta from upstream ChangeLog: * Sat May 4 2013 Kevin Fenzi ke...@scrye.com 3.0-0.4.b5 - Update to 3.0b5 * Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 3.0-0.3.b4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild References: [ 1 ] Bug #958469 - iperf3-3.0b5 is available https://bugzilla.redhat.com/show_bug.cgi?id=958469 perl-Locale-Maketext-Gettext-1.27-12.el6 (FEDORA-EPEL-2013-10488) Joins the gettext and Maketext frameworks Update Information:
EPEL Fedora 5 updates-testing report
The following Fedora EPEL 5 Security updates need testing: Age URL 421 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5 316 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-6608/Django-1.1.4-2.el5 12 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-6086/libguestfs-1.20.8-1.el5 11 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-6089/ssmtp-2.61-20.el5 9 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-10388/perl-Module-Signature-0.73-1.el5 9 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-10389/rrdtool-1.2.27-4.el5 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-10450/clamav-0.97.8-1.el5 The following builds have been pushed to Fedora EPEL 5 updates-testing iperf3-3.0-0.4.b5.el5 python-qpid-0.22-1.el5 Details about builds: iperf3-3.0-0.4.b5.el5 (FEDORA-EPEL-2013-10490) Measurement tool for TCP/UDP bandwidth performance Update Information: latest beta from upstream ChangeLog: * Sat May 4 2013 Kevin Fenzi ke...@scrye.com 3.0-0.4.b5 - Update to 3.0b5 * Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 3.0-0.3.b4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild References: [ 1 ] Bug #958469 - iperf3-3.0b5 is available https://bugzilla.redhat.com/show_bug.cgi?id=958469 python-qpid-0.22-1.el5 (FEDORA-EPEL-2013-10496) Python client library for AMQP Update Information: First build of python-qpid for EL5. ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)
On Mon, Jun 17, 2013 at 8:57 AM, Alec Leamas leamas.a...@gmail.com wrote: Isn't the proper solution then to patch the config files to get rid of the obsolete macros? Such patches should certainly be acceptable upstream. If I have some other reason for needing to touch the configure script, then sure. (In fact, I have done just that with several projects. See what I've had to do to the gcl configure script, for example.) If not, I'd rather not spend the small amount of time I can devote to open source software work messing with a configure script just because somebody thinks they should be able to run autoreconf with a newer version of the autotools and get away with it. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
On Mon, 17 Jun 2013 11:46:13 -0600 Eric Smith brouh...@fedoraproject.org wrote: Is the source code of the Red Hat Bugzilla instance published somewhere? A quick search didn't turn it up. It's very close to upstream bugzilla 4.4 at this point I think. I don't know of a public repo of the exact source. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
On Mon, 17 Jun 2013 18:29:11 + Jóhann B. Guðmundsson johan...@gmail.com wrote: On 06/17/2013 05:19 PM, Haïkel Guémar wrote: If using Red Hat Bugzilla instance is the problem, then it's worth taking a look at having our own bugtracker. In fact, it's already been examined by our awesome infrastructure team and i personnally believe that we should help them fixing that. https://fedoraproject.org/wiki/Infrastructure_Fedora_bug_tracker If we move we should remove epel since it's RHEL specific ( it belongs in RH Bugzilla ) well any arguments containing RHEL are moot Fedora != RHEL I don't follow your logic there, but yes we would have to determine what we want to do with epel bugs if we moved anything. The argument could be made we should use that instance instead of all tracker instances on fedora hosted and I would recommend we stick with mozilla ( since many upstream use it ) and or apply for [1] and move to atlassian jira maybe since we have a strong java team. No go. http://fedoraproject.org/wiki/Infrastructure_Licensing I'd like to note that we were/are just exploring this idea, there's nothing decided or set in stone. If you have constructive, concrete things to consider, please do add them to the wiki page. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: icedtea-web installed and enabled by default in Fedora 19
On Mon, Jun 17, 2013 at 8:25 AM, Mateusz Marzantowicz mmarzantow...@osdf.com.pl wrote: On 17.06.2013 17:18, Heiko Adams wrote: From my point of view the java-plugin is a big security hole and should be kicked from default installations ASAP. Then, why not fix it? Mateusz Marzantowicz There is no way in hell anyone here is going to fix the security holes in Java (open or closed). The only way to avoid the security holes caused by java is to not use it. That's like telling someone not to use Firefox because it has security holes. It might be worth to fix in openjdk but again, openjdk is useless to me as it is. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: icedtea-web installed and enabled by default in Fedora 19
Hi On Mon, Jun 17, 2013 at 3:26 PM, Dan Mashal wrote: There is no way in hell anyone here is going to fix the security holes in Java (open or closed). The only way to avoid the security holes caused by java is to not use it. That is too extreme. It is certainly possible to fix security issues in IcedTea and OpenJDK. Otherwise Fedora wouldn't be including it in the distribution and building a lot of packages using openJDK. If we don't include IcedTea by default and there are future security issues, it still needs to be fixed but the chances of it affecting users are reduced however we might be creating problems for users who are relying on IcedTea-Web to do their banking or other critical tasks and IcedTea-Web is not easily installable via the Firefox plugin search and it is a entirely un-obvious name for users to install using the package manager. Not a lot of people understand that Java applet source was never open sourced by Sun or Oracle and is not part of the OpenJDK project. If we can fix Firefox to install IcedTea on demand, that would be great. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
On Mon, 17 Jun 2013 11:46:13 -0600 Eric Smith brouh...@fedoraproject.org wrote: Is the source code of the Red Hat Bugzilla instance published somewhere? A quick search didn't turn it up. On Mon, Jun 17, 2013 at 1:18 PM, Kevin Fenzi ke...@scrye.com wrote: It's very close to upstream bugzilla 4.4 at this point I think. Thanks! It seems quite a bit different than other Bugzillas I use, but they're all significantly older versions, so I'll try 4.4. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: icedtea-web installed and enabled by default in Fedora 19
* Rahul Sundaram methe...@gmail.com [2013-06-17 15:42]: Hi On Mon, Jun 17, 2013 at 3:26 PM, Dan Mashal wrote: There is no way in hell anyone here is going to fix the security holes in Java (open or closed). The only way to avoid the security holes caused by java is to not use it. That is too extreme. It is certainly possible to fix security issues in IcedTea and OpenJDK. Otherwise Fedora wouldn't be including it in the distribution and building a lot of packages using openJDK. If we don't include IcedTea by default and there are future security issues, it still needs to be fixed but the chances of it affecting users are reduced however we might be creating problems for users who are relying on IcedTea-Web to do their banking or other critical tasks and IcedTea-Web is not easily installable via the Firefox plugin search and it is a entirely un-obvious name for users to install using the package manager. Not a lot of people understand that Java applet source was never open sourced by Sun or Oracle and is not part of the OpenJDK project. If we can fix Firefox to install IcedTea on demand, that would be great. +1 to fixing Firefox if we must stop it from being installed by default. As archaic as applets may be, they are still used in critical applications such as for banking/trading/etc. and I think it should always be possible for users to easily find it/install it if it is not already done by default. FWIW, Oracle has been taking JVM security very seriously lately -- we do security releases on OpenJDK in Fedora and over the past few months, we have seen a significant rise (past avg*3+) in the number of issues fixed and also a significant rise in code hardening. Cheers, Deepak Rahul -- 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
Re: bugzilla.redhat.com vs upstream bug trackers
OK, so this post is going to be rather long and rambling, and hopefully respectful, but I'm passionate about this subject (and Fedora). The tl;dr summary is that there shouldn't be a single standard for what we expect of packagers, especially in the context of what to expect when bugs are filed against their packages on Red Hat's bugzilla. My view is that expectations are going to depend on the criticality of the package to Fedora (kernel, installer, default desktop stack) and the packager (are they being paid to maintain the package in Fedora or are they volunteering their time). Also, where some of us seem to be at odds is the definition of proper maintenance for packages. My definition: 1) Ensure that packages meet all of the packaging guidelines. 2) Fix packaging related bugs in a timely manner. 3) Incorporate new upstream releases, in accordance with packaging guidelines (e.g. packages shouldn't be updated to a new major version in a released version of Fedora). 4) Incorporate patches that fix security issues or critical bugs. In my view these expectations imply that a packager has some involvement with upstream. I think that the level of involvement is going to depend on the packager and the package. I don't think that a hard and fast rule can be developed to cover every case without becoming ridiculously long and complex. Other than generally encouraging packagers to become involved with upstream development it should be left up to the conscience of the packager. In no way should packagers be expected to provide end-user support for packages, be an expert in every aspect of a package, or be expected to work with upstream to debug issues because the end user is unwilling to do the work themselves (in essence becoming an upstream developer themselves). OK, so with that out of a way, I'm hopefully going to respectfully (if wordily) respond to Jóhann's comments. On Mon, Jun 17, 2013 at 10:55 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 06/17/2013 03:42 PM, Jeffrey Ollie wrote: I maintain packages in Fedora because it allows me to get what I want to do done, whether at work or at home. Since I've done the work of making these packages, why not share them with the Fedora community? Because if you cannot properly maintain the component in the distribution the community is better of without it. 1) There's a 99.999% chance that I don't have the resources (either hardware or software) to reproduce the bug. Then you should not be maintaining that component In some cases you may be right. But in most cases I was the only person to step up and package a particular piece of software. Also, in most cases I'm willing to step aside as the owner of a package if someone wants to take over the responsibility. In every case I've been willing to take on co-maintainers to help out with the packaging duties. 2) There's a 100% chance that I don't have the time between work and family obligations. We do not need unresponsive or poor maintained packages in the distribution and if there is really need or demand for the component you maintain, co-maintainers will appear or people to pick it up if you drop it so if you dont have the time to properly maintain your component(s) in the distribution then either find yourself co-maintainers or drop the package. Again, our key disagreement here is on the definition of proper maintenance. I have more than enough time to keep up with new versions as they are released (most of the time) or to pull a patch out of the upstream's version control and add it to the package. But even if I had the hardware I don't have the kind of time it takes to set up test environments to reproduce a bug, and then dig into the code and find the bug, develop a fix and then test it. 3) Even though I'm an excellent programmer, well versed in C and Python, and decent in Perl, Ruby, et. al. I probably don't have the familiarity with the codebase to even know where to start looking for a bug. If you aren't familiar with the component you are packaging and maintaining why are you doing it et all? Well, let's take Asterisk. First off, there are a lot of components that require specific (and expensive) hardware like ISDN POTS adapters. And if I had the Asterisk-specific hardware I'd need ISDN or POTS lines to connect to which would mean sending lots of my money to the local telco or spending lots of money on other telephony hardware to set up a lab environment. Then you've got to worry about country-specific setups. ISDN and POTS lines work differently depending on what country you're in, and I've only had minimal experience with such lines in the US and none at all in other countries. Asterisk provides support many VoIP protocols, each with their own quirks. A number of them only talk to proprietary hardware (which I don't own). Even if you're using SIP, it's one of those protocols whose specification is fuzzy enough that every implementation
Need some advices moving a fedora package from sysVinit to systemd t
Hello, Trying to do an overdue package upgrade for a package we have in fedora and I have question regarding using systemd to do fine tuning configuration on the FIRST daemon starting. With sysVinit it was straightforward enough: At the first service start, the script was detecting the configuration process never run and begin a one shot init sequence to (mainly) create database structure and prepare an httpd config file. Restarting/starting other needed daemon (httpd, dovecot, clamd, etc..). Trying to do the same within systemd and I have small troubles. First question: Sysadmin can choose about data-base to use (postgresql or MySQL, editing the config file) and tuning configuration process will check proper data-base server is up and running then create application data-base according a configuration variable named DB_TYPE. I can use After= directive with daemon server (lets say postgresql.service) but sysadmin could decide his production server to only use MySQL. So the service After= directive should be conditional to an env variable. I have seen no provision within systemd to resolve such case... Could somebody propose a nice way to resolve such needs within systemd service file? (if this is achievable?). Second question: ExecStartPre allow me to start a shell script file (which is used to check|do the initial config sequence), it is my understanding it is not wise (almost forbidden) to start daemon within this shell script, is calling systemctl (restart, start) allowed? (basically; is systemctl calling another systemctl technically sound?). Last question: When our deamon start, there is a small delay before it set a lock-pid (the lock pid is set only when daemon know its configuration is sound and going in daemon background mode). This lock pid is not yet available within PIDFile when the process started by ExecStart exit. So systemd complain about the fact the daemon never started (which is not true, daemon is up and running). I would like to add a delay before systemd check about daemon pid. According to me [Timer] is not what I am looking for, is there a way to add a small delay between ExecStart return and PID check? systemd seems to me more on the Microsoft way of doing thing than Unix (so far, I see systemd as trying to do all and everything, instead being a small program focused on doing only one thing but extremely well). Hopefully I am wrong, (I must be too much fine tuned by using SysV since 1984 :-}). -- A bientôt === Jean-Marc PigeonE-Mail: j...@safe.ca SAFE Inc. Phone: (514) 493-4280 Clement, 'a kiss solution' to get rid of SPAM (at last) Clement' Home base http://www.clement.safe.ca; === smime.p7s Description: S/MIME Cryptographic Signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm and config.{guess,sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)
On Seg, 2013-06-17 at 11:39 +0300, Oron Peled wrote: In the Fedora spirit of everything buildable from clean sources, I think the autoreconf solution should be globally adopted (regardless of aarch64): * It doesn't use generated files as input to the build process. * It delegates the actual management to where it belongs. Agreed , I will do that on dpkg Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
On Mon, Jun 17, 2013 at 1:57 PM, Jeffrey Ollie j...@ocjtech.us wrote: In no way should packagers be expected to provide end-user support for packages, be an expert in every aspect of a package, or be expected to work with upstream to debug issues because the end user is unwilling to do the work themselves (in essence becoming an upstream developer themselves). I agree. For some of the packages I maintain, I am able to do some bug fixing myself, and forward the patches upstream. For other packages, I have done the packaging because I use the software, but I am not at all knowledgeable about the innards, and get lost quickly trying to fix any bugs. I think it's reasonable in those cases to advise that the user report the bugs upstream. If there was consensus that handling it that way was bad, and that the package maintainer had to accept more responsibility for bug fixing, then I'd be happy to hand over the package maintenance duties to another Fedora package maintainer that was willing to do that. Well, let's take Asterisk. First off, there are a lot of components That's a good example, but I think there are a lot of packages far simpler than that which are still too complicated to necessarily expect the Fedora packager to do all of the software maintenance. Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please review (additinal fix): [389 Project] #47391: deleting and adding userpassword fails to update the password
https://fedorahosted.org/389/ticket/47391 https://fedorahosted.org/389/attachment/ticket/47391/0001-Ticket-47391-deleting-and-adding-userpassword-fails-.patch Bug description: ldapmodify with changetype modify is supposed to skip checking unhashed password in acl_check_mods. delete and replace were being skipped, but not add. Fix description: add also skips to check unhashed password. -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: option to ignore flash memory device at USB1.1 full speed
On Sun, 2013-06-16 at 22:33 +0100, Matthew Garrett wrote: On Sun, Jun 16, 2013 at 10:11:42PM +0100, David Woodhouse wrote: On Sun, 2013-06-16 at 05:38 +0100, Matthew Garrett wrote: On Sat, Jun 15, 2013 at 08:24:33AM -0700, John Reiser wrote: How can I force the system not to recognize a USB2.0 flash memory device at USB1.1 speed? You can't - it's negotiated at the host controller level, the OS isn't involved. You can't force it to use USB2 mode when for some reason it's negotiated something slower. But you can *detect* that it's connected as a USB1 device and refuse to mount it, surely? And then the user will unplug it and plug it in again, until it works correctly. Yeah, I guess you could write a udev rule that detected that case and flagged it such that it didn't get automounted. IIRC, Windows pops up one of its little yellow warnings associated with a notification tray icon when this happens - the medium is mounted but you get a warning that it's running at a slow speed. That seems reasonable. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)
On 2013-06-17 21:17, Jerry James wrote: On Mon, Jun 17, 2013 at 8:57 AM, Alec Leamas leamas.a...@gmail.com wrote: Isn't the proper solution then to patch the config files to get rid of the obsolete macros? Such patches should certainly be acceptable upstream. If I have some other reason for needing to touch the configure script, then sure. (In fact, I have done just that with several projects. See what I've had to do to the gcl configure script, for example.) If not, I'd rather not spend the small amount of time I can devote to open source software work messing with a configure script just because somebody thinks they should be able to run autoreconf with a newer version of the autotools and get away with it. -- Jerry James http://www.jamezone.org/ Fair enough. Hope you did not recognize me as one of those who just thinks they should be able to run autoreconf with a newer version of the autotools and get away with it - that was not my idea. My question mark was for real. My personal feeling is that the old discussion about keeping these files and not running autoreconf vs running autoreconf doesn't have a one size fits all answer. If we ever will be able to write GL about it, we should keep both doors open. Perhaps with a recommendation about one of them being preferred, but nothing more drastic. Not perfect, simple and clean. But that's what the world is like from time to time. --alec -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F19 locale issue?
On Sun, 16 Jun 2013 22:25:50 +0200 Kalev Lember kalevlem...@gmail.com wrote: 2013-06-16 17:17, Michael Scherer skrev: In short, fix /usr/libexec/gnome-settings-daemon-localeexec to remove ', not ','. Can you give a try to gnome-settings-daemon-3.8.3-3.fc19 ? This should fix up the issue with the extra quotes. Solved. Thanks a lot! signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)
On Seg, 2013-06-17 at 08:43 -0600, Jerry James wrote:
On Mon, Jun 17, 2013 at 2:59 AM, Björn Esser bjoern.es...@gmail.com wrote:
I completely agree to this. Using `autoreconf -fi` in %build or %prep
should be mandatory in packages using autotools. This will surely avoid
lots of possible problems caused by just injecting config.{guess,sub} by
%configure.
That would only work if the autotools had perfect backwards
compatibility. They don't. I maintain multiple packages where
autoreconf -fi with modern autotools fails due to use of obsolete
macros.
What you are writing is not much common. In fact some times I had to do
the opposite, which is : run autoreconf because we have errors with
configure .
--
Sérgio M. B.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need some advices moving a fedora package from sysVinit to systemd t
On Mon, 17.06.13 16:05, Jean-Marc Pigeon (j...@safe.ca) wrote: First question: Sysadmin can choose about data-base to use (postgresql or MySQL, editing the config file) and tuning configuration process will check proper data-base server is up and running then create application data-base according a configuration variable named DB_TYPE. I can use After= directive with daemon server (lets say postgresql.service) but sysadmin could decide his production server to only use MySQL. So the service After= directive should be conditional to an env variable. I have seen no provision within systemd to resolve such case... Could somebody propose a nice way to resolve such needs within systemd service file? (if this is achievable?). You can add After= for both databases. After= orders units only if they exist, and if they don't htey have no effect. Hence simply lists all database services you support and you should be fine. Second question: ExecStartPre allow me to start a shell script file (which is used to check|do the initial config sequence), it is my understanding it is not wise (almost forbidden) to start daemon within this shell script, is calling systemctl (restart, start) allowed? (basically; is systemctl calling another systemctl technically sound?). All processes started by ExecStartPre= will be killed before ExecStart= is run. You cannot fork long-running processes from that. It's usually a bad idea to run systemctl from ExecStartPre= since that hides dependencies. With Wants= and After= you should have all you need to make these depdendencies explicit. If you have various bits you need to run in order to get your service up, it's a good idea to simply split up the logic into two unit files, and pull in one from the other and add ordering between them. This makes it unnecessary to invoke systemctl from ExecStartPre= or any other such command. Last question: When our deamon start, there is a small delay before it set a lock-pid (the lock pid is set only when daemon know its configuration is sound and going in daemon background mode). This lock pid is not yet available within PIDFile when the process started by ExecStart exit. So systemd complain about the fact the daemon never started (which is not true, daemon is up and running). Use Type=forking. That will cause systemd wait for the initial process to exit before checking for the PID file. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
On 06/17/2013 07:57 PM, Jeffrey Ollie wrote: OK, so this post is going to be rather long and rambling, and hopefully respectful, but I'm passionate about this subject (and Fedora). As am I. The tl;dr summary is that there shouldn't be a single standard for what we expect of packagers, especially in the context of what to expect when bugs are filed against their packages on Red Hat's bugzilla. I disagree and from my pov it should be. But I agree that RHEL customers somehow expect the same customer treatment RHEL provides them for bug filed agains Fedora. I filed a ticket with the board where I asked them to come up with and write a wiki page which clarified that for them ( RHEL customers ) but that ticket has been laying in that tracker for a about 2 years now without any kind of movement. ( takes them maybe half an hour for them to come up with and wikify it ) My view is that expectations are going to depend on the criticality of the package to Fedora (kernel, installer, default desktop stack) and the packager (are they being paid to maintain the package in Fedora or are they volunteering their time). It should not matter if you get paid or not for working on Fedora because in the end of the day this boils down to time and by that I mean the time you as an employee get paid to spend on maintaining your package in Fedora or the free time you have to dedicate to maintain your package Fedora however the time required to maintain the package properly in the distribution still remains the same. We should be able to provide a minimum time it takes to just package and provided minimum maintenance on a component along with calculate the average maintenance time for an existing component in the distribution, which in turn should provide both the employer and or the volunteer with the estimated time he/she needs to spend maintaining the component per day/week/month in the distribution Also, where some of us seem to be at odds is the definition of proper maintenance for packages. My definition: 1) Ensure that packages meet all of the packaging guidelines. 2) Fix packaging related bugs in a timely manner. 3) Incorporate new upstream releases, in accordance with packaging guidelines (e.g. packages shouldn't be updated to a new major version in a released version of Fedora). 4) Incorporate patches that fix security issues or critical bugs. The only difference is that I would add step number five acting as the liaison between upstream and downstream for reporters which to me is unavoidable for a packager/maintainer from my pov. In my view these expectations imply that a packager has some involvement with upstream. I think that the level of involvement is going to depend on the packager and the package. I don't think that a hard and fast rule can be developed to cover every case without becoming ridiculously long and complex. Other than generally encouraging packagers to become involved with upstream development it should be left up to the conscience of the packager. From my point of view If you are not involved with upstream ( at least subscribed to their mailing list and have a account in their upstream tracker ) you should not be maintaining package in the distribution but should instead just be maintaining it in a side repo. In no way should packagers be expected to provide end-user support for packages, be an expert in every aspect of a package, or be expected to work with upstream to debug issues because the end user is unwilling to do the work themselves (in essence becoming an upstream developer themselves). Agreed but at least they should know how to debug their own components which when I started the how to debug initiative a while back in QA revealed many of them did not even know how to do that. OK, so with that out of a way, I'm hopefully going to respectfully (if wordily) respond to Jóhann's comments. On Mon, Jun 17, 2013 at 10:55 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 06/17/2013 03:42 PM, Jeffrey Ollie wrote: I maintain packages in Fedora because it allows me to get what I want to do done, whether at work or at home. Since I've done the work of making these packages, why not share them with the Fedora community? Because if you cannot properly maintain the component in the distribution the community is better of without it. 1) There's a 99.999% chance that I don't have the resources (either hardware or software) to reproduce the bug. Then you should not be maintaining that component In some cases you may be right. But in most cases I was the only person to step up and package a particular piece of software. Also, in most cases I'm willing to step aside as the owner of a package if someone wants to take over the responsibility. In every case I've been willing to take on co-maintainers to help out with the packaging duties. So here is where I see things go wrong for many packagers they fail to understand or
Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)
On Seg, 2013-06-17 at 16:57 +0200, Alec Leamas wrote:
On 2013-06-17 16:43, Jerry James wrote:
On Mon, Jun 17, 2013 at 2:59 AM, Björn Esser bjoern.es...@gmail.com wrote:
I completely agree to this. Using `autoreconf -fi` in %build or %prep
should be mandatory in packages using autotools. This will surely avoid
lots of possible problems caused by just injecting config.{guess,sub} by
%configure.
That would only work if the autotools had perfect backwards
compatibility. They don't. I maintain multiple packages where
autoreconf -fi with modern autotools fails due to use of obsolete
macros.
--
Jerry James
http://www.jamezone.org/
Isn't the proper solution then to patch the config files to get rid of
the obsolete macros? Such patches should certainly be acceptable upstream.
That said, this and related questions have been discussed in several
threads over the years. The sad fact is that it hasn't been possible to
find an agreement how to cope with autotools and that we thus havn't
much about them in the guidelines.
What are the chances finding common ground now?
I hope so , some guidelines about this would be nice.
Thanks,
--
Sérgio M. B.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: icedtea-web installed and enabled by default in Fedora 19
On Mon, Jun 17, 2013 at 11:03:26AM -0400, Bill Nottingham wrote: The one issue I can see with removing it is that the plugin finder you then get in Firefox if you hit a Java site doesn't work to actually get you the Fedora version. Well, if we're looking at this for F20, it's probably worth figuring out whether we can integrate the Firefox plugin finder with Packagekit in some meaningful way. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)
On Monday 17 June 2013 22:58:53 Alec Leamas wrote: On 2013-06-17 21:17, Jerry James wrote: ... I'd rather not spend the small amount of time I can devote to open source software work messing with a configure script just because somebody thinks they should be able to run autoreconf with a newer version of the autotools and get away with it. Fair enough. Hope you did not recognize me as one of those who just thinks they should be able to run autoreconf with a newer version of the autotools and get away with it - that was not my idea. Actually, that was me who *hoped* we could get away with this ;-) ... If we ever will be able to write GL about it, we should keep both doors open. Perhaps with a recommendation about one of them being preferred, but nothing more drastic. Agreed. Let me be more specific: * If upstream uses a modern autotools, than autoreconf should be preferred (IMO). * If not, we should advise them to modernize (and if we can, try to help them). Because using very old autotools version isn't so different than using other very old development tools (think about compilers, support libraries, etc.). It is OK, but not the most advisable practice. Helping upstream to modernize is helping our ecosystem and helping Fedora being First. Again, all of this should be *recommendation*. Like Jerry James mentioned, it should be weighted by the package maintainer against other tasks which may be more urgent/important. -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron Without the wind, the grass does not move. Without software, hardware is useless. -- Tao of Programming -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
On 06/17/2013 04:49 PM, Jóhann B. Guðmundsson wrote: The only difference is that I would add step number five acting as the liaison between upstream and downstream for reporters which to me is unavoidable for a packager/maintainer from my pov. +1 I think that this is where a Fedora packager can add a ton of value, even without deep knowledge of the code being packaged. A lot of open source development communities are -- dare I say it -- fairly cliquish. A random end-user's bug reports or questions are often pretty much ignored. (I recognize that this isn't out of malice, BTW. Everyone is busy and we all have to do a sort of social triage to stay sane.) In many cases, the Fedora packager has built up a level of credibility with the development community that could get a bug report the attention that it deserves. -- Ian Pilcher arequip...@gmail.com Sometimes there's nothing left to do but crash and burn...or die trying. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need some advices moving a fedora package from sysVinit to systemd t
Hello Lennart, Many thank for you advices, but... Quoting Lennart Poettering mzerq...@0pointer.de: So the service After= directive should be conditional to an env variable. I have seen no provision within systemd to resolve such case... Could somebody propose a nice way to resolve such needs within systemd service file? (if this is achievable?). You can add After= for both databases. After= orders units only if they exist, and if they don't htey have no effect. Hence simply lists all database services you support and you should be fine. I just understood I need Requires= instead of After= as the application require the data-base daemon to be up and running in order to be operational. Then (to do some testing), I required spamassassin.service dovecot.service bigre.service sure enough bigre.service is unknown (as expected) and systemctl complain Failed to issue method call: Unit bigre.service failed to load: No such file or directory (as it should). Such I can't require a service the sysadmin don't want to use (lets say he want just use Posgresql but not want to start Mysqld at all and didn't bother to install it). So it will be nice to have a way to do conditional require, if not, we are asking the sysadmin to mess up with the service definition file (which is not good)... Second question: calling systemctl (restart, start) allowed? (basically; is systemctl calling another systemctl technically sound?). All processes started by ExecStartPre= will be killed before ExecStart= is run. You cannot fork long-running processes from that. It's usually a bad idea to run systemctl from ExecStartPre= since that hides dependencies. With Wants= and After= you should have all you need to make these depdendencies explicit Agreed, dependency are nicely resolved by Requires= directive, but while doing the first start config I need (at least) to restart httpd.service once a new WEB interface is automatically defined by application first start config. The only way I see is within the ExecStartPre script to issue systemctl restart httpd once the new application httpd configuration is done. if that is not a good way, how can I handle such situation within the service definition file?. If you have various bits you need to run in order to get your service up, it's a good idea to simply split up the logic into two unit files, and pull in one from the other and add ordering between them. This makes it unnecessary to invoke systemctl from ExecStartPre= or any other such command. Sorry I do not understand how this resolve the restart needed situation. What am I missing? Last question: [..] yet available within PIDFile when the process started by ExecStart exit. So systemd complain about the fact the daemon never started (which is not true, daemon is up and running). Use Type=forking. That will cause systemd wait for the initial process to exit before checking for the PID file. Was already with Type=forking, the initial process start, initiate the daemon itself, starting in background (which set-up a lock file with its own process PID) once some checking is done. Timing are such, systemctl check for pid befor lock file is in place. A timer capability of some kind, would be nice?. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- A bientôt === Jean-Marc PigeonE-Mail: j...@safe.ca SAFE Inc. Phone: (514) 493-4280 Clement, 'a kiss solution' to get rid of SPAM (at last) Clement' Home base http://www.clement.safe.ca; === smime.p7s Description: S/MIME Cryptographic Signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
* Jóhann B. Guðmundsson [17/06/2013 15:37] : This can be solved technically and I have already explain how to do so in the past at least between two mozilla bugzilla instances and there was some bugzilla maintainer from Red Hat ( we are not running our own bugzilla instance so we cannot hack as we please but are forced to abide to what ever internal RH bugzilla admins have set that nobody in the community knows about ) looking into it but then he quit and that effort died with him as I understood it from James at that time. If This refers to inter-bugzilla communication, I'ld love to have references to any efforts done to accomplish this. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Please test dracut-029-1.fc19!!
On Mon, 2013-06-17 at 11:41 +0200, Harald Hoyer wrote: https://admin.fedoraproject.org/updates/FEDORA-2013-10871/dracut-029-1.fc19 Thank you! It already got +6 karma and went to stable :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
Is it possible to add a virtual team for each package(or only some packages with a lot of bugs)? I mean, since upstream may ignore the bugs in bugzilla, we can add a maintainer team like kernel, or a sig like java, to cope with many bugs reported everyday if some programs really have so many. And this team/sig contains email address of upstream developers if they are willing to get notifications of bugs in bugzilla but don't wish to create an account. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
Is it possible to add a virtual team for each package(or some packages with a lot of bugs)? I mean, since upstream may ignore the bugs in bugzilla, we can add a maintainer team like kernel, or a sig like java, to cope with many bugs reported everyday if some programs really have so many. And this team/sig contains email address of upstream developers if they are willing to get notifications of bugs in bugzilla but don't wish to create an account. I think being a liaison is not only I wish abrt can report bugs to external bug trackers, but it's impossible. And some upstream developers may not interested in bugzilla, too. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)
On Mon, 2013-06-17 at 16:57 +0200, Alec Leamas wrote:
On 2013-06-17 16:43, Jerry James wrote:
On Mon, Jun 17, 2013 at 2:59 AM, Björn Esser bjoern.es...@gmail.com wrote:
I completely agree to this. Using `autoreconf -fi` in %build or %prep
should be mandatory in packages using autotools. This will surely avoid
lots of possible problems caused by just injecting config.{guess,sub} by
%configure.
That would only work if the autotools had perfect backwards
compatibility. They don't. I maintain multiple packages where
autoreconf -fi with modern autotools fails due to use of obsolete
macros.
Isn't the proper solution then to patch the config files to get rid of
the obsolete macros? Such patches should certainly be acceptable upstream.
Not necessarily, or at least not reasonably quickly.
Upstream might be running an older version of the Autotools on their
development machine, and not be interested in upgrading it (e.g they run
Debian Stable or RHEL).
So you'd still have to carry that patch downstream until they finally
upgrade and accept your patch, which can take years.
--
Mathieu
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Fedora 19 Final Test Compose 5 (TC5) Available Now!
NOTE: TC4 was broken (several DEs failed to appear in the DVD menu) so it was decided to not announce it and spin TC5 instead. Content information, including changes, for TC4 can be found at https://fedorahosted.org/rel-eng/ticket/5623#comment:9 . There are delta ISOs for TC3-TC4 and TC4-TC5. The 64-bit Live Desktop is over its size target of 1 GB. As per the Fedora 19 schedule [1], Fedora 19 Final Test Compose 5 (TC5) is now available for testing. Content information, including changes, can be found at https://fedorahosted.org/rel-eng/ticket/5623#comment:13 . Please see the following pages for download links (including delta ISOs) and testing instructions. Normally dl.fedoraproject.org should provide the fastest download, but download-ib01.fedoraproject.org is available as a mirror (with an approximately 1 hour lag) in case of trouble. To use it, just replace dl with download-ib01 in the download URL. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Base: https://fedoraproject.org/wiki/Test_Results:Current_Base_Test Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Ideally, all Alpha, Beta, and Final priority test cases for Installation [2], Base [3], and Desktop [4] should pass in order to meet the Final Release Criteria [5]. Help is available on #fedora-qa on irc.freenode.net [6], or on the test list [7]. Create Fedora 19 Final test composes (TC) and release candidates (RC) https://fedorahosted.org/rel-eng/ticket/5623 Current Blocker and Freeze Exception bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-19/f-19-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Installation_validation_testing [3] https://fedoraproject.org/wiki/QA:Base_validation_testing [4] https://fedoraproject.org/wiki/QA:Desktop_validation_testing [5] https://fedoraproject.org/wiki/Fedora_19_Final_Release_Criteria [6] irc://irc.freenode.net/fedora-qa [7] https://admin.fedoraproject.org/mailman/listinfo/test signature.asc Description: OpenPGP digital signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Retrospective license change heads-up: Roundcubemail changed to GPLv3+ with exceptions and GPLv3+ and GPLv2 and LGPLv2+ and CC-BY-SA and (MIT or GPLv2)
Hey, fun times! I'm not the roundcubemail maintainer, but as a user and provenpackager I more or less co-maintain it with Jon. I was just doing a 'routine' bump to 0.9.2 and noticed the license situation was rather more complex than appeared. Up to 0.9.0 our package has claimed the license to be GPLv2. This was probably never strictly true, but never mind. It was the license on most of the core code prior to version 0.8.0 beta. Upstream in fact changed the license on the core code to GPLv3+ with exceptions at version 0.8.0 beta, something Jon and I presumably missed. That's the main change here. The exception in question is the following: This file forms part of the Roundcube Webmail Software for which the following exception is added: Plugins and Skins which merely make function calls to the Roundcube Webmail Software, and for that purpose include it by reference shall not be considered modifications of the software. If you wish to use this file in another project or create a modified version that will not be part of the Roundcube Webmail Software, you may remove the exception above and use this source code under the original version of the license. Usually legal@ would have to review and approve this exception, but as we've actually been distributing the code for some time, it seems better to correct it immediately. I'm in the process of building and testing 0.9.2 with the license field corrected; if I don't hear otherwise I'll just submit it as an update as usual. If legal thinks we need to do anything drastic here, please advise: to me the exception doesn't seem like a problem in any way, it's just intended to make sure plugins and themes aren't automatically GPLv3+. Worst impact if it's invalid is that plugins and themes are actually GPLv3+, which wouldn't be a problem for us. While checking that I noticed that the overall license situation of the package is rather more complex. Several other Things are embedded in Roundcube. None of them actually happens to constitute an embedding violation, happily, but they do muddy the licensing waters. It has embedded copies of the Javascript libraries jQueryUI and tinyMCE (javascript is excepted from the embedding policy) and an old copy of the Pear library Crypt_GPG - that would be a violation, only we don't actually have a php-pear-Crypt-GPG package, so we're okay until it gets packaged. I have raised a ticket with upstream - http://trac.roundcube.net/ticket/1489182 - suggesting this should be taken out of roundcube's no-dependencies tarball; if that happens we'll have to package it ourselves and modify the roundcube package appropriately. These are variously licensed as LGPLv2 (tinymce and crypt_gpg) and MIT or GPLv2 (jqueryui). RC's plugins themselves are all licensed either GPLv2 or GPLv3+. As the 'exception' is specifically intended to apply to RC's *core code* and let plugins *not* be versioned the same way if they don't want to be, it seems odd to suggest the GPLv3+ plugins are actually under RC's GPLv3+ with exceptions license, so I'd hold them to be under pure GPLv3+, hence GPLv3+ with exceptions and GPLv3+. Finally, RC's themes are licensed CC-BY-SA, which ultimately gives the final string GPLv3+ with exceptions and GPLv3+ and GPLv2 and LGPLv2+ and CC-BY-SA and (MIT or GPLv2) in all its glory. I may well have got the details a bit wrong there, so please, corrections welcome: I'm always around on IRC to discuss the details with reference to the source tarball, which is available at http://downloads.sourceforge.net/roundcubemail/roundcubemail-0.9.2-dep.tar.gz for anyone who wants to poke at it. CCing upstream's contact email address for feedback from them, in case I misunderstood anything. Upstream, our licensing guidelines are at https://fedoraproject.org/wiki/Packaging:LicensingGuidelines and https://fedoraproject.org/wiki/Licensing:Main , for your reference. Yeesh, who'd be a webapp packager. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 968425] perl-XML-Writer-0.623 is available
https://bugzilla.redhat.com/show_bug.cgi?id=968425 --- Comment #5 from Petr Pisar ppi...@redhat.com --- I can take ownership of the perl-XML-Writer in Fedora. -- 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=O18wh3RSlra=cc_unsubscribe -- 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-CPANPLUS-Dist-Build] Do not build-require Module::Install::AutoLicense on RHEL = 7
commit 104b68fab87516e14cb6ab90154e50b56f794864
Author: Petr Písař ppi...@redhat.com
Date: Mon Jun 17 10:40:20 2013 +0200
Do not build-require Module::Install::AutoLicense on RHEL = 7
perl-CPANPLUS-Dist-Build.spec | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
---
diff --git a/perl-CPANPLUS-Dist-Build.spec b/perl-CPANPLUS-Dist-Build.spec
index a4d6f13..b23930b 100644
--- a/perl-CPANPLUS-Dist-Build.spec
+++ b/perl-CPANPLUS-Dist-Build.spec
@@ -1,6 +1,6 @@
Name: perl-CPANPLUS-Dist-Build
Version:0.70
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Module::Build extension for CPANPLUS
License:GPL+ or Artistic
Group: Development/Libraries
@@ -22,7 +22,9 @@ BuildRequires: perl(vars)
BuildRequires: perl(warnings)
%else
BuildRequires: perl(inc::Module::Install)
+%if !(0%{?rhel} = 7)
BuildRequires: perl(Module::Install::AutoLicense)
+%endif
# Module::Install::GithubMeta is optional and not usefull
%endif
BuildRequires: perl(strict)
@@ -95,6 +97,9 @@ Module::Build-based perl modules by calling CPANPLUS::Dist
methods.
# is a core module.
rm -r ./inc/*
sed -i -e '/^\/inc\//d' MANIFEST
+%if 0%{?rhel} = 7
+sed -i -e '/^auto_license\s/d' Makefile.PL
+%endif
%endif
%build
@@ -115,5 +120,8 @@ make test
%{_mandir}/man3/*
%changelog
+* Mon Jun 17 2013 Petr Pisar ppi...@redhat.com - 0.70-2
+- Do not build-require Module::Install::AutoLicense on RHEL = 7
+
* Mon Jun 10 2013 Petr Pisar ppi...@redhat.com 0.70-1
- Specfile autogenerated by cpanspec 1.78.
--
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
