openssh: no pre-release sanity check? [Re: ssh-to-rawhide hangs

[Jim Meyering]

darrell pfeifer wrote:
> Fails for me too, with the same error.

Thanks for confirming that.

I don't mean to be rude or inflammatory, but do have to wonder how such
a fundamentally-broken package was released -- even to rawhide.  In the
fedora openssh release process, isn't there some sort of sanity check
that would catch this before inflicting it on all rawhide users?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: openssh: no pre-release sanity check? [Re: ssh-to-rawhide hangs

[Frank Murphy]

On 11/09/11 09:33, Jim Meyering wrote:
> darrell pfeifer wrote:
>> Fails for me too, with the same error.
>
> Thanks for confirming that.
>
> I don't mean to be rude or inflammatory, but do have to wonder how such
> a fundamentally-broken package was released -- even to rawhide.  In the
> fedora openssh release process, isn't there some sort of sanity check
> that would catch this before inflicting it on all rawhide users?

Is not rawhide "the sanity check", even if used productively by many?


-- 
Regards,

Frank Murphy
UTF_8 Encoded
Friend of fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: openssh: no pre-release sanity check? [Re: ssh-to-rawhide hangs

[Rahul Sundaram]

On 09/11/2011 02:13 PM, Frank Murphy wrote:
> Is not rawhide "the sanity check", even if used productively by many? 

Not many and I think the branch being less fragile would certainly
help.  If I know my system will still boot and I can access the network
and my browser is enough for me to consider running Rawhide as my main
system but I don't think we can rely on any of that now. 

Rahul

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: PostgreSQL 9.1 and Lucene Core for F16

[Michał Piotrowski]

Hi,

2011/7/2 Tom Lane :
> =?ISO-8859-2?Q?Micha=B3_Piotrowski?=  writes:
>> Are there any plans to provide PostgreSQL 9.1 in Fedora 16? PostgreSQL
>> 9.1 is in beta2 now and it's scheduled for Q3 2011.
>
> If upstream releases it in time, it'll be in F16.  I would put the odds
> of that no better than 50-50, though.  I'm not going to push a new major
> PG release into F16 post-beta, and with the F16 beta change deadline
> only 2 months away, it's pretty iffy.

I see a new tag in git repo REL9_1_0 :)

F16 beta is targeted at 2011-09-27, so there is still a little time to
upgrade PostgreSQL for this release.

>
> Of course, you could always use the PGDG RPMs whenever you think 9.1 is
> stable enough for your taste.  I'm sure Devrim will be producing RPMs
> for F16 as soon as it's released.
>
>                        regards, tom lane
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>



-- 
Best regards,
Michal

http://eventhorizon.pl/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: openssh: no pre-release sanity check? [Re: ssh-to-rawhide hangs

[Jim Meyering]

Frank Murphy wrote:
> On 11/09/11 09:33, Jim Meyering wrote:
>> darrell pfeifer wrote:
>>> Fails for me too, with the same error.
>>
>> Thanks for confirming that.
>>
>> I don't mean to be rude or inflammatory, but do have to wonder how such
>> a fundamentally-broken package was released -- even to rawhide.  In the
>> fedora openssh release process, isn't there some sort of sanity check
>> that would catch this before inflicting it on all rawhide users?
>
> Is not rawhide "the sanity check", even if used productively by many?

I was thinking of something more like "make check" (that would
run a test suite), or "maintainer gives it a spin before releasing".
But maybe something about the maintainer's set-up was different
enough that those tests would all pass.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: openssh: no pre-release sanity check? [Re: ssh-to-rawhide hangs

[Jim Meyering]

Rahul Sundaram wrote:
> On 09/11/2011 02:13 PM, Frank Murphy wrote:
>> Is not rawhide "the sanity check", even if used productively by many?
>
> Not many and I think the branch being less fragile would certainly
> help.  If I know my system will still boot and I can access the network
> and my browser is enough for me to consider running Rawhide as my main
> system but I don't think we can rely on any of that now.

I run rawhide in a VM, update/reboot daily, and use it to
sanity-check most of the packages that I tend.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [coreutils: 1/2] new upstream release 8.13, drop libs subpackage, temporarily disable multibyte checks in misc/cut te

[Paul Howarth]

Hi Ondrej,

On Fri,  9 Sep 2011 12:54:21 + (UTC)
Ondrej Vasik  wrote:

> commit b5f92004485e03004e5830205af0d1873f84f482
> Author: Ondřej Vašík 
> Date:   Fri Sep 9 13:16:47 2011 +0200
> 
> new upstream release 8.13, drop libs subpackage, temporarily
> disable multibyte checks in misc/cut test

...

> -324,17 +312,20 @@ fi /bin/true /bin/uname
>  /bin/unlink
> -%_bindir/*
> -%_infodir/coreutils*
> -%_mandir/man*/*
> -%_sbindir/chroot
> +%{_bindir}/*
> +%{_infodir}/coreutils*
> +%{_libexecdir}/coreutils*
> +%{_mandir}/man*/*
> +%{_sbindir}/chroot
>  %{?!norunuser:/sbin/runuser}
>  
> -%files libs
> -%defattr(-, root, root, -)
> -%{_libdir}/coreutils
> -
>  %changelog
> +* Fri Sep 09 2011 Ondrej Vasik  - 8.13-1
> +- new upstream release 8.13
> +- temporarily disable recently added multibyte checks in
> +  misc/cut test
> +- drop coreutils-libs subpackage, no longer needed

I think the main coreutils package needs to obsolete coreutils-libs <
8.13 to prevent upgrade problems:

--> Finished Dependency Resolution
Dependency Process ending
Depsolve time: 0.163
Error: Package: coreutils-libs-8.12-7.fc17.x86_64
(@fedora-local/$releasever) Requires: coreutils = 8.12-7.fc17
   Removing: coreutils-8.12-7.fc17.x86_64
(@fedora-local/$releasever) coreutils = 8.12-7.fc17
   Updated By: coreutils-8.13-1.fc17.x86_64 (fedora-local)
   coreutils = 8.13-1.fc17
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest



Paul.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

F-16 Branched report: 20110911 changes

[Branched Report]

Compose started at Sun Sep 11 08:15:22 UTC 2011

Broken deps for x86_64
--
FlightGear-2.0.0-6.fc16.x86_64 requires libosg.so.74()(64bit)
FlightGear-2.0.0-6.fc16.x86_64 requires libosgText.so.74()(64bit)
FlightGear-2.0.0-6.fc16.x86_64 requires libOpenThreads.so.11()(64bit)
FlightGear-2.0.0-6.fc16.x86_64 requires libosgViewer.so.74()(64bit)
FlightGear-2.0.0-6.fc16.x86_64 requires libosgUtil.so.74()(64bit)
FlightGear-2.0.0-6.fc16.x86_64 requires libosgParticle.so.74()(64bit)
FlightGear-2.0.0-6.fc16.x86_64 requires libosgGA.so.74()(64bit)
FlightGear-2.0.0-6.fc16.x86_64 requires libosgDB.so.74()(64bit)
FlightGear-2.0.0-6.fc16.x86_64 requires libosgSim.so.74()(64bit)
FlightGear-2.0.0-6.fc16.x86_64 requires libosgFX.so.74()(64bit)
SimGear-2.0.0-6.fc16.i686 requires libosg.so.74
SimGear-2.0.0-6.fc16.i686 requires libOpenThreads.so.11
SimGear-2.0.0-6.fc16.i686 requires libosgParticle.so.74
SimGear-2.0.0-6.fc16.i686 requires libosgDB.so.74
SimGear-2.0.0-6.fc16.x86_64 requires libosg.so.74()(64bit)
SimGear-2.0.0-6.fc16.x86_64 requires libOpenThreads.so.11()(64bit)
SimGear-2.0.0-6.fc16.x86_64 requires libosgParticle.so.74()(64bit)
SimGear-2.0.0-6.fc16.x86_64 requires libosgDB.so.74()(64bit)
acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell)
askbot-0.7.17-1.fc16.noarch requires django-recaptcha-works
assogiate-0.2.1-5.fc15.x86_64 requires libgnomevfsmm-2.6.so.1()(64bit)
awn-extras-applets-0.4.2-0.1.bzr1523.fc16.x86_64 requires 
libgnome-menu.so.2()(64bit)
bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit)
cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(64bit)
coda-backup-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit)
coda-backup-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit)
coda-backup-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires rvm-tools
coda-server-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit)
comoonics-cdsl-py-0.2-18.noarch requires comoonics-base-py
comoonics-cluster-py-0.1-24.noarch requires comoonics-base-py
contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1
contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit)
dh-make-0.55-3.fc15.noarch requires debhelper
emacs-spice-mode-1.2.25-5.fc15.noarch requires gwave
emerillon-0.1.2-17.fc16.x86_64 requires libethos-ui-1.0.so.0()(64bit)
emerillon-0.1.2-17.fc16.x86_64 requires libethos-1.0.so.0()(64bit)
evolution-rss-0.2.90-27.20110818git.fc16.x86_64 requires 
libcamel-provider-1.2.so.28()(64bit)
evolution-rss-0.2.90-27.20110818git.fc16.x86_64 requires 
libedataserver-1.2.so.14()(64bit)
evolution-rss-0.2.90-27.20110818git.fc16.x86_64 requires 
libebook-1.2.so.11()(64bit)
evolution-rss-0.2.90-27.20110818git.fc16.x86_64 requires 
libcamel-1.2.so.28()(64bit)
exaile-0.3.2.1-1.fc16.noarch requires hal
fawkes-guis-0.4.2-4.fc16.i686 requires libgvc.so.5
fawkes-guis-0.4.2-4.fc16.i686 requires libcdt.so.4
fawkes-guis-0.4.2-4.fc16.i686 requires libgraph.so.4
fawkes-guis-0.4.2-4.fc16.x86_64 requires libgvc.so.5()(64bit)
fawkes-guis-0.4.2-4.fc16.x86_64 requires libcdt.so.4()(64bit)
fawkes-guis-0.4.2-4.fc16.x86_64 requires libgraph.so.4()(64bit)
fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires 
libboost_signals-mt.so.1.46.1()(64bit)
fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires 
libboost_thread-mt.so.1.46.1()(64bit)
fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires 
libgeos-3.2.1.so()(64bit)
fgrun-1.5.2-8.fc16.x86_64 requires libosg.so.74()(64bit)
fgrun-1.5.2-8.fc16.x86_64 requires libosgText.so.74()(64bit)
fgrun-1.5.2-8.fc16.x86_64 requires libOpenThreads.so.11()(64bit)
fgrun-1.5.2-8.fc16.x86_64 requires libosgViewer.so.74()(64bit)
fgrun-1.5.2-8.fc16.x86_64 requires libosgUtil.so.74()(64bit)
fgrun-1.5.2-8.fc16.

Re: rm --no-traverse-mount-points [Re: stop rm at same-dev bind mounts

[Thomas Moschny]

2011/9/10 Jim Meyering :
> Thanks for the example, but I don't see how that option name is
> misleading.  A "file system" is the thing you create with "mkfs".
> Even though normally there is only one mount point per file system,
> the fact that with bind mounts there can be many doesn't change
> the name of the thing occupying the underlying device: a file system.
>
> I think you want a new option, say --no-traverse-mount-points.

The term "file system" can of course have different meaning to
different people - you could also argue it means "file system type",
with unexpected results for the interpretation of "--one-file-system".
Anyway, that is nitpicking on my side; obviously it was clear what I
meant: An option to make rm walk the tree, ignoring (=not following)
mount points. Thanks for opening the ticket.

As a side note: I am not sure whether that also means it should remove
stuff normally hidden by such a mountpoint?

As long as such a "--no-traverse-mount-points" option is not available
yet for rm, I am still looking for suggestions on how to achieve the
same effect in a shell script.

-- 
Thomas Moschny 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

rawhide report: 20110911 changes

[Rawhide Report]

Compose started at Sun Sep 11 08:15:02 UTC 2011

Broken deps for x86_64
--
389-admin-1.1.23-1.fc17.i686 requires libicuuc.so.46
389-admin-1.1.23-1.fc17.i686 requires libicui18n.so.46
389-admin-1.1.23-1.fc17.i686 requires libicudata.so.46
389-admin-1.1.23-1.fc17.x86_64 requires libicuuc.so.46()(64bit)
389-admin-1.1.23-1.fc17.x86_64 requires libicui18n.so.46()(64bit)
389-admin-1.1.23-1.fc17.x86_64 requires libicudata.so.46()(64bit)
389-adminutil-1.1.14-1.fc16.i686 requires libicuuc.so.46
389-adminutil-1.1.14-1.fc16.i686 requires libicui18n.so.46
389-adminutil-1.1.14-1.fc16.i686 requires libicudata.so.46
389-adminutil-1.1.14-1.fc16.x86_64 requires libicuuc.so.46()(64bit)
389-adminutil-1.1.14-1.fc16.x86_64 requires libicui18n.so.46()(64bit)
389-adminutil-1.1.14-1.fc16.x86_64 requires libicudata.so.46()(64bit)
389-dsgw-1.1.7-1.fc16.x86_64 requires libicuuc.so.46()(64bit)
389-dsgw-1.1.7-1.fc16.x86_64 requires libicui18n.so.46()(64bit)
389-dsgw-1.1.7-1.fc16.x86_64 requires libicudata.so.46()(64bit)
R-core-2.13.1-4.fc17.i686 requires libicuuc.so.46
R-core-2.13.1-4.fc17.i686 requires libicui18n.so.46
R-core-2.13.1-4.fc17.x86_64 requires libicuuc.so.46()(64bit)
R-core-2.13.1-4.fc17.x86_64 requires libicui18n.so.46()(64bit)
acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell)
assogiate-0.2.1-5.fc15.x86_64 requires libgnomevfsmm-2.6.so.1()(64bit)
awn-extras-applets-0.4.2-0.4.bzr1537.fc17.x86_64 requires 
gnome-python2-gtkmozembed
bibletime-2.8.1-1.fc16.x86_64 requires libicuuc.so.46()(64bit)
bibletime-2.8.1-1.fc16.x86_64 requires libicui18n.so.46()(64bit)
bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit)
claws-mail-plugins-geolocation-3.7.9-9.fc17.x86_64 requires 
libchamplain-gtk-0.10.so.0()(64bit)
claws-mail-plugins-geolocation-3.7.9-9.fc17.x86_64 requires 
libchamplain-0.10.so.0()(64bit)
cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(64bit)
coda-backup-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit)
coda-backup-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit)
coda-backup-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires rvm-tools
coda-server-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit)
comoonics-cdsl-py-0.2-18.noarch requires comoonics-base-py
comoonics-cluster-py-0.1-24.noarch requires comoonics-base-py
contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1
contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit)
couchdb-1.0.3-2.fc16.x86_64 requires libicuuc.so.46()(64bit)
couchdb-1.0.3-2.fc16.x86_64 requires libicui18n.so.46()(64bit)
couchdb-1.0.3-2.fc16.x86_64 requires libicudata.so.46()(64bit)
dh-make-0.55-3.fc15.noarch requires debhelper
dwdiff-1.9-2.fc16.x86_64 requires libicuuc.so.46()(64bit)
dwdiff-1.9-2.fc16.x86_64 requires libicui18n.so.46()(64bit)
dwdiff-1.9-2.fc16.x86_64 requires libicudata.so.46()(64bit)
emacs-spice-mode-1.2.25-5.fc15.noarch requires gwave
emerillon-0.1.2-17.fc16.x86_64 requires libethos-ui-1.0.so.0()(64bit)
emerillon-0.1.2-17.fc16.x86_64 requires libethos-1.0.so.0()(64bit)
emerillon-0.1.2-17.fc16.x86_64 requires 
libchamplain-gtk-0.10.so.0()(64bit)
emerillon-0.1.2-17.fc16.x86_64 requires libchamplain-0.10.so.0()(64bit)
empathy-3.1.90.1-2.fc17.x86_64 requires libgcr-3.so.0()(64bit)
empathy-3.1.90.1-2.fc17.x86_64 requires 
libchamplain-gtk-0.10.so.0()(64bit)
empathy-3.1.90.1-2.fc17.x86_64 requires libchamplain-0.10.so.0()(64bit)
eog-plugins-3.1.2-2.fc16.x86_64 requires 
libchamplain-gtk-0.10.so.0()(64bit)
eog-plugins-3.1.2-2.fc16.x86_64 requires libchamplain-0.10.so.0()(64bit)
fawkes-core-0.4.2-4.fc16.i686 requires libopencv_video.so.2.2
fawkes-core-0.4.2-4.fc16.i686 requires libopencv_objdetect.so.2.2
fawkes-core-0.4.2-4.fc16.i686 

Re: openssh: no pre-release sanity check? [Re: ssh-to-rawhide hangs

[Bruno Wolff III]

On Sun, Sep 11, 2011 at 09:43:27 +0100,
  Frank Murphy  wrote:
> On 11/09/11 09:33, Jim Meyering wrote:
> > darrell pfeifer wrote:
> >> Fails for me too, with the same error.
> >
> > Thanks for confirming that.
> >
> > I don't mean to be rude or inflammatory, but do have to wonder how such
> > a fundamentally-broken package was released -- even to rawhide.  In the
> > fedora openssh release process, isn't there some sort of sanity check
> > that would catch this before inflicting it on all rawhide users?
> 
> Is not rawhide "the sanity check", even if used productively by many?

I would have expected this to have been caught before subjecting rawhide
users to it. And I would have expected after having made it to rawhide, it
would have been fixed in a day (even if it was just removing the bad builds).
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: PostgreSQL 9.1 and Lucene Core for F16

[Bruno Wolff III]

On Sun, Sep 11, 2011 at 11:13:03 +0200,
  Michał Piotrowski  wrote:
> Hi,
> 
> 2011/7/2 Tom Lane :
> > =?ISO-8859-2?Q?Micha=B3_Piotrowski?=  writes:
> >> Are there any plans to provide PostgreSQL 9.1 in Fedora 16? PostgreSQL
> >> 9.1 is in beta2 now and it's scheduled for Q3 2011.
> >
> > If upstream releases it in time, it'll be in F16.  I would put the odds
> > of that no better than 50-50, though.  I'm not going to push a new major
> > PG release into F16 post-beta, and with the F16 beta change deadline
> > only 2 months away, it's pretty iffy.
> 
> I see a new tag in git repo REL9_1_0 :)
> 
> F16 beta is targeted at 2011-09-27, so there is still a little time to
> upgrade PostgreSQL for this release.

The beta freeze starts two weeks before that and even if it gets in the next
couple of days it is going to need testing to get positive karma before
making it to updates on time. So there is really extremely little time to
get 9.1 in in time for f16 beta.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: openssh: no pre-release sanity check? [Re: ssh-to-rawhide hangs

[Clyde E. Kunkel]

On 09/11/2011 04:33 AM, Jim Meyering wrote:
> darrell pfeifer wrote:
>> Fails for me too, with the same error.
>
> Thanks for confirming that.
>
> I don't mean to be rude or inflammatory, but do have to wonder how such
> a fundamentally-broken package was released -- even to rawhide.  In the
> fedora openssh release process, isn't there some sort of sanity check
> that would catch this before inflicting it on all rawhide users?

Maybe there needs to be a classification for rawhide similar to the 
karma system for updates-testing, but limited to just a set of packages 
that should just always work (maybe openssh would be one).  For such 
packages, there should be a test validation set that the maintainer runs 
to automatically allow the package into rawhide.

I know in the past when such things have been discussed, some 
maintainers chimed in that they do have test sets that they run on their 
packages.

Doesn't have to be for all packages, just the ones that are critical or 
necessary.  Yeah, defining those will be a challenge, but then what they 
hey, makes life interesting.

-- 
Regards,
OldFart

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: PostgreSQL 9.1 and Lucene Core for F16

[Tom Lane]

Bruno Wolff III  writes:
> On Sun, Sep 11, 2011 at 11:13:03 +0200,
>   Michał Piotrowski  wrote:
>> F16 beta is targeted at 2011-09-27, so there is still a little time to
>> upgrade PostgreSQL for this release.

> The beta freeze starts two weeks before that and even if it gets in the next
> couple of days it is going to need testing to get positive karma before
> making it to updates on time. So there is really extremely little time to
> get 9.1 in in time for f16 beta.

Yeah.  I have done test packaging of 9.1rc1 already, so it's pretty much
ready to go on my end.  I would be prepared to push 9.1 into f16 on
Monday if there were enough people willing to test and up-karma it
before the freeze ... any volunteers out there?

regards, tom lane
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: PostgreSQL 9.1 and Lucene Core for F16

[Bruno Wolff III]

On Sun, Sep 11, 2011 at 11:27:53 -0400,
  Tom Lane  wrote:
> 
> Yeah.  I have done test packaging of 9.1rc1 already, so it's pretty much
> ready to go on my end.  I would be prepared to push 9.1 into f16 on
> Monday if there were enough people willing to test and up-karma it
> before the freeze ... any volunteers out there?

I'll test an in place upgrade from 9.0 to 9.1, reloading a small database
from some scripts I have, and making sure some selects used by cgi scripts
appear to work correctly. I should be able to get this done Monday evening.
(I'll pull packages from koji, so I won't need to wait for it to move to
updates-testing.)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Compiling 32bit on 64bit Fedora

[drago01]

On Wed, Sep 7, 2011 at 9:35 PM, Adam Williamson  wrote:
> On Wed, 2011-09-07 at 11:52 -0400, Nathaniel McCallum wrote:
>> "gcc -m32 -o foo foo.c" gives me:
>> /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file
>> or directory
>>
>> If I copy the gnu/stubs-32.h file from the 32bit glibc-devel package
>> into the right place and run the command above again I get:
>> /usr/bin/ld: cannot find crt1.o: No such file or directory
>> /usr/bin/ld: cannot find crti.o: No such file or directory
>> /usr/bin/ld: skipping
>> incompatible /usr/lib/gcc/x86_64-redhat-linux/4.6.1/libgcc_s.so when
>> searching for -lgcc_s
>> /usr/bin/ld: cannot find -lgcc_s
>> /usr/bin/ld: skipping incompatible /usr/lib64/libc.so when searching for
>> -lc
>> /usr/bin/ld: cannot find -lc
>> /usr/bin/ld: skipping
>> incompatible /usr/lib/gcc/x86_64-redhat-linux/4.6.1/libgcc_s.so when
>> searching for -lgcc_s
>> /usr/bin/ld: cannot find -lgcc_s
>> /usr/bin/ld: cannot find crtn.o: No such file or directory
>> collect2: ld returned 1 exit status
>>
>> Hrm...
>>
>> Am I doing something wrong? Or is this a packaging bug? I can't think of
>> any reason why I shouldn't be able to compile at least a basic C program
>> with no deps as 32bit on 64bit.
>
> it's worth noting a 'cleaner' way to do this than messing up your main
> system with 32-bit packages

Not seeing what the "mess up" is really ... (having 32bit libs/apps
does not hurt in any way ... a chroot does use even more diskpace).
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Compiling 32bit on 64bit Fedora

[Reindl Harald]

Am 11.09.2011 18:18, schrieb drago01:
>>> Am I doing something wrong? Or is this a packaging bug? I can't think of
>>> any reason why I shouldn't be able to compile at least a basic C program
>>> with no deps as 32bit on 64bit.
>>
>> it's worth noting a 'cleaner' way to do this than messing up your main
>> system with 32-bit packages
> 
> Not seeing what the "mess up" is really ... (having 32bit libs/apps
> does not hurt in any way ... a chroot does use even more diskpace)

but not as default installed

from 1000 users only 2 using any compiler and on ALL of my machines
there is no single 32bit Lib installed and has never to be installed

for compiling generally a virtual machine is recommended instead
install tons of dependencies on the work system



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: openssh: no pre-release sanity check? [Re: ssh-to-rawhide hangs

[Richard W.M. Jones]

On Sun, Sep 11, 2011 at 12:18:51PM +0200, Jim Meyering wrote:
> Frank Murphy wrote:
> > On 11/09/11 09:33, Jim Meyering wrote:
> >> darrell pfeifer wrote:
> >>> Fails for me too, with the same error.
> >>
> >> Thanks for confirming that.
> >>
> >> I don't mean to be rude or inflammatory, but do have to wonder how such
> >> a fundamentally-broken package was released -- even to rawhide.  In the
> >> fedora openssh release process, isn't there some sort of sanity check
> >> that would catch this before inflicting it on all rawhide users?
> >
> > Is not rawhide "the sanity check", even if used productively by many?
> 
> I was thinking of something more like "make check" (that would
> run a test suite), or "maintainer gives it a spin before releasing".
> But maybe something about the maintainer's set-up was different
> enough that those tests would all pass.

That seems to be what libguestfs is for.

At least, we're the first to discover many qemu/kernel bugs, because
we're the first to actually try to boot new Rawhide combinations.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: PostgreSQL 9.1 and Lucene Core for F16

[Jared K. Smith]

On Sun, Sep 11, 2011 at 11:27 AM, Tom Lane  wrote:
> Yeah.  I have done test packaging of 9.1rc1 already, so it's pretty much
> ready to go on my end.  I would be prepared to push 9.1 into f16 on
> Monday if there were enough people willing to test and up-karma it
> before the freeze ... any volunteers out there?

I'd be happy to do some testing on Monday as well.

--
Jared Smith
Fedora Project Leader
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Compiling 32bit on 64bit Fedora

[drago01]

On Sun, Sep 11, 2011 at 6:21 PM, Reindl Harald  wrote:
>
>
> Am 11.09.2011 18:18, schrieb drago01:
 Am I doing something wrong? Or is this a packaging bug? I can't think of
 any reason why I shouldn't be able to compile at least a basic C program
 with no deps as 32bit on 64bit.
>>>
>>> it's worth noting a 'cleaner' way to do this than messing up your main
>>> system with 32-bit packages
>>
>> Not seeing what the "mess up" is really ... (having 32bit libs/apps
>> does not hurt in any way ... a chroot does use even more diskpace)
>
> but not as default installed

I didn't suggest that.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Broken dependencies: pino

[Michel Alexandre Salim]

On Thu 08 Sep 2011 01:22:04 PM CEST, Rahul Sundaram wrote:
> On 09/08/2011 04:43 PM, Michel Alexandre Salim wrote:
>> Given that several changes are needed, it's probably best for one of
>> the Pino maintainers to make the update (I'd not feel comfortable
>> doing anything more than just adjusting for the libgee changes)
>
> Upstream is struck in development stage for a long time after the
> rewrite started and hasn't been responsive to any bug reports filed.  I
> am inclined to just orphan it
>
Now that libgee06 is built for Rawhide, at least the currently-built 
Pino should continue to work, though I suspect rebuilding it would fail.

Regards,

-- 
Michel Alexandre Salim

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: PostgreSQL 9.1 and Lucene Core for F16

[Michał Piotrowski]

2011/9/11 Tom Lane :
> Bruno Wolff III  writes:
>> On Sun, Sep 11, 2011 at 11:13:03 +0200,
>>   Michał Piotrowski  wrote:
>>> F16 beta is targeted at 2011-09-27, so there is still a little time to
>>> upgrade PostgreSQL for this release.
>
>> The beta freeze starts two weeks before that and even if it gets in the next
>> couple of days it is going to need testing to get positive karma before
>> making it to updates on time. So there is really extremely little time to
>> get 9.1 in in time for f16 beta.
>
> Yeah.  I have done test packaging of 9.1rc1 already, so it's pretty much
> ready to go on my end.  I would be prepared to push 9.1 into f16 on
> Monday if there were enough people willing to test and up-karma it
> before the freeze ... any volunteers out there?

I don't have F16, but I can rebuild packages and test on F15 if this
will have some test value.

>
>                        regards, tom lane
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>



-- 
Best regards,
Michal

http://eventhorizon.pl/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: PostgreSQL 9.1 and Lucene Core for F16

[Tom Lane]

=?ISO-8859-2?Q?Micha=B3_Piotrowski?=  writes:
> 2011/9/11 Tom Lane :
>> Yeah.  I have done test packaging of 9.1rc1 already, so it's pretty much
>> ready to go on my end.  I would be prepared to push 9.1 into f16 on
>> Monday if there were enough people willing to test and up-karma it
>> before the freeze ... any volunteers out there?

> I don't have F16, but I can rebuild packages and test on F15 if this
> will have some test value.

F15 is where I've been doing my own testing.  It's the F16 packages that
would need karma, though.

The database weenie in me says that trying to push 9.1.0 into F16 at
this late date is insane.  I'm willing to do it if we can get enough
testing attention, but I think it has to be honest testing in an
F16-alpha environment.

regards, tom lane
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: openssh: no pre-release sanity check? [Re: ssh-to-rawhide hangs

[Till Maas]

On Sun, Sep 11, 2011 at 10:44:35AM -0400, Clyde E. Kunkel wrote:
> On 09/11/2011 04:33 AM, Jim Meyering wrote:
> > darrell pfeifer wrote:
> >> Fails for me too, with the same error.
> >
> > Thanks for confirming that.
> >
> > I don't mean to be rude or inflammatory, but do have to wonder how such
> > a fundamentally-broken package was released -- even to rawhide.  In the
> > fedora openssh release process, isn't there some sort of sanity check
> > that would catch this before inflicting it on all rawhide users?
> 
> Maybe there needs to be a classification for rawhide similar to the 
> karma system for updates-testing, but limited to just a set of packages 
> that should just always work (maybe openssh would be one).  For such 
> packages, there should be a test validation set that the maintainer runs 
> to automatically allow the package into rawhide.

AutoQA will eventually allow to run functional tests for packages afaik.
This is imho the right place to put more effort into.

Regards
Till
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: PostgreSQL 9.1 and Lucene Core for F16

[Michał Piotrowski]

2011/9/11 Tom Lane :
> =?ISO-8859-2?Q?Micha=B3_Piotrowski?=  writes:
>> 2011/9/11 Tom Lane :
>>> Yeah.  I have done test packaging of 9.1rc1 already, so it's pretty much
>>> ready to go on my end.  I would be prepared to push 9.1 into f16 on
>>> Monday if there were enough people willing to test and up-karma it
>>> before the freeze ... any volunteers out there?
>
>> I don't have F16, but I can rebuild packages and test on F15 if this
>> will have some test value.
>
> F15 is where I've been doing my own testing.  It's the F16 packages that
> would need karma, though.

I tried to upgrade to F16 at Wednesday, but preupgrade failed
somewhere. Next week I will not be able to upgrade because my vacation
ended and I need a fully functioning system over the next few days
(I've got a large webapp deployment). So I am afraid that I will not
be useful for testing PGSQL 9.1 on F16.

>
> The database weenie in me says that trying to push 9.1.0 into F16 at
> this late date is insane.  I'm willing to do it if we can get enough
> testing attention, but I think it has to be honest testing in an
> F16-alpha environment.

If I find some time I'll try to install F16 on VM, but I do not know
whether such tests will be useful. It seems to me that best and most
valuable tests would be just do some regular work on DB.

>
>                        regards, tom lane
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>



-- 
Best regards,
Michal

http://eventhorizon.pl/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: openssh: no pre-release sanity check? [Re: ssh-to-rawhide hangs

[Kevin Kofler]

Frank Murphy wrote:
> Is not rawhide "the sanity check",

Yes.

> even if used productively by many?

That's the problem then. Rawhide is explicitly labeled as NOT being intended 
nor suitable for any sort of production use.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: openssh: no pre-release sanity check? [Re: ssh-to-rawhide hangs

[Kevin Kofler]

Clyde E. Kunkel wrote:
> Maybe there needs to be a classification for rawhide similar to the
> karma system for updates-testing, but limited to just a set of packages
> that should just always work (maybe openssh would be one).  For such
> packages, there should be a test validation set that the maintainer runs
> to automatically allow the package into rawhide.

NO! Just no!

We cannot do any useful development if we have to wait 10+ days (1 push 
delay + 7 full days + 1 (another) push delay) for any of our changes to get 
out. The push delays alone are enough of a PITA even if the 7-day delay is 
set to 0 days for Rawhide.

This karma model doesn't even work well for releases, it'd be completely 
insane for Rawhide.

We just need people to grasp that Rawhide is NOT suitable for any sort of 
production use and that it WILL break. (Not "may", "will"!) As they say: 
"Rawhide eats babies!"

If people have to run Rawhide to get the current software they need, then 
THAT is the problem we must fix (and in fact one of the major advantages of 
Fedora used to be that this was NOT the case, but recent policy changes made 
it more and more the case!). Making Rawhide suitable for production use is 
about as realistic as making nuclear fission without radioactive waste.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: openssh: no pre-release sanity check? [Re: ssh-to-rawhide hangs

[Stefan Held]

Am Montag, den 12.09.2011, 00:19 +0200 schrieb Kevin Kofler:
> NO! Just no!

+1000

> This karma model doesn't even work well for releases, it'd be completely 
> insane for Rawhide.

+1000


-- 

Stefan Held  VI has only 2 Modes:
obi unixkiste orgThe first one is for beeping all the time,
FreeNode: foo_barthe second destroys the text.
---
perl -e'map{print pack c,($|++?1:13)+ord,select$,,$,,$,,$|}split//,ESEL.$/'
---

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: openssh: no pre-release sanity check? [Re: ssh-to-rawhide hangs

[Clyde E. Kunkel]

On 09/11/2011 06:19 PM, Kevin Kofler wrote:
> Clyde E. Kunkel wrote:
>> Maybe there needs to be a classification for rawhide similar to the
>> karma system for updates-testing, but limited to just a set of packages
>> that should just always work (maybe openssh would be one).  For such
>> packages, there should be a test validation set that the maintainer runs
>> to automatically allow the package into rawhide.
>
> NO! Just no!
>
> We cannot do any useful development if we have to wait 10+ days (1 push
> delay + 7 full days + 1 (another) push delay) for any of our changes to get
> out. The push delays alone are enough of a PITA even if the 7-day delay is
> set to 0 days for Rawhide.
>
> This karma model doesn't even work well for releases, it'd be completely
> insane for Rawhide.
>
> We just need people to grasp that Rawhide is NOT suitable for any sort of
> production use and that it WILL break. (Not "may", "will"!) As they say:
> "Rawhide eats babies!"
>
> If people have to run Rawhide to get the current software they need, then
> THAT is the problem we must fix (and in fact one of the major advantages of
> Fedora used to be that this was NOT the case, but recent policy changes made
> it more and more the case!). Making Rawhide suitable for production use is
> about as realistic as making nuclear fission without radioactive waste.
>
>  Kevin Kofler
>


Didn't say like, said similar.  Don't you test your changes somehow?  Or 
do you just toss the mods over the wall and hope for the best?  I don't 
think so.  Share your test cases for those packages that should just 
work--not all packages.  Forget that the changes are for rawhide and 
forget "that Rawhide is NOT suitable for any sort of
production use and that it WILL break. (Not "may", "will"!)"  I bet 
every developer and maintainer has pride in their work and products and 
really don't want to put untested changes into any distro.

I am willing to test and test and test, but need test cases for most 
things, especially esoteric bugs that are hard to duplicate.

Just because its rawhide doesn't mean we just throw our hands up and say 
"oh its just rawhide" and ignore sound development, coding and testing 
methods and ignore good engineering principles.

-- 
Regards,
OldFart

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: openssh: no pre-release sanity check? [Re: ssh-to-rawhide hangs

[Horst H. von Brand]

Clyde E. Kunkel  wrote:
> On 09/11/2011 04:33 AM, Jim Meyering wrote:
> > darrell pfeifer wrote:
> >> Fails for me too, with the same error.
> >
> > Thanks for confirming that.
> >
> > I don't mean to be rude or inflammatory, but do have to wonder how such
> > a fundamentally-broken package was released -- even to rawhide.  In the
> > fedora openssh release process, isn't there some sort of sanity check
> > that would catch this before inflicting it on all rawhide users?

> Maybe there needs to be a classification for rawhide similar to the 
> karma system for updates-testing, but limited to just a set of packages 
> that should just always work (maybe openssh would be one).  For such 
> packages, there should be a test validation set that the maintainer runs 
> to automatically allow the package into rawhide.
> 
> I know in the past when such things have been discussed, some 
> maintainers chimed in that they do have test sets that they run on their 
> packages.

If that is so, that should count into whatever karma system is put in place.

> Doesn't have to be for all packages, just the ones that are critical or 
> necessary.  Yeah, defining those will be a challenge, but then what they 
> hey, makes life interesting.

The problem is that what is critical for me might be completely irrelevant
for you. I.e., TeXlive _has_ to work for me, if libreoffice fails to work
it can be a annoyance at worst; most users will wonder what TeXlive is and
scream bloody murder when libreoffice has hickups. On this (work) machine
the SSH server is a convenience (for logging in from the phone when away
from my desk for a fast check or such), on my "server" it is the only
convenient way to get in.

Perhaps the Critical Path packages
 need extra care
during their lifetime, not just leading up to release?  Perhaps OpenSSH
should be added (or placed in a separate "server critical" category, given
the above is mostly install/running/updating for "final users")?

BTW, I've seen several times that updating the server makes a running
instance non-responsive, but been too lazy to report it.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de InformaticaFono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 234   Fax:  +56 32 2797513
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: openssh: no pre-release sanity check? [Re: ssh-to-rawhide hangs

[Horst H. von Brand]

Kevin Kofler  wrote:
> Frank Murphy wrote:
> > Is not rawhide "the sanity check",
> 
> Yes.
> 
> > even if used productively by many?
> 
> That's the problem then. Rawhide is explicitly labeled as NOT being intended 
> nor suitable for any sort of production use.

You _need_ people to use rawhide, a as wide variety of people as possible
doing the wildest range of tasks, so as to shake out bugs early. This means
it has to be usable, at least for people with the smarts to fix broken
systems and nuts enough to use rawhide in earnest. Otherwise rawhide is
just a bag of untested packages, and thus useless.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de InformaticaFono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 234   Fax:  +56 32 2797513
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel