date:20131005

Re: Source file audit - 2013-09-30

2013-10-05 Thread Ville Skyttä

On Fri, Oct 4, 2013 at 8:29 PM, Alexey I. Froloff ra...@raorn.name wrote:
 On Fri, Oct 04, 2013 at 10:21:02AM -0600, Kevin Fenzi wrote:
  What tool were you using for download?
 spectool -g *.spec
 Which uses curl do download files...

Current one does. But the one Kevin used for this run on CentOS 5 uses wget.

 remote-header-name should be added to /etc/rpmdevtools/curlrc

That'd just break pretty much every github release download in a
slightly different way as far as this check is concerned because their
Content-Disposition header for those seems to prepend the project name
to the tarball name.

We really need spectool grab the filename which the URL ends with, not
some random other one that a Content-Disposition header might contain
-- I'd say it's far more common for a Content-Disposition header to
change the download name to something else than to fix it to the one
we already specified in the URL, so I won't be adding that option.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Red Hat and Fedora Working Groups

2013-10-05 Thread Mathieu Bridon


On Saturday, October 05, 2013 11:29 AM, Jóhann B. Guðmundsson wrote:

Did you look at the history who signed up to the WG page before it even
got announced to the community?


Who? People who were at Flock and/or had read the meeting logs and knew 
about the WG about to be announced.


I knew about that page before it was announced.

And I don't work for Red Hat, I just happen to read the FESCo meeting 
logs every week.



Want to take this further shall we start pointing out individuals that
Red Hat invented job positions for within our communities then planted
individuals outside the community in those positions to satisify it's
compulseve corporate need for control?


So every time you say that, I can't help thinking you're just jealous 
they took someone « outside the community » instead of you.


It might not be what you're thinking, but it's really how you sound.

Maybe those « individuals » are just more competent? Or you know, maybe 
Red Hat prefers hiring people who don't spend their time vomiting their 
hatred on mailing-lists?



--
Mathieu
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F-20 Branched report: 20131005 changes

2013-10-05 Thread Fedora Branched Report

Compose started at Sat Oct  5 09:15:02 UTC 2013

Broken deps for armhfp
--
[blueman]
blueman-1.23-7.fc20.armv7hl requires obex-data-server = 0:0.4.3
blueman-1.23-7.fc20.armv7hl requires gvfs-obexftp
[bwm-ng]
bwm-ng-0.6-11.1.fc20.armv7hl requires libstatgrab.so.9
[cloud-init]
cloud-init-0.7.2-4.fc20.noarch requires dmidecode
[cobbler]
cobbler-2.4.0-2.fc20.noarch requires syslinux
[fawkes]
fawkes-doc-0.5.0-9.fc20.noarch requires fawkes = 0:0.5.0-9.fc20
[fts]
fts-server-3.1.1-1.fc20.armv7hl requires libactivemq-cpp.so.14
[glusterfs]
glusterfs-ufo-3.4.0-8.fc20.noarch requires openstack-swift-proxy = 
0:1.8.0
glusterfs-ufo-3.4.0-8.fc20.noarch requires openstack-swift-object = 
0:1.8.0
glusterfs-ufo-3.4.0-8.fc20.noarch requires openstack-swift-container = 
0:1.8.0
glusterfs-ufo-3.4.0-8.fc20.noarch requires openstack-swift-account = 
0:1.8.0
glusterfs-ufo-3.4.0-8.fc20.noarch requires openstack-swift = 0:1.8.0
[gnome-do-plugins]
gnome-do-plugins-thunderbird-0.8.4-14.fc20.armv7hl requires thunderbird
[gofer]
ruby-gofer-0.75-4.fc20.noarch requires rubygem(qpid) = 0:0.16.0
[gradle]
gradle-1.0-18.fc20.noarch requires plexus-container-default
[grass]
grass-6.4.2-11.fc20.armv7hl requires libgeos-3.3.8.so
grass-libs-6.4.2-11.fc20.armv7hl requires libgeos-3.3.8.so
[gtkd]
gtkd-geany-tags-2.0.0-29.20120815git9ae9181.fc18.noarch requires gtkd = 
0:2.0.0-29.20120815git9ae9181.fc18
[kawa]
1:kawa-1.11-5.fc19.armv7hl requires servlet25
[koji]
koji-vm-1.8.0-2.fc20.noarch requires python-virtinst
[kyua-cli]
kyua-cli-0.5-3.fc19.armv7hl requires liblutok.so.0
kyua-cli-tests-0.5-3.fc19.armv7hl requires liblutok.so.0
[monotone]
monotone-1.0-11.fc19.armv7hl requires libbotan-1.8.2.so
perl-Monotone-1.0-11.fc19.armv7hl requires perl(:MODULE_COMPAT_5.16.2)
[mozilla-firetray]
mozilla-firetray-thunderbird-0.3.6-0.5.143svn.fc18.1.armv7hl requires 
thunderbird = 0:11
[msp430-libc]
msp430-libc-20120224-2.fc19.noarch requires msp430-gcc = 0:4.6.3
[nifti2dicom]
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtksys.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkWidgets.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkVolumeRendering.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkViews.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkTextAnalysis.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkRendering.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkParallel.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkInfovis.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkImaging.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkIO.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkHybrid.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGraphics.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGeovis.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGenericFiltering.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkFiltering.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCommon.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCharts.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libQVTK.so.5.10
[nocpulse-common]
nocpulse-common-2.2.7-2.fc20.noarch requires perl(RHN::DBI)
[openbox]
gdm-control-3.5.2-2.fc20.armv7hl requires gnome-panel
gnome-panel-control-3.5.2-2.fc20.armv7hl requires gnome-panel
[openpts]
openpts-0.2.6-7.fc20.armv7hl requires tboot
[osm2pgsql]
osm2pgsql-0.82.0-1.fc20.armv7hl requires libgeos-3.3.8.so
[ovirt-engine]
ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires 
classpathx-mail
[oyranos]
oyranos-libs-0.4.0-7.fc19.armv7hl requires libraw.so.5
[perl-Language-Expr]
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
[perl-MIME-Lite-HTML]
perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires 
perl(:MODULE_COMPAT_5.16.0)
[perl-MooseX-TrackDirty-Attributes]
perl-MooseX-TrackDirty-Attributes-2.002-2.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
[perl-Padre]
perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0)
[player]
player-3.0.2-32.fc20.armv7hl requires libstatgrab.so.9
player-3.0.2-32.fc20.armv7hl requires libgeos-3.3.8.so
[pure]
pure-doc-0.57-4.fc20.noarch requires pure = 0:0.57-4.fc20
[python-basemap]
python-basemap-1.0.6-4.fc20.armv7hl requires libgeos-3.3.8.so
[python-tag]
python-tag-2013.1-1.fc20.armv7hl requires libboost_python.so.1.53.0
[rootplot]
rootplot-2.2.1-7.fc19.noarch requires root-python
[rubygem-audited-activerecord]

Re: Red Hat and Fedora Working Groups

2013-10-05 Thread Frankie Onuonga

On Sat, Oct 5, 2013 at 8:08 AM, Mathieu Bridon
boche...@fedoraproject.orgwrote:

On Saturday, October 05, 2013 11:29 AM, Jóhann B. Guðmundsson wrote:

Did you look at the history who signed up to the WG page before it even
got announced to the community?

Who? People who were at Flock and/or had read the meeting logs and knew
about the WG about to be announced.

I knew about that page before it was announced.

And I don't work for Red Hat, I just happen to read the FESCo meeting logs
every week.

Want to take this further shall we start pointing out individuals that
Red Hat invented job positions for within our communities then planted
individuals outside the community in those positions to satisify it's
compulseve corporate need for control?

So every time you say that, I can't help thinking you're just jealous they
took someone « outside the community » instead of you.

It might not be what you're thinking, but it's really how you sound.

Maybe those « individuals » are just more competent? Or you know, maybe
Red Hat prefers hiring people who don't spend their time vomiting their
hatred on mailing-lists?

It sounds like this is an issue from way back from the tone of this email.

Come on guys we cant keep going back and forth on this. find it sad that
we are.
My opinion is this.
we get funding from these guys. So to some extent I think they ca put in
engineers to assist us when they see a feature that they want in.
I am not commenting on the methods they use.
This is because I actually do not care.

It is open source. Unhappy with something, just fork it and move on. That
is the beauty of it.
No one will come after you cause that is the beauty of the whole thing.

I think we also need to look at deliverables. I usually am not the person
looking at the small details.
For me it is more of deliver and we are all good.
I mean if this needs to be revised I am sure we can have a look at it and
ask them to change it for the community.

this is just my $0.02

thanks.

--
Mathieu

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct:
http://fedoraproject.org/code-**of-conducthttp://fedoraproject.org/code-of-conduct

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: boost141 and stability of Boost API?

2013-10-05 Thread Denis Arnaud

Hi Dave,

note that Boost-1.48 has been packaged for EPEL 5 and 6, but not yet
approved: http://bugzilla.redhat.com/show_bug.cgi?id=921134
In case it is useful to anyone, do not hesitate to approve it :)
And if there is more love, we could even embark on the way to package
Boost-1.54 for EPEL... But that is another story.

Kind regards

Denis

Ref:
http://lists.fedoraproject.org/pipermail/devel/2013-September/189704.html
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Review swaps: perl-Parse-DebControl, devscripts, debian-keyring, ubuntu-keyring, jetring + question: where to install keyrings?

2013-10-05 Thread Sérgio Basto

On Seg, 2013-09-23 at 10:30 +0200, Sandro Mani wrote: 
 On 23.09.2013 02:01, Zbigniew Jędrzejewski-Szmek wrote:
  On Mon, Sep 23, 2013 at 12:14:29AM +0200, Sandro Mani wrote:
  On 20.09.2013 06:37, Zbigniew Jędrzejewski-Szmek wrote:
  On Thu, Sep 19, 2013 at 06:41:03PM +0200, Sandro Mani wrote:
  Hi,
 
  In the hope to continue the effort of getting pbuilder (and hence an
  easy way to build deb packages from fedora) into the repos (review
  here: [1]), I've packaged devscripts, debian-keyring, ubuntu-keyring
  and jetring. Reviews are here:
 
  - jetring: https://bugzilla.redhat.com/show_bug.cgi?id=1009996
  - debian-keyring: https://bugzilla.redhat.com/show_bug.cgi?id=1009997
  - ubuntu-keyring: https://bugzilla.redhat.com/show_bug.cgi?id=1009998
  - perl-Parse-DebControl: 
  https://bugzilla.redhat.com/show_bug.cgi?id=100
  - devscripts: https://bugzilla.redhat.com/show_bug.cgi?id=101
(...) 
 Ok, thanks. I've gone ahead and created a keyrings-filesytem package, 
 review is here:
 
 https://bugzilla.redhat.com/show_bug.cgi?id=1010857
 
 I've also update the other reviews to use this package.

Hi Sandro , sorry I don't had time to look into this, but seems over
packages have a package to have just keyrings-filesytem, can't we group
jetring, debian-keyring and ubuntu-keyring in one package and add
keyrings-filesytem as sub package like pacman package does ? 

Other thing, what are dependencies of debian-keyring and ubuntu-keyring
to pbuider or perl-Parse-DebControl ? 

we still doesn't have rpmdevtools-8.4 packaged for F21 ...

Best regards, 
-- 
Sérgio M. B.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

21 matches

Mail list logo