Re: orphaning gwibber, any takers?
On 04/01/10 21:47, Tom "spot" Callaway wrote: On 01/04/2010 04:25 PM, Ian Weller wrote: I know Gwibber is widely used by Fedora users because there are a crapton of abrt reports for it and I just can't keep up with it. :) If no one else wants it, I will take it. I'd prefer to comaintain it with someone who has more time than I do. :) I'd happily co-maintain - I use gwibber a fair amount and can probably have a stab at debugging some of the issues. Cheers Alex. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
PackageKit 0.6.0 going into rawhide
I'm about to build PackageKit 0.6.0 into rawhide, which bumps the soname. I'll take care of rebuilding gnome-packagekit and kpackagekit which is (I think) are the only users of the low level library API. The other applications using the _session_ DBus connections should continue to work as this API has not changed. If you're affected by the small _system_ DBus API change, either ping me on IRC or by mail and I'll do my best to help. For the interested, 0.6.x removed a lot of deprecated API and starts to add new features and translations again. Richard. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
formal request - package take over (libssh2)
Hello, I'd like to take over the libssh2 package according to http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers all reasonable efforts have been made to contact the maintainer: https://bugzilla.redhat.com/523796 https://bugzilla.redhat.com/539444 https://www.redhat.com/archives/fedora-devel-list/2009-December/msg00996.html Thanks in advance! Kamil -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20100105 changes
These still need upstream attention. I'll badger them but it might take a while: > cduce > ocaml-camlp5 The following should be fixed in tomorrow's report: > ocaml-ocamlnet > ocaml-json-wheel > ocaml-preludeml > ocaml-pxp > ocaml-xmlrpc-light > ocaml-reins Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
packages up for adoption
I intend to give up the following packages: fedorainfinity-backgrounds libbeagle libcroco libexif libspectre preferences-menus Any takers ? Matthias -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages up for adoption
On Tue, Jan 5, 2010 at 15:37, Matthias Clasen wrote: > I intend to give up the following packages: > > fedorainfinity-backgrounds I've been using it since Fedora 8 (never liked any other Fedora wallpaper as much as this one), so I can't let it be retired. :) I'll take it. -- Mathieu Bridon -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
qstat conflicts
Hello. Does Fedora dead? I have submit new qstat packages and filed bugs against applications which are using its [qstat] old binary name. There were several weeks when qstat update on hold due to bug #533777 Should we obsolete blocking pacakge(s)? -- With Best Regards, Andy Shevchenko -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Our static Libraries packaging guidelines once more
How much do we adhere to our Packaging Guidelines for static libraries? https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries What had started with a few Yum queries for corner-cases (see https://www.redhat.com/archives/fedora-packaging/2009-December/msg00012.html ) has continued with another remote repository checking script: [...] Target distribution: rawhide Reading repository metadata... Misnamed -devel/-static packages: db4-devel-static from db4-4.8.24-1.fc13.src.rpm elfutils-devel-static from elfutils-0.143-1.fc12.src.rpm elfutils-libelf-devel-static from elfutils-0.143-1.fc12.src.rpm libibverbs-devel-static from libibverbs-1.1.3-3.fc13.src.rpm pciutils-devel-static from pciutils-3.1.4-6.fc13.src.rpm Shared library -devel packages that provide a virtual -static package and static libraries: cdparanoia-devel from cdparanoia-10.2-6.fc13.src.rpm /usr/lib/libcdda_interface.so <=> /usr/lib/libcdda_interface.a /usr/lib/libcdda_paranoia.so <=> /usr/lib/libcdda_paranoia.a e2fsprogs-devel from e2fsprogs-1.41.9-8.fc13.src.rpm /usr/lib/libe2p.so <=> /usr/lib/libe2p.a /usr/lib/libext2fs.so <=> /usr/lib/libext2fs.a libblkid-devel from util-linux-ng-2.17-0.6.fc13.src.rpm /usr/lib/libblkid.so <=> /usr/lib/libblkid.a libcom_err-devel from e2fsprogs-1.41.9-8.fc13.src.rpm /usr/lib/libcom_err.so <=> /usr/lib/libcom_err.a libss-devel from e2fsprogs-1.41.9-8.fc13.src.rpm /usr/lib/libss.so <=> /usr/lib/libss.a libuuid-devel from util-linux-ng-2.17-0.6.fc13.src.rpm /usr/lib/libuuid.so <=> /usr/lib/libuuid.a mpich2-devel from mpich2-1.2.1-4.fc13.src.rpm /usr/lib/mpich2/lib/libfmpich.so <=> /usr/lib/mpich2/lib/libfmpich.a /usr/lib/mpich2/lib/libmpich.so <=> /usr/lib/mpich2/lib/libmpich.a /usr/lib/mpich2/lib/libmpichcxx.so <=> /usr/lib/mpich2/lib/libmpichcxx.a /usr/lib/mpich2/lib/libmpichf90.so <=> /usr/lib/mpich2/lib/libmpichf90.a Shared library -devel packages that require a -static package: Library-less -devel packages that require a -static package: grib_api-devel from grib_api-1.7.0-4.fc12.src.rpm libmimedir-devel from libmimedir-0.4-6.fc12.src.rpm osiv-devel from osiv-2.0.0-0.8.beta.fc12.src.rpm Mispackaged -static libraries: Canna-devel from Canna-3.7p3-28.fc12.src.rpm /usr/lib/libRKC.so <=> /usr/lib/libRKC.a /usr/lib/libRKC16.so <=> /usr/lib/libRKC16.a /usr/lib/libcanna.so <=> /usr/lib/libcanna.a /usr/lib/libcanna16.so <=> /usr/lib/libcanna16.a QuantLib-devel from QuantLib-0.9.7-6.fc12.src.rpm /usr/lib/libQuantLib.so <=> /usr/lib/libQuantLib.a atlas-3dnow-devel from atlas-3.8.3-12.fc13.src.rpm /usr/lib/atlas-3dnow/libatlas.so <=> /usr/lib/atlas-3dnow/libatlas.a /usr/lib/atlas-3dnow/libcblas.so <=> /usr/lib/atlas-3dnow/libcblas.a /usr/lib/atlas-3dnow/libf77blas.so <=> /usr/lib/atlas-3dnow/libf77blas.a /usr/lib/atlas-3dnow/liblapack.so <=> /usr/lib/atlas-3dnow/liblapack.a /usr/lib/atlas-3dnow/libptcblas.so <=> /usr/lib/atlas-3dnow/libptcblas.a /usr/lib/atlas-3dnow/libptf77blas.so <=> /usr/lib/atlas-3dnow/libptf77blas.a atlas-devel from atlas-3.8.3-12.fc13.src.rpm /usr/lib/atlas/libatlas.so <=> /usr/lib/atlas/libatlas.a /usr/lib/atlas/libcblas.so <=> /usr/lib/atlas/libcblas.a /usr/lib/atlas/libf77blas.so <=> /usr/lib/atlas/libf77blas.a /usr/lib/atlas/liblapack.so <=> /usr/lib/atlas/liblapack.a /usr/lib/atlas/libptcblas.so <=> /usr/lib/atlas/libptcblas.a /usr/lib/atlas/libptf77blas.so <=> /usr/lib/atlas/libptf77blas.a atlas-sse-devel from atlas-3.8.3-12.fc13.src.rpm /usr/lib/atlas-sse/libatlas.so <=> /usr/lib/atlas-sse/libatlas.a /usr/lib/atlas-sse/libcblas.so <=> /usr/lib/atlas-sse/libcblas.a /usr/lib/atlas-sse/libf77blas.so <=> /usr/lib/atlas-sse/libf77blas.a /usr/lib/atlas-sse/liblapack.so <=> /usr/lib/atlas-sse/liblapack.a /usr/lib/atlas-sse/libptcblas.so <=> /usr/lib/atlas-sse/libptcblas.a /usr/lib/atlas-sse/libptf77blas.so <=> /usr/lib/atlas-sse/libptf77blas.a atlas-sse2-devel from atlas-3.8.3-12.fc13.src.rpm /usr/lib/atlas-sse2/libatlas.so <=> /usr/lib/atlas-sse2/libatlas.a /usr/lib/atlas-sse2/libcblas.so <=> /usr/lib/atlas-sse2/libcblas.a /usr/lib/atlas-sse2/libf77blas.so <=> /usr/lib/atlas-sse2/libf77blas.a /usr/lib/atlas-sse2/liblapack.so <=> /usr/lib/atlas-sse2/liblapack.a /usr/lib/atlas-sse2/libptcblas.so <=> /usr/lib/atlas-sse2/libptcblas.a /usr/lib/atlas-sse2/libptf77blas.so <=> /usr/lib/atlas-sse2/libptf77blas.a atlas-sse3-devel from atlas-3.8.3-12.fc13.src.rpm /usr/lib/atlas-sse3/libatlas.so <=> /usr/lib/atlas-sse3/l
Re: packages up for adoption
On Tue, 2010-01-05 at 15:54 +0100, Mathieu Bridon wrote: > On Tue, Jan 5, 2010 at 15:37, Matthias Clasen wrote: > > I intend to give up the following packages: > > > > fedorainfinity-backgrounds > > I've been using it since Fedora 8 (never liked any other Fedora > wallpaper as much as this one), so I can't let it be retired. :) > > I'll take it. Thanks, I've released it now. You can pick it up at https://admin.fedoraproject.org/pkgdb/packages/name/fedorainfinity-backgrounds -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Can some provenpackager bump openvpn in EL-5
Jon Ciesla wrote: Jussi Lehtola wrote: On Wed, 2009-12-30 at 16:35 +0530, Huzaifa Sidhpurwala wrote: Jussi Lehtola wrote: Even though any proven packager could do the change, that bug does not fall in the items listed in the proven packager policy [1]. You haven't listed any problems with the current package, you're just requesting a version upgrade. The version of openvpn in EPEL is an upstream rc version. The Changelog file upstream shows a lot of bugs have been fixed and it would be nice to have it fixed in EPEL too. OK, that's starting to sound better. Version upgrades should be performed by the package maintainer. This especially holds in EPEL, which should be a slowly moving distribution. In this case the bz is around 2.5 weeks old, with absolutely no response. What is the policy to get the package updated in this case? See the nonresponsive maintainer policy at https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers Actually, FYI, I'm a provenpackager and have recently contacted the openvpn maintainer. There are quite a few open bugs, including yours, and I requested his approval to take a look at the open bugs and make changes, updates, etc, and he gave me the green light. I'll try to get to this this week. Essentially, he's not been doing much with Fedora lately due to Real Life intervening, which I can certainly understand. -J An update for F-12 is on it's way to testing. I'm using it now with no issues, but I can't test the boot bug, as the machine acting as my openvpn server isn't using NetworkManager. That said, it should work. Please test and let me know if changes need to be made. -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit 0.6.0 going into rawhide
Am Dienstag, den 05.01.2010, 10:33 + schrieb Richard Hughes: > I'm about to build PackageKit 0.6.0 into rawhide, which bumps the > soname. I'll take care of rebuilding gnome-packagekit and kpackagekit > which is (I think) are the only users of the low level library API. Plus moblin-app-installer, currently under review at https://bugzilla.redhat.com/show_bug.cgi?id=546301 Regards, Christoph -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages up for adoption
Matthias Clasen wrote: > I intend to give up the following packages: > libspectre I can help out here. -- Rex -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages up for adoption
Matthias Clasen wrote: > I intend to give up the following packages: [snip] FYI: > libexif This is used by a lot of stuff, including kdegraphics (but also WINE and several GNOME packages). > libspectre This one is used by Okular (kdegraphics) and Evince. I guess one of us KDE SIG folks might pick these up if nobody else wants them. I'm hereby forwarding this to the fedora-kde ML. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages up for adoption
2010/1/5 Matthias Clasen : > I intend to give up the following packages: > > libexif I will take this one. -- LG Thomas Dubium sapientiae initium -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages up for adoption
2010/1/5 Kevin Kofler : > Matthias Clasen wrote: >> I intend to give up the following packages: > [snip] > > FYI: > >> libexif > > This is used by a lot of stuff, including kdegraphics (but also WINE and > several GNOME packages). > >> libspectre Ok, i will take that one as well. -- LG Thomas Dubium sapientiae initium -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Looking for pointers how to set up lzma stream using xz-devel
On Mon, Jan 04, 2010 at 13:37:17 -0800, John Reiser wrote: > On 01/04/2010 10:18 AM, Bruno Wolff III wrote: > >On Mon, Jan 04, 2010 at 07:57:54 -0600, > > Jon Ciesla wrote: > >>I've actually come across this WRT UPX as well. > >> > >>https://bugzilla.redhat.com/show_bug.cgi?id=501636 > > >It seemed odd that the debian bug for this claimed that source from the SDK > >was needed. Presumably an appropriate library would work. ... > > https://bugzilla.redhat.com/show_bug.cgi?id=501636#c6 > UPX cannot use a library, UPX must use source. UPX requires total control > during decompression (no malloc() allowed, etc.) and so far the library > writers have not catered to such a restricted environment, AFAICT. The alloc function in the LZMA SDK allows you to pass it a pointer to your own allocater function. (I don't know whether or not the xz library works like that.) Would that be enough for UPX? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Our static Libraries packaging guidelines once more
Michael Schwendt writes: > How much do we adhere to our Packaging Guidelines for static libraries? > > https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries > Mispackaged -static libraries: > mysql-devel from mysql-5.1.42-2.fc13.src.rpm > postgresql-devel from postgresql-8.4.2-1.fc13.src.rpm As far as these two go, I think it's just a matter of the specfiles dating from years before we had any such guideline, and not revisiting the point since then. I don't have any particular objection to removing the static versions of their libraries. On the other hand, with the guideline being so widely ignored, I'm not in a hurry to do work to comply with it ... regards, tom lane -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages up for adoption
On Tue, 2010-01-05 at 09:46 -0600, Rex Dieter wrote: > Matthias Clasen wrote: > > > I intend to give up the following packages: > > libspectre > > I can help out here. > Already sold to Marek, but I'm sure he'll welcome you as a comaintainer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: formal request - package take over (libssh2)
On Tue, Jan 5, 2010 at 3:49 AM, Kamil Dudka wrote: > Hello, > > I'd like to take over the libssh2 package according to > http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers > > all reasonable efforts have been made to contact the maintainer: > > https://bugzilla.redhat.com/523796 > https://bugzilla.redhat.com/539444 > https://www.redhat.com/archives/fedora-devel-list/2009-December/msg00996.html > > Thanks in advance! Well, it's post-holiday season now and I'm starting to catch up on my mail/bugs... These should be taken care of this week. Feel free to ping me via email/bugzilla if you need anything before then. -Chris -- Chris Weyl Ex astris, scientia -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Our static Libraries packaging guidelines once more
On Tue, 2010-01-05 at 11:03 -0500, Tom Lane wrote: > On the other hand, with the > guideline being so widely ignored, I'm not in a hurry to do work to > comply with it ... Isn't that a chicken/egg problem? -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Heads-up: %define vs %global in specs
For the impatient:
Starting with today's rawhide, the these kind of constructs in specs
no longer "work":
%{?!foo: %define foo bar}
For the generally desired effect, the above simply becomes:
%{?!foo: %global foo bar}
This is already recommended by the Fedora guidelines, but packages which
haven't been updated to follow the guideline might need revising:
https://fedoraproject.org/wiki/Packaging/Guidelines#.25global_preferred_over_.25define
The longer version:
As explained in the guidelines, %define nested in %{ } block was never
supposed to work, but due to a longstanding bug in rpm macro engine it has
seemed to work in many cases... until you do something completely
unrelated in the spec and it suddenly breaks in mysterious ways. Consider
this example spec:
--- snip ---
%{!?foo: %define foo bar}
%define dofoo() true
Name: macroscope
Version: 1.0
Release: 1
License: Testing
Summary: Testing macro behavior
%description
%{summary}
%prep
echo 1: %{foo}
%dofoo
echo 2: %{foo}
%files
%defattr(-,root,root)
--- snip ---
You'd probably expect %{foo} to expand to "bar" in both 1 and 2, but due
to this funny little macro buglet, you'd get this rather non-obvious
result:
1: bar
2: %{foo}
What you start getting now is:
1: %{foo}
2: %{foo}
...in other words, the %define inside %{} block goes out of scope when the
block ends, and you probably wanted to use %global there instead.
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages up for adoption
Kevin Kofler wrote: > Matthias Clasen wrote: >> I intend to give up the following packages: > [snip] > > FYI: > >> libexif > > This is used by a lot of stuff, including kdegraphics (but also WINE and > several GNOME packages). indeed, I missed that, can jump on that one too. -- Rex -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Our static Libraries packaging guidelines once more
On 01/05/2010 11:30 AM, Jesse Keating wrote: > On Tue, 2010-01-05 at 11:03 -0500, Tom Lane wrote: >> On the other hand, with the >> guideline being so widely ignored, I'm not in a hurry to do work to >> comply with it ... > > Isn't that a chicken/egg problem? It really is. I mean, we could create the "Packaging Police" to run around and enforce the guidelines by force (either by fixing them manually, or by threatening maintainers until they do it), but is that really what we want? ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads-up: %define vs %global in specs
On Tue, Jan 05, 2010 at 06:34:12PM +0200, Panu Matilainen wrote:
>
> For the impatient:
>
> Starting with today's rawhide, the these kind of constructs in specs
> no longer "work":
> %{?!foo: %define foo bar}
> For the generally desired effect, the above simply becomes:
> %{?!foo: %global foo bar}
>
> This is already recommended by the Fedora guidelines, but packages which
> haven't been updated to follow the guideline might need revising:
> https://fedoraproject.org/wiki/Packaging/Guidelines#.25global_preferred_over_.25define
What exactly do you mean 'no longer work' ? Can we expect to get a formal
RPM build error for this bogus construct, or will it silently build and
do the wrong thing ? From your long description, it sounds like the latter,
which means maintainers should audit their spec files to identify these
bogus macros
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Our static Libraries packaging guidelines once more
On Tue, Jan 05, 2010 at 11:48:47AM -0500, Tom spot Callaway wrote: > On 01/05/2010 11:30 AM, Jesse Keating wrote: > > On Tue, 2010-01-05 at 11:03 -0500, Tom Lane wrote: > >> On the other hand, with the > >> guideline being so widely ignored, I'm not in a hurry to do work to > >> comply with it ... > > > > Isn't that a chicken/egg problem? > > It really is. I mean, we could create the "Packaging Police" to run > around and enforce the guidelines by force (either by fixing them > manually, or by threatening maintainers until they do it), but is that > really what we want? Not for all packaging policies, but for some I think that would be a good idea. Pick a set of policies we think are particularly important to enforce & can be automatically checked, and declare any non-compliant ones will be dropped in the next fedora release unless fixed. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Our static Libraries packaging guidelines once more
Tom "spot" Callaway wrote: On 01/05/2010 11:30 AM, Jesse Keating wrote: On Tue, 2010-01-05 at 11:03 -0500, Tom Lane wrote: On the other hand, with the guideline being so widely ignored, I'm not in a hurry to do work to comply with it ... Isn't that a chicken/egg problem? It really is. I mean, we could create the "Packaging Police" to run around and enforce the guidelines by force (either by fixing them manually, or by threatening maintainers until they do it), but is that really what we want? ~spot No. Too bad though, I had visions of spiffy new uniforms. That aside, I'd love to have all packages in total Guidlines compliance. I'd also love to be rich. And thinner. -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads-up: %define vs %global in specs
On 01/05/2010 11:50 AM, Daniel P. Berrange wrote: > What exactly do you mean 'no longer work' ? Can we expect to get a formal > RPM build error for this bogus construct, or will it silently build and > do the wrong thing ? From your long description, it sounds like the latter, > which means maintainers should audit their spec files to identify these > bogus macros The easy way to be sure you're not hitting this is to not use %define. Sed will fix your packages up quickly. ;) ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Our static Libraries packaging guidelines once more
On Tue, Jan 05, 2010 at 12:16:13PM -0500, Tom spot Callaway wrote: > On 01/05/2010 12:08 PM, Daniel P. Berrange wrote: > > Not for all packaging policies, but for some I think that would be a > > good idea. Pick a set of policies we think are particularly important > > to enforce & can be automatically checked, and declare any non-compliant > > ones will be dropped in the next fedora release unless fixed. > > Well, I think a reasonable alternative would be to add those policies to > the AutoQA infrastructure, and if the package fails the check, it > doesn't get tagged and the packager gets an email explaining the > failure. That will get things fixed up. ;) That sounds good as long as AutoQA is reliable, not generating false positives. I'd still also suggest that we have a rule drop all packages reported by the FTBFS tests which aren't fixed by time of Beta. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Our static Libraries packaging guidelines once more
"Tom \"spot\" Callaway" writes: > On 01/05/2010 11:30 AM, Jesse Keating wrote: >> On Tue, 2010-01-05 at 11:03 -0500, Tom Lane wrote: >>> On the other hand, with the >>> guideline being so widely ignored, I'm not in a hurry to do work to >>> comply with it ... >> >> Isn't that a chicken/egg problem? > It really is. Well, fwiw, I have to fix the same two spec files for the %define problem, so I'm going to take care of this today while it's fresh in mind. But there's a general issue that new things keep getting added to the packaging guidelines and there's no very good mechanism to detect whether existing packages ever get updated to comply. regards, tom lane -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20100105 changes
On Tue, Jan 05, 2010 at 02:28:28PM +, Richard W.M. Jones wrote: > These still need upstream attention. I'll badger them but it might > take a while: > > > cduce > > ocaml-camlp5 Wow, upstream fixed them just after I posted. I'll try to have these done before tomorrow's Rawhide build too. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Our static Libraries packaging guidelines once more
On 01/05/2010 12:08 PM, Daniel P. Berrange wrote: > Not for all packaging policies, but for some I think that would be a > good idea. Pick a set of policies we think are particularly important > to enforce & can be automatically checked, and declare any non-compliant > ones will be dropped in the next fedora release unless fixed. Well, I think a reasonable alternative would be to add those policies to the AutoQA infrastructure, and if the package fails the check, it doesn't get tagged and the packager gets an email explaining the failure. That will get things fixed up. ;) ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages up for adoption
On Tue, 2010-01-05 at 16:59 +0100, Thomas Janssen wrote: > 2010/1/5 Matthias Clasen : > > I intend to give up the following packages: > > > > libexif > > I will take this one. > Thanks, its yours if you take it: http://admin.fedoraproject.org/pkgdb/packages/name/libexif -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Our static Libraries packaging guidelines once more
On 01/05/2010 12:27 PM, Tom Lane wrote: > But there's a general issue that new things keep getting added > to the packaging guidelines and there's no very good mechanism to > detect whether existing packages ever get updated to comply. You're right. I'm hopeful that the items which can be checked via automation will be done via AutoQA, but for those that can't, we will still depend on packagers to be responsible. ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Our static Libraries packaging guidelines once more
On 01/05/2010 12:23 PM, Daniel P. Berrange wrote: > On Tue, Jan 05, 2010 at 12:16:13PM -0500, Tom spot Callaway wrote: >> On 01/05/2010 12:08 PM, Daniel P. Berrange wrote: >>> Not for all packaging policies, but for some I think that would be a >>> good idea. Pick a set of policies we think are particularly important >>> to enforce & can be automatically checked, and declare any non-compliant >>> ones will be dropped in the next fedora release unless fixed. >> >> Well, I think a reasonable alternative would be to add those policies to >> the AutoQA infrastructure, and if the package fails the check, it >> doesn't get tagged and the packager gets an email explaining the >> failure. That will get things fixed up. ;) > > That sounds good as long as AutoQA is reliable, not generating false > positives. I'd still also suggest that we have a rule drop all > packages reported by the FTBFS tests which aren't fixed by time of > Beta. Sure, but even if it did generate a false positive, the build would still be there, just not tagged. Rel-eng could tag the package manually while fixing the test to prevent the false positive. ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Our static Libraries packaging guidelines once more
On Tue, Jan 05, 2010 at 10:38:50AM -0700, Jerry James wrote: > On Tue, Jan 5, 2010 at 10:23 AM, Daniel P. Berrange > wrote: > > That sounds good as long as AutoQA is reliable, not generating false > > positives. I'd still also suggest that we have a rule drop all > > packages reported by the FTBFS tests which aren't fixed by time of > > Beta. > > What about packages that fail to build because they depend on some > other package that is broken? I've got one in that state now. It > fails to build from source because one of its BuildRequires is broken. > There's nothing wrong with my package. Once the other guy fixes his, > mine will magically start building again. If the other guy hasn't > fixed his package by Beta, how is dropping mine going to help? It will motivate you, or someone else depending on it, to become a co-maintainer of the broken package & help with fixing it ;-P In all seriousness though, it is very bad if we're having many of cases of large sets of downstream package chains being blocked by an dependant one failing. If a security issue arises in the FTBFS package we're between a rock & a hard place, which is why I think it is worth being strict on fixing FTBFS bugs. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
UPX, lzma stream, xz-devel
The alloc function in the LZMA SDK allows you to pass it a pointer to your own allocater function. (I don't know whether or not the xz library works like that. [Ed: Yes, it does.]) Would that be enough for UPX? Maybe. Some changes would be required to UPX, on both the compression and decompression sides. Decompression is highly machine-dependent: machine-language instructions, bare stack, no libraries. Ten architectures are supported today. For decompression, current UPX [pre-]allocates all space (input, output, and temporary) because that results in smaller code size, which is important. Tens of bytes can make a difference. An allocator function also requires effectively-static storage for the 'next' pointer, which can be cumbersome depending on architecture (such as -fPIE, x86_64, ARM) and interference from SELinux (exec_mod, etc.) -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Our static Libraries packaging guidelines once more
On Tue, 2010-01-05 at 12:27 -0500, Tom Lane wrote: > "Tom \"spot\" Callaway" writes: > > On 01/05/2010 11:30 AM, Jesse Keating wrote: > >> On Tue, 2010-01-05 at 11:03 -0500, Tom Lane wrote: > >>> On the other hand, with the > >>> guideline being so widely ignored, I'm not in a hurry to do work to > >>> comply with it ... > >> > >> Isn't that a chicken/egg problem? > > > It really is. > > Well, fwiw, I have to fix the same two spec files for the %define > problem, so I'm going to take care of this today while it's fresh in > mind. But there's a general issue that new things keep getting added > to the packaging guidelines and there's no very good mechanism to > detect whether existing packages ever get updated to comply. > > regards, tom lane > In the future when we have AutoQA online we'll be able to add new tests for new guidelines and alert maintainers who's specs fall out of.. er.. spec. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Our static Libraries packaging guidelines once more
On 01/05/2010 05:48 PM, Tom "spot" Callaway wrote: On 01/05/2010 11:30 AM, Jesse Keating wrote: On Tue, 2010-01-05 at 11:03 -0500, Tom Lane wrote: On the other hand, with the guideline being so widely ignored, I'm not in a hurry to do work to comply with it ... Isn't that a chicken/egg problem? It really is. I mean, we could create the "Packaging Police" to run around and enforce the guidelines by force (either by fixing them manually, I would not want to call it a "packaging police", but a "tag team" which fixes the packages == IMO, that's the way to go. or by threatening maintainers until they do it), but is that really what we want? Yes, people have had enough time to fix their packages - It's time for action. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Should we digg PI
Hi, A news of a new calculation of PI is on the net. Should we digg (http://digg.com/d31EgvV) the article in order to promote the fact that the author used Fedora 10 for he's success ? Best regards, Adrian -- :: http://fedoraproject.ro :: http://forum.fedoraproject.ro :: -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Our static Libraries packaging guidelines once more
On Tue, Jan 5, 2010 at 10:23 AM, Daniel P. Berrange wrote: > That sounds good as long as AutoQA is reliable, not generating false > positives. I'd still also suggest that we have a rule drop all > packages reported by the FTBFS tests which aren't fixed by time of > Beta. What about packages that fail to build because they depend on some other package that is broken? I've got one in that state now. It fails to build from source because one of its BuildRequires is broken. There's nothing wrong with my package. Once the other guy fixes his, mine will magically start building again. If the other guy hasn't fixed his package by Beta, how is dropping mine going to help? -- Jerry James http://www.jamezone.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Should we digg PI
On Tue, Jan 5, 2010 at 12:22 PM, Adrian wrote: > Hi, > > A news of a new calculation of PI is on the net. Should we digg > (http://digg.com/d31EgvV) the article in order to promote the fact that the > author used Fedora 10 for he's success ? > > Best regards, > Adrian > > -- > :: http://fedoraproject.ro :: http://forum.fedoraproject.ro :: > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > A quote from the page "The Linux Operating System was used with the 64 bit Red Hat Fedora 10 distribution" ... its possible that's a "lost in translation" issue ... but it just sounds wrong to me. -Adam -- http://maxamillion.googlepages.com - () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Should we digg PI
On Tue, 2010-01-05 at 20:22 +0200, Adrian wrote: > Hi, > > A news of a new calculation of PI is on the net. Should we digg > (http://digg.com/d31EgvV) the article in order to promote the fact that > the author used Fedora 10 for he's success ? This sounds like a question about Fedora advocacy, not Fedora development. You probably want fedora-ambassadors-l...@. - ajax signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: formal request - package take over (libssh2)
On Tuesday 05 of January 2010 17:24:46 Chris Weyl wrote: > Well, it's post-holiday season now and I'm starting to catch up on my > mail/bugs... These should be taken care of this week. Feel free to > ping me via email/bugzilla if you need anything before then. Glad to see you alive! Please grant me the commit ACLs for the libssh2 Fedora packages. I've already fixed all of the above issues for RHEL and would like to sync Fedora now. Thanks in advance! Kamil -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: qstat conflicts
On Tue, 5 Jan 2010 16:57:31 +0200 Andy Shevchenko wrote: > Hello. > > Does Fedora dead? I have submit new qstat packages and filed bugs > against applications which are using its [qstat] old binary name. > There were several weeks when qstat update on hold due to bug #533777 > Should we obsolete blocking pacakge(s)? So, qstat is changing names, you filed bugs on any of the packages that are using the old name to update and they haven't yet done so? Are you waiting for them to update before pushing the new qstat? Perhaps the maintainer could use some more co-maintainers to help, or no longer wishes to maintain the package. Have you tried a direct email to them? kevin signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads-up: %define vs %global in specs
On Tue, 5 Jan 2010, Daniel P. Berrange wrote:
On Tue, Jan 05, 2010 at 06:34:12PM +0200, Panu Matilainen wrote:
For the impatient:
Starting with today's rawhide, the these kind of constructs in specs
no longer "work":
%{?!foo: %define foo bar}
For the generally desired effect, the above simply becomes:
%{?!foo: %global foo bar}
This is already recommended by the Fedora guidelines, but packages which
haven't been updated to follow the guideline might need revising:
https://fedoraproject.org/wiki/Packaging/Guidelines#.25global_preferred_over_.25define
What exactly do you mean 'no longer work' ? Can we expect to get a formal
RPM build error for this bogus construct, or will it silently build and
do the wrong thing ? From your long description, it sounds like the latter,
which means maintainers should audit their spec files to identify these
bogus macros
It depends on the details but most likely you'll get a build error of some
kind as you'll get unexpanded macros where you previously got expanded
macros (if you were lucky). For example
%{!?python_sitelib: %define python_sitelib %(python -c "from distutils.sysconfig
import get_python_lib; print get_python_lib()")}
...
%files
%{python_sitelib}/mystuff.py
...would now error out at filelist processing stage as %{python_sitelib}
is not defined in the global scope and literal
"%{python_sitelib}/mystuff.py" is not a valid file name.
Or you can get downright parse errors etc. Sure there *are* cases where it
could go unnoticed: if you're creating package content based on such a
%define - using the python_sitelib again as a dumb example, rpm wouldn't
complain about file created (and packaged) from this, you'd just get wrong
contents (unexpanded macro name) in the file:
cat << EOF >> my.conf
%{python_sitelib}/mylib/
EOF
...but the potential for such silent errors has been there all the
time: you just need to call a parametrized macro (knowingly or as a
side-effect) somewhere in the spec and poof.
Oh and btw, technically there's nothing illegal or wrong with the
construct "%{?!foo: %define foo bar}" itself. What's wrong is trying to
*use* macro defined that way outside the %{} block where it was defined.
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: formal request - package take over (libssh2)
On Tue, Jan 5, 2010 at 7:21 PM, Kamil Dudka wrote: > On Tuesday 05 of January 2010 17:24:46 Chris Weyl wrote: >> Well, it's post-holiday season now and I'm starting to catch up on my >> mail/bugs... These should be taken care of this week. Feel free to >> ping me via email/bugzilla if you need anything before then. > > Glad to see you alive! Please grant me the commit ACLs for the libssh2 Fedora > packages. I've already fixed all of the above issues for RHEL and would like > to sync Fedora now. You can request ACL permissions through the Fedora pkgdb here https://admin.fedoraproject.org/pkgdb/packages/name/libssh2 and then the maintainer can grant them Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads-up: %define vs %global in specs
On Tuesday 05 January 2010, Tom "spot" Callaway wrote: > On 01/05/2010 11:50 AM, Daniel P. Berrange wrote: > > What exactly do you mean 'no longer work' ? Can we expect to get a formal > > RPM build error for this bogus construct, or will it silently build and > > do the wrong thing ? From your long description, it sounds like the > > latter, which means maintainers should audit their spec files to identify > > these bogus macros > > The easy way to be sure you're not hitting this is to not use %define. > Sed will fix your packages up quickly. ;) Smiley noted, but blindly doing that has potential to break stuff too. Here's one example that works as intended with %define but not with %global: http://cvs.fedoraproject.org/viewvc/devel/bash-completion/bash-completion.spec?r1=1.46&r2=1.47 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Our static Libraries packaging guidelines once more
On Tue, Jan 05, 2010 at 11:48:47AM -0500, Tom spot Callaway wrote: > On 01/05/2010 11:30 AM, Jesse Keating wrote: > > On Tue, 2010-01-05 at 11:03 -0500, Tom Lane wrote: > >> On the other hand, with the > >> guideline being so widely ignored, I'm not in a hurry to do work to > >> comply with it ... > > > > Isn't that a chicken/egg problem? > > It really is. I mean, we could create the "Packaging Police" to run > around and enforce the guidelines by force (either by fixing them > manually, or by threatening maintainers until they do it), but is that > really what we want? I would skip the threatening part, but allowing provenpackagers to fix violations to the packaging guidelines after a short notice to the maintainers is something we should encourage imho. It just plain sucks if there are bugs that can be fixed easily and may cause issues, but it takes several weeks to be able to fix them oneself. Regards Till pgpRgIi5QJllp.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Our static Libraries packaging guidelines once more
On Tue, Jan 05, 2010 at 05:23:08PM +, Daniel P. Berrange wrote: > That sounds good as long as AutoQA is reliable, not generating false > positives. I'd still also suggest that we have a rule drop all > packages reported by the FTBFS tests which aren't fixed by time of > Beta. I would like to have this with a slight modificiation. If a package FTBFS for at least a certain amount of time (e.g. two weeks) at the time of Beta, then every provenpackager may just fix the bugs for another certain amount of time (e.g. another two weeks) and if nobody fixes it then it should be dropped. Or maybe we could have some kind of "neglected packages task force", that may just in general fix bugs in packages that are not fixed by the original maintainer. The advantage over becoming co-maintainer of certain packages is then, that one does not get all the noise about bugs that are already been taken care of by the original maintainer. Regards Till pgpDh71etIbdp.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: formal request - package take over (libssh2)
On Tuesday 05 of January 2010 20:55:16 Peter Robinson wrote: > You can request ACL permissions through the Fedora pkgdb here > https://admin.fedoraproject.org/pkgdb/packages/name/libssh2 and then > the maintainer can grant them You can see I already did. It was more than a month ago, still waiting for response. Thus I am asking Chris as the current maintainer for the grant again now. Kamil -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages up for adoption
On Tue, Jan 05, 2010 at 09:37:26AM -0500, Matthias Clasen wrote: > I intend to give up the following packages: > libcroco > Any takers ? I'll take this one. Dodji -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
