Re: Lack of response about sponsorship

[Miroslav Suchý]

On 10/21/2013 09:38 PM, Michael Schwendt wrote:

   * Oldest request is from 2008(!) - but there are recent work on this BZ.

Probably the same reasons as with the "normal" review requests.
Sometimes reviews have stalled because of bundled libs, licensing troubles,
missing deps, waiting for upstream.
http://fedoraproject.org/PackageReviewStatus/NEW.html


Yes.
But is this just problem of submiter? I would say that sponsor should lead. And either help to resolve it or suggest to 
close it. Having it open indefinitely with false hope is not good.



>   * Oldest change on BZs waiting for sponsor is from 2010.

Which ticket is that?
Above page lists four tickets from 2011, but all have changed in 2013.



https://bugzilla.redhat.com/show_bug.cgi?id=508126

--
Miroslav Suchy, RHCE, RHCDS
Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys
--
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: Introducing of Pierre Jourdain

[Christopher Meng]

Hello, nice to meet you.

Just a note that your name linked with this gmail address is:

""

Hope you've noticed that.
-- 
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: Lack of response about sponsorship

[Luya Tshimbalanga]

On 17/10/13 05:30 AM, Matthew Miller wrote:

I agree; this is a problem. (In general, I think the beg-for-review-swaps
system is not friendly to new contributors.) I see that you applied for
sponsorship https://fedorahosted.org/packager-sponsors/ticket/90 but there
wasn't enough activity on the ticket to make the approval threshold. Maybe
something which attracts more activity from sponsors in reviewing new
sponsors would help?

I have been caught with other projects (Design spin to name a few) hence 
the lack of activities on the tickets I will look up when I will have 
opportunity.


Luya
--
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: Lack of response about sponsorship

[Michael Schwendt]

On Tue, 22 Oct 2013 08:59:28 +0200, Miroslav Suchý wrote:

> On 10/21/2013 09:38 PM, Michael Schwendt wrote:
> >>* Oldest request is from 2008(!) - but there are recent work on this BZ.
> > Probably the same reasons as with the "normal" review requests.
> > Sometimes reviews have stalled because of bundled libs, licensing troubles,
> > missing deps, waiting for upstream.
> > http://fedoraproject.org/PackageReviewStatus/NEW.html
> 
> Yes.
> But is this just problem of submiter? I would say that sponsor should lead. 
> And either help to resolve it or suggest to 
> close it. Having it open indefinitely with false hope is not good.

Let's talk about specific tickets then, please. 
There are various reasons why there may be no progress in some reviews.

> >> >   * Oldest change on BZs waiting for sponsor is from 2010.
> > Which ticket is that?
> > Above page lists four tickets from 2011, but all have changed in 2013.
> >
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=508126

It's approved since 2009-09-21 -> fedora-review+
It's approved in dist git since 2009--09-22 -> fedora-cvs+
Packager is sponsored -> 2009-09-21
Packager is member of more than a dozen groups in FAS.
It's waiting for the submitter to import and build.
https://bugzilla.redhat.com/show_activity.cgi?id=508126
-- 
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: --Wl, -z, relro in LDFLAGS required?/Inconsistency when not using %configure

[Ville Skyttä]

On Mon, Oct 21, 2013 at 3:08 PM, Michael Schwendt  wrote:
> On Mon, 21 Oct 2013 04:01:15 +0200, Kevin Kofler wrote:
>>
>> We already have one, it's called %{__global_ldflags}. You are indeed
>> supposed to set LDFLAGS of handwritten makefiles to that. The guidelines
>> need to be updated.
>
> Also raises the question whether we want more such packages to do
[...]

In many cases the values aren't picked up from the environment but
need to be passed in by other means (such as arguments to make etc).

Anyway for the ones that do get them from the environment, I wonder if
there's a macro whose content gets run at start of %build
(%__spec_build_pre ?), or if the %build section marker could be
overloaded to do the environment setup so it could be moved there from
%configure
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Bug 1021852] New: perl-HTML-Template-2.95 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1021852

Bug ID: 1021852
   Summary: perl-HTML-Template-2.95 is available
   Product: Fedora
   Version: rawhide
 Component: perl-HTML-Template
  Keywords: FutureFeature, Triaged
  Assignee: tcall...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-de...@lists.fedoraproject.org,
tcall...@redhat.com



Latest upstream release: 2.95
Current version/release in Fedora Rawhide: 2.94-4.fc20
URL: http://search.cpan.org/dist/HTML-Template/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=U3cBmupsfm&a=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Fwd: Broken dependencies: tika mvn(org.bouncycastle:bc*-jdk16:1.46)

[Stanislav Ochotnicky]

Quoting punto...@libero.it (2013-10-21 23:32:47)
> 
> any ideas?
> thanks
> regards
> 
>  Messaggio originale 
> Oggetto:Broken dependencies: tika
> Data:   Mon, 21 Oct 2013 21:01:15 + (UTC)
> Mittente:   build...@fedoraproject.org
> A:  tika-ow...@fedoraproject.org
> 
> 
> 
> tika has broken dependencies in the rawhide tree:
> On x86_64:
> tika-parsers-1.4-2.fc21.noarch requires 
> mvn(org.bouncycastle:bcprov-jdk16:1.46)
> tika-parsers-1.4-2.fc21.noarch requires 
> mvn(org.bouncycastle:bcmail-jdk16:1.46)
> On i386:
> tika-parsers-1.4-2.fc21.noarch requires 
> mvn(org.bouncycastle:bcprov-jdk16:1.46)
> tika-parsers-1.4-2.fc21.noarch requires 
> mvn(org.bouncycastle:bcmail-jdk16:1.46)
> On armhfp:
> tika-parsers-1.4-2.fc21.noarch requires 
> mvn(org.bouncycastle:bcprov-jdk16:1.46)
> tika-parsers-1.4-2.fc21.noarch requires 
> mvn(org.bouncycastle:bcmail-jdk16:1.46)
> Please resolve this as soon as possible.


This is a bug in bouncycastle, it should not have versioned jar symlinks unless
it's a compat package.

-- 
Stanislav Ochotnicky 
Software Engineer - Developer Experience

PGP: 7B087241
Red Hat Inc.   http://cz.redhat.com
-- 
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: Fwd: Broken dependencies: tika mvn(org.bouncycastle:bc*-jdk16:1.46)

[Mikolaj Izdebski]

On 10/21/2013 11:32 PM, punto...@libero.it wrote:
> tika has broken dependencies in the rawhide tree:
> On x86_64:
> tika-parsers-1.4-2.fc21.noarch requires
> mvn(org.bouncycastle:bcprov-jdk16:1.46)
> tika-parsers-1.4-2.fc21.noarch requires
> mvn(org.bouncycastle:bcmail-jdk16:1.46)

This is a bug in bouncycastle -- it does not follow Java packaging
guidelines in terms of versioned JARs and compatibility packages.

-- 
Mikolaj Izdebski
IRC: mizdebsk
-- 
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: --Wl, -z, relro in LDFLAGS required?/Inconsistency when not using %configure

[Ralf Corsepius]

On 10/22/2013 10:26 AM, Ville Skyttä wrote:

On Mon, Oct 21, 2013 at 3:08 PM, Michael Schwendt  wrote:

On Mon, 21 Oct 2013 04:01:15 +0200, Kevin Kofler wrote:

We already have one, it's called %{__global_ldflags}. You are indeed
supposed to set LDFLAGS of handwritten makefiles to that. The guidelines
need to be updated.

Also raises the question whether we want more such packages to do

[...]

In many cases the values aren't picked up from the environment but
need to be passed in by other means (such as arguments to make etc).
Also, the meaning of "LDFLAGS" is ambigous, which means implicitly 
passing it is somewhat dangerous.


It may mean flags to be passed to the linker through the compiler", but 
there also exist Makefiles/build environment, which treat LDFLAGS as 
"flags to be directly passed to the linker".


-Wl,-z,relo is from the former family (-Wl ... gcc options to be passed 
to the linker through gcc).


gmake defines it as (from "info make"):

`LDFLAGS'
 Extra flags to give to compilers when they are supposed to invoke
 the linker, `ld'.

Ralf



--
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: --Wl, -z, relro in LDFLAGS required?/Inconsistency when not using %configure

[Michael Schwendt]

On Tue, 22 Oct 2013 11:26:18 +0300, Ville Skyttä wrote:

> In many cases the values aren't picked up from the environment but
> need to be passed in by other means (such as arguments to make etc).

Okay. "make -e …" could be run in that case as a work-around. But
overriding Makefile variables completely can be less than ideal (this
can be observed in some spec files where the packagers also adds the
libs to link with, so the build doesn't break). Better would be that
the Makefile inherits from values passed in via Make or the env.

When using %configure always, even if not available, that makes it
possible to reuse the env vars it defines, and one doesn't need to
access the RPM macros:

  %configure || :
  make CFLAGS="$CFLAGS" LDFLAGS="$LDFLAGS"

To repeat from the earlier reply, one may want to take precautions,
so when a future upgrade adds a configure script, one drops the '|| :'.
-- 
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: Fwd: Broken dependencies: tika mvn(org.bouncycastle:bc*-jdk16:1.46)

[punto...@libero.it]

Il 22/10/2013 10:53, Mikolaj Izdebski ha scritto:

On 10/21/2013 11:32 PM, punto...@libero.it wrote:

tika has broken dependencies in the rawhide tree:
On x86_64:
 tika-parsers-1.4-2.fc21.noarch requires
mvn(org.bouncycastle:bcprov-jdk16:1.46)
 tika-parsers-1.4-2.fc21.noarch requires
mvn(org.bouncycastle:bcmail-jdk16:1.46)

This is a bug in bouncycastle -- it does not follow Java packaging
guidelines in terms of versioned JARs and compatibility packages.


hi
fine, removed the version to bcprov and bcmail JARs (F20 and rawhide)
thanks
gil
<>-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

dracut: how do I...

[Felix Miata]

Difference in size between initramfs generated with and without nohostonly is 
huge. I don't want to routinely use nohostonly, but neither do I want a 
specific root filesystem specified with root= in the image. I want 
root= on cmdline to be obeyed in order to be able to "clone" the root 
filesystem for use on same hardware as many times as I want for various 
reasons and use whichever according to cmdline root=, having regenerated 
UUID(s)s on the clone(s). Is there a way? If there is one to be found in the 
dracut man page, I'm not seeing it. As it is, one must choose between 
nohostonly, or chrooting into the clone to regenerate with correct root UUID.

--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
--
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: --Wl, -z, relro in LDFLAGS required?/Inconsistency when not using %configure

[Ville Skyttä]

On Tue, Oct 22, 2013 at 1:47 PM, Michael Schwendt  wrote:
> Better would be that
> the Makefile inherits from values passed in via Make or the env.

Sure.

>   %configure || :
[...]
> To repeat from the earlier reply, one may want to take precautions,
> so when a future upgrade adds a configure script, one drops the '|| :'.

IMHO adding precaution cruft like "[ -f configure ] && exit -1 [...]"
is a sign of the packager doing package updates too carelessly if
(s)he doesn't even trust oneself or others to check if the upstream
build system has changed between releases...
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

User/Group ID assignment

[Mateusz Marzantowicz]

Are there any guidelines regarding user and group id number assignment
on Fedora?

I'd like to add user/group for daemon, related to installed package, in
order to avoid running it as root. What numbers are already reserved and
where can I find up to date table with that numbers?

I see in my /etc/passwd that regular user accounts are assigned numbers
starting from 1000 (was it 500 on older systems?), 0-200 and 201-999 are
used by system accounts and packages like httpd, wireshark, etc.

I've found this [1] site but it looks outdated and incomplete because it
references FC5 and discussions pointed there are from 2005.

[1] https://fedoraproject.org/wiki/PackageUserCreation



Mateusz Marzantowicz
-- 
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: User/Group ID assignment

[Mikolaj Izdebski]

On 10/22/2013 01:25 PM, Mateusz Marzantowicz wrote:
> Are there any guidelines regarding user and group id number assignment
> on Fedora?
> 
> I'd like to add user/group for daemon, related to installed package, in
> order to avoid running it as root. What numbers are already reserved and
> where can I find up to date table with that numbers?
> 
> I see in my /etc/passwd that regular user accounts are assigned numbers
> starting from 1000 (was it 500 on older systems?), 0-200 and 201-999 are
> used by system accounts and packages like httpd, wireshark, etc.

UIDs >= 1000 are reserved for users, < 1000 for system.  System UIDs can
be allocated statically or dynamically.  Static UID allocation can be
found in [1], to add a new UID you need to file a RFE against setup
package.  Dynamic UID allocation is done from 999 downwards.  You don't
need to reserve anything, but UIDs can very between systems.

[1] /usr/share/doc/setup/uidgid

-- 
Mikolaj Izdebski
IRC: mizdebsk
-- 
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: User/Group ID assignment

[Simone Caronni]

Hello,

On 22 October 2013 13:25, Mateusz Marzantowicz wrote:

> Are there any guidelines regarding user and group id number assignment
> on Fedora?
>

please read the packaging guidelines regarding user creation at rpm install
time:

http://fedoraproject.org/wiki/Packaging:UsersAndGroups

As a rule of thumb, your user must be dynamically allocated and not deleted
after rpm uninstallation.
If you need a static UID you need to open a ticket to FPC.

Details in the wiki page.

Regards,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: --Wl, -z, relro in LDFLAGS required?/Inconsistency when not using %configure

[Michael Schwendt]

On Tue, 22 Oct 2013 14:06:33 +0300, Ville Skyttä wrote:

> IMHO adding precaution cruft like "[ -f configure ] && exit -1 [...]"
> is a sign of the packager doing package updates too carelessly if
> (s)he doesn't even trust oneself or others to check if the upstream
> build system has changed between releases...

Agreed. It's a trade-off. Guards aren't bad, but in this case their
benefit is questionable. It probably doesn't work completely anyway, since
if the build framework uses Autotools, there likely are no pregenerated
Makefiles, and only a successful run on the configure script will generate
them.
-- 
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: User/Group ID assignment

[Mateusz Marzantowicz]

On 22.10.2013 13:32, Mikolaj Izdebski wrote:
> On 10/22/2013 01:25 PM, Mateusz Marzantowicz wrote:
>> Are there any guidelines regarding user and group id number assignment
>> on Fedora?
>>
>> I'd like to add user/group for daemon, related to installed package, in
>> order to avoid running it as root. What numbers are already reserved and
>> where can I find up to date table with that numbers?
>>
>> I see in my /etc/passwd that regular user accounts are assigned numbers
>> starting from 1000 (was it 500 on older systems?), 0-200 and 201-999 are
>> used by system accounts and packages like httpd, wireshark, etc.
> 
> UIDs >= 1000 are reserved for users, < 1000 for system.  System UIDs can
> be allocated statically or dynamically.  Static UID allocation can be
> found in [1], to add a new UID you need to file a RFE against setup
> package.  Dynamic UID allocation is done from 999 downwards.  You don't
> need to reserve anything, but UIDs can very between systems.
> 
> [1] /usr/share/doc/setup/uidgid
> 

Thanks, that is the list I was looking for. Is there any mechanism to
assign first available id from "less than 999" pool or should I manually
find the right number? I understand that dynamic assignment is done by
package manager, but I don't want to rebuild and reinstall rpm package
for now on.


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

Broken dependencies: perl-MIME-Lite-HTML

[buildsys]

perl-MIME-Lite-HTML has broken dependencies in the F-20 tree:
On x86_64:
perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires 
perl(:MODULE_COMPAT_5.16.0)
On i386:
perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires 
perl(:MODULE_COMPAT_5.16.0)
On armhfp:
perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires 
perl(:MODULE_COMPAT_5.16.0)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-PDL

[buildsys]

perl-PDL has broken dependencies in the F-20 tree:
On x86_64:
perl-PDL-2.4.10-6.fc19.x86_64 requires perl(:MODULE_COMPAT_5.16.2)
perl-PDL-2.4.10-6.fc19.x86_64 requires libgd.so.2()(64bit)
On i386:
perl-PDL-2.4.10-6.fc19.i686 requires perl(:MODULE_COMPAT_5.16.2)
perl-PDL-2.4.10-6.fc19.i686 requires libgd.so.2
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Language-Expr

[buildsys]

perl-Language-Expr has broken dependencies in the F-20 tree:
On x86_64:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
On i386:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
On armhfp:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: slic3r

[buildsys]

slic3r has broken dependencies in the F-20 tree:
On x86_64:
slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3)
On i386:
slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3)
On armhfp:
slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-BerkeleyDB

[buildsys]

perl-BerkeleyDB has broken dependencies in the F-20 tree:
On x86_64:
perl-BerkeleyDB-0.53-1.fc20.x86_64 requires libdb = 0:5.3.21
On i386:
perl-BerkeleyDB-0.53-1.fc20.i686 requires libdb = 0:5.3.21
On armhfp:
perl-BerkeleyDB-0.53-1.fc20.armv7hl requires libdb = 0:5.3.21
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Padre

[buildsys]

perl-Padre has broken dependencies in the F-20 tree:
On x86_64:
perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0)
On i386:
perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0)
On armhfp:
perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: dracut: how do I...

[Harald Hoyer]

On 10/22/2013 12:59 PM, Felix Miata wrote:
> Difference in size between initramfs generated with and without nohostonly is
> huge. I don't want to routinely use nohostonly, but neither do I want a 
> specific
> root filesystem specified with root= in the image. I want root= on 
> cmdline
> to be obeyed in order to be able to "clone" the root filesystem for use on 
> same
> hardware as many times as I want for various reasons and use whichever 
> according
> to cmdline root=, having regenerated UUID(s)s on the clone(s). Is there a way?
> If there is one to be found in the dracut man page, I'm not seeing it. As it 
> is,
> one must choose between nohostonly, or chrooting into the clone to regenerate
> with correct root UUID.

If your root is on a non-assembled device (like a plain partition), then dracut
(at least for F20) does not store any UUIDs in the initramfs in hostonly mode.

You can check with:

# lsinitrd | egrep '.*requires.*\.device'

and

# lsinitrd | egrep 'etc/cmdline.d/.*\.conf'

Both should be empty for simple partition setups.
-- 
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: F21/F22 System Wide Change: Python 3 as the Default Implementation

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/17/2013 11:45 AM, Miloslav Trmač wrote:
> On Thu, Oct 17, 2013 at 9:13 AM, Bohuslav Kabrda 
> wrote:
>>> * The Change plan should be updated to take into account Dennis's
>>> Feedback * I suggeested that perhaps a better contingency plan would be
>>> to simply ship with some applications using python2 and others using
>>> python3.
>>> 
>> 
>> Personally I don't have problem with this, but: - Side tag is a good
>> contingency plan. If we have to revert for whatever reason, then without
>> sidetag we will have to rebuild everything with Python 2 again.
> 
> Yes.  In general it would be great to start frequently making disruptive
> changes on branches to not disrupt other people, and this is a very big
> change where at least having the option is very much warranted Mirek
> 
Began working on porting all of the SELinux python code to python3.  I plan on
shipping bindings for both 2 and 3, but tools are hung up on missing yum and
dbus python3 bindings.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJmbgUACgkQrlYvE4MpobMUygCdFFfP2E4luT6+U1+y6sOdglWe
gK4AoMNhuRj8sB0ZuFvUD8nn3CZPDKqH
=4pTR
-END PGP SIGNATURE-
-- 
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: 20131022 changes

[Fedora Branched Report]

Compose started at Tue Oct 22 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-7.fc20.noarch requires dmidecode
[cobbler]
cobbler-2.4.0-2.fc20.noarch requires syslinux
[condor-wallaby]
condor-wallaby-client-5.0.3-4.fc20.noarch requires python-qmf >= 
0:0.9.1073306
[fts]
fts-server-3.1.1-1.fc20.armv7hl requires libactivemq-cpp.so.14
[glpi]
glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Version
glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Stdlib
glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-ServiceManager
glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Loader
glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-I18n
glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Cache-apc
glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Cache
[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.3-2.fc20.armv7hl requires libgeos-3.3.8.so
grass-libs-6.4.3-2.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
[oyranos]
oyranos-libs-0.4.0-7.fc19.armv7hl requires libraw.so.5
[perl-BerkeleyDB]
perl-BerkeleyDB-0.53-1.fc20.armv7hl requires libdb = 0:5.3.21
[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-Padre]
perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0)
[pure]
pure-doc-0.57-4.fc20.noarch requires pure = 0:0.57-4.fc20
[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
[ruby-spqr]
ruby-spqr-0.3.6-7.fc20.noarch requires ruby-qpid-qmf
[rubygem-audited-activerecord]
rubygem-audited-activerecord-3.0.0-3.fc19.noarch requires 
rubygem(activerecord) < 0:4
[rubygem-fog]
rubygem-fog-1.11.1-1.fc20.noarch requires rubygem(nokogiri) < 0:1.6
[scala]
scala-2.9.2-2.fc19

Re: User/Group ID assignment

[Mikolaj Izdebski]

On 10/22/2013 01:43 PM, Mateusz Marzantowicz wrote:
> Thanks, that is the list I was looking for. Is there any mechanism to
> assign first available id from "less than 999" pool or should I manually
> find the right number? I understand that dynamic assignment is done by
> package manager, but I don't want to rebuild and reinstall rpm package
> for now on.

Dynamic assignment is done by adduser tool.  adduser -r will create user
with UID 999 if available, if not then 998 and so on.  Basically adduser
-r chooses UIDs from SYS_UID_MIN to SYS_UID_MAX, as defined in
/etc/login.defs

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

Introducing Myself

[Baptiste Mille-Mathias]

Hello,

Per the requested process for new packagers, I hereby introduce myself.

My name is Baptiste Mille-Mathias, I'm French, 34 years old guy.
I use Fedora since the beginning of 2011 but I only recently started
contributing to Fedora with packaging [0]. Haïkel Guémar (number80) is
mentoring me.

My day-to-day job is Production Application / System Engineer in the
South of France.
I'm also the president of GNOME-FR the non-profit organization that
promote GNOME in France (we participate events like FOSDEM too).

My FAS name is baptistemm [1]. You can found me on irc with this nickname.

Regards.

[0] 
https://lists.fedoraproject.org/pipermail/package-announce/2013-October/118884.html
[1] https://admin.fedoraproject.org/accounts/user/view/baptistemm
-- 
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: Introducing Myself

[Haïkel Guémar]

Le 22/10/2013 16:06, Baptiste Mille-Mathias a écrit :

Hello,

Per the requested process for new packagers, I hereby introduce myself.

My name is Baptiste Mille-Mathias, I'm French, 34 years old guy.
I use Fedora since the beginning of 2011 but I only recently started
contributing to Fedora with packaging [0]. Haïkel Guémar (number80) is
mentoring me.

My day-to-day job is Production Application / System Engineer in the
South of France.
I'm also the president of GNOME-FR the non-profit organization that
promote GNOME in France (we participate events like FOSDEM too).

My FAS name is baptistemm [1]. You can found me on irc with this nickname.

Regards.

[0] 
https://lists.fedoraproject.org/pipermail/package-announce/2013-October/118884.html
[1] https://admin.fedoraproject.org/accounts/user/view/baptistemm


Welcome Baptiste !
I have no doubts you'll a be valuable member of the Fedora Community, 
keep up with the good work. :)


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

Canonical copy of config.guess/config.sub

[Florian Weimer]

What's the canonical system-wide copy of the config.guess file?  I have:

9c01fa8c4554cb2c7b92c95dfa0dbfcf /usr/lib/rpm/redhat/config.guess
9c01fa8c4554cb2c7b92c95dfa0dbfcf /usr/share/libtool/config/config.guess
c3178bdc1506f569388eaebec2026003 /usr/lib/rpm/config.guess
d9375ba9d0b8cfd7bb6737e3fc43984f /usr/share/dejagnu/libexec/config.guess
eea34cf893bb060ee20189e256a8065a /usr/share/automake-1.13/config.guess

The situation with config.sub isn't much better:

0b96c40308f509ba2c0e132c1d2e70e7  /usr/lib/rpm/config.sub
1803a1d601bcf4debccfe2902c4f0f65  /usr/lib/rpm/redhat/config.sub
1803a1d601bcf4debccfe2902c4f0f65  /usr/share/libtool/config/config.sub
520911d86319be25a97f4be9ed7e0301  /usr/share/automake-1.13/config.sub

I'm asking because I want to propose upstream that they put in a check 
if the system-wide version is newer, and if it is, just run it instead 
of the package-supplied copy.  But in order to do that, we need a 
canonical path.


Right now, iterating over /usr/share/automake*/config.{guess,sub} looks 
most promising and would work on Debian as well.


--
Florian Weimer / Red Hat Product Security Team
--
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: --Wl,-z,relro in LDFLAGS required?/Inconsistency when not using %configure

[Adam Jackson]

On Sun, 2013-10-20 at 23:42 +0200, Till Maas wrote:
> Hi,
> 
> https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#Compiler_flags
> 
> mentions only %optflags to be required for packages but I noticed that
> %configure sets LDFLAGS to a value different than %optflags:

As noted there does exist an rpm variable for this.  However at least
the relro part of it seems to be unnecessary with current binutils:

%if 0%{?fedora} >= 18
* Tue Mar 06 2012 Nick Clifton  - 2.22.52.0.1-7
- Enable -zrelro by default. (#621983 #807831)
%endif

- ajax

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

[Bug 1013122] perl-MIME-Charset-1.011.1 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1013122

Xavier Bachelot  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2013-10-22 10:49:09



-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=ljWClAELC9&a=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Canonical copy of config.guess/config.sub

[Peter Lemenkov]

2013/10/22 Florian Weimer :
> What's the canonical system-wide copy of the config.guess file?  I have:

I'm copying them from libtool.

-- 
With best regards, Peter Lemenkov.
-- 
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: --Wl,-z,relro in LDFLAGS required?/Inconsistency when not using %configure

[Reindl Harald]

Am 22.10.2013 16:47, schrieb Adam Jackson:
> On Sun, 2013-10-20 at 23:42 +0200, Till Maas wrote:
>> https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#Compiler_flags
>>
>> mentions only %optflags to be required for packages but I noticed that
>> %configure sets LDFLAGS to a value different than %optflags:
> 
> As noted there does exist an rpm variable for this.  However at least
> the relro part of it seems to be unnecessary with current binutils:
> 
> %if 0%{?fedora} >= 18
> * Tue Mar 06 2012 Nick Clifton  - 2.22.52.0.1-7
> - Enable -zrelro by default. (#621983 #807831)
> %endif

this is only *partial* RELRO
Full RELRO: -Wl,-z,now -Wl,-z,relro

http://tk-blog.blogspot.co.at/2009/02/relro-not-so-well-known-memory.html





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

Is rpmbuild reentrant?

[Petr Pisar]

Is it healty to execute rpmbuild while building a package?

I have tests for perl dependencency generator filters. I.e. the tests
build a package using rpmbuild with redefeined all the `_*dir' macros,
then use librpm to query requires and provides from built package, and
then do checks on the values.

I'm thinking how to plug the tests into Fedora. The simplest solution is
to run the tests in %check phase of a package (I don't know which one,
but it does not matter which one).

I've already heard warnings that calling rpm from package scriptlets is
not recommend.

What the situation with rpmbuild?

-- Petr

-- 
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: communications and community [was Re: Lack of response about sponsorship]

[Matthew Miller]

On Mon, Oct 21, 2013 at 08:26:54PM +0200, Michael Schwendt wrote:
> Correct. Less lists (or the same lists) and with a more well-defined
> target group and description.

So, in the not so far future, we'll have mailman3 and hyperkitty, and we
want to migrate the lists to that. That switchover point could also be a
time when we consolidate and rationalize the overall structure.




-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
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: Is rpmbuild reentrant?

[Neil Horman]

On Tue, Oct 22, 2013 at 03:03:44PM +, Petr Pisar wrote:
> Is it healty to execute rpmbuild while building a package?
> 
> I have tests for perl dependencency generator filters. I.e. the tests
> build a package using rpmbuild with redefeined all the `_*dir' macros,
> then use librpm to query requires and provides from built package, and
> then do checks on the values.
> 
> I'm thinking how to plug the tests into Fedora. The simplest solution is
> to run the tests in %check phase of a package (I don't know which one,
> but it does not matter which one).
> 
> I've already heard warnings that calling rpm from package scriptlets is
> not recommend.
> 
> What the situation with rpmbuild?
> 
I'm not sure how re-entrant-safe rpmbuild is, but doing the above seems a bit
dodgy in general.  Could you instead package the test separately from the
dependency generator rpm, make the latter depedent on the former, and then use
chain-build in koji to build them at the same time?

Neil

> -- Petr
> 
> -- 
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://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: Canonical copy of config.guess/config.sub

[Ralf Corsepius]

On 10/22/2013 04:48 PM, Peter Lemenkov wrote:

2013/10/22 Florian Weimer :

What's the canonical system-wide copy of the config.guess file?  I have:

I'm copying them from libtool.


Why?

config.sub/config.guess originate from an upstream of their own (The 
config project):

http://savannah.gnu.org/projects/config
which is where GNU upstreams usually update their config.* from, when 
preparing releases.


Also, automake-based projects receive the versions bundled with 
automake, when running automake rsp. autoreconf.


So, if there's something resembling to a system-wide copy, then it's the 
version in automake or that in rpm (Because that's where rpmbuild 
currently picks it up from).


That said, it might be worth considering a system-wide "config" package ;)

Ralf



--
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: The trouble with metadata-extractor

[Andrea Musuruane]

I send again the following post. I can't believe not to get an opinion :)

Bye,

Andrea.



On Sun, Oct 20, 2013 at 11:37 PM, Andrea Musuruane wrote:

> Hi all,
> last April the following bug report was opened:
> https://bugzilla.redhat.com/show_bug.cgi?id=947457
>
> As I stated on bugzilla, metadata-extractor was just needed by JOSM.
> Updating metadata-extractor would break JOSM. Anyway I suggested to
> patch JOSM to use a newer version of metadata-extractor if he really
> needed it. I had no response at all.
>
> BTW, I am metadata-extractor maintainer, and not JOSM maintainer.
>
> This evening the submitter emailed me privately and I discovered that
> meanwhile, a new review request for a newer version of
> metadata-extractor was approved and now it is part of Fedora:
> https://bugzilla.redhat.com/show_bug.cgi?id=1004563
>
> As I understand now, newer metadata-extractor is required by Apache
> Sorl and Apache Tika, which are not yet part of Fedora.
>
> He asked me to "exchange our repository" "to simplify some build with
> maven". And with that I presume that he would like to have his package
> called metadata-extractor because he has troubles to build sorl and
> tika.
>
> I think all this have been handled very badly. He could have told why
> he needed a more recent version of metadata-extractor in the first
> place, the reviewer of #1004563 could have checked if the package
> followed the naming guidelines and/or have checked if the package was
> already in Fedora.
>
> I still think that my original plan (i.e. patching JOSM). was more
> sensible.
>
> What to do now? What do you think?
>
> If it helps, if it makes things easier, I can release the ownership of
> metadata-extractor and someone else can have good care. I just
> packaged it because, as an openstreetmap mapper, I longed to have JOSM
> in Fedora.
>
> Regards,
>
> Andrea.
>
-- 
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: The trouble with metadata-extractor

[punto...@libero.it]

Il 22/10/2013 17:54, Andrea Musuruane ha scritto:

I send again the following post. I can't believe not to get an opinion :)

Bye,

Andrea.



hi


On Sun, Oct 20, 2013 at 11:37 PM, Andrea Musuruane > wrote:


Hi all,
last April the following bug report was opened:
https://bugzilla.redhat.com/show_bug.cgi?id=947457

As I stated on bugzilla, metadata-extractor was just needed by JOSM.
Updating metadata-extractor would break JOSM. Anyway I suggested to
patch JOSM to use a newer version of metadata-extractor if he really
needed it. I had no response at all.

BTW, I am metadata-extractor maintainer, and not JOSM maintainer.

This evening the submitter emailed me privately and I discovered that
meanwhile, a new review request for a newer version of
metadata-extractor was approved and now it is part of Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=1004563

As I understand now, newer metadata-extractor is required by Apache
Sorl and Apache Tika, which are not yet part of Fedora.


wrong, Apache tika is already part of Fedora
and for question of time only for import some new libraries for Wildfly 8.x
was disabled a module (tika-parsers 
https://bugzilla.redhat.com/show_bug.cgi?id=1019650)

but is required also , by some Bigdata (hadhoop) packages


He asked me to "exchange our repository" "to simplify some build with
maven". And with that I presume that he would like to have his package
called metadata-extractor because he has troubles to build sorl and
tika.


no i havent any trouble for me is the same


I think all this have been handled very badly. He could have told why
he needed a more recent version of metadata-extractor in the first
place, the reviewer of #1004563 could have checked if the package
followed the naming guidelines and/or have checked if the package was
already in Fedora.

I still think that my original plan (i.e. patching JOSM). was more
sensible.

What to do now? What do you think?

If it helps, if it makes things easier, I can release the ownership of
metadata-extractor and someone else can have good care. I just
packaged it because, as an openstreetmap mapper, I longed to have JOSM
in Fedora.


regards
gil


Regards,

Andrea.






<>-- 
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: The trouble with metadata-extractor

[Stanislav Ochotnicky]

Ugh, what a mess..

Quoting Andrea Musuruane (2013-10-20 23:37:54)
> Hi all,
> last April the following bug report was opened:
> https://bugzilla.redhat.com/show_bug.cgi?id=947457
> 
> As I stated on bugzilla, metadata-extractor was just needed by JOSM.
> Updating metadata-extractor would break JOSM. Anyway I suggested to
> patch JOSM to use a newer version of metadata-extractor if he really
> needed it. I had no response at all.
>
> BTW, I am metadata-extractor maintainer, and not JOSM maintainer.

Sorry but it is your responsibility as maintainer to keep the package up to date
as much as possible. If JOSM required older version you should work with JOSM
maintainer and upstream to update it to latest (providing patches/testing etc.)

Why are you even maintaining metadata-extractor if you have no use for it? It
only makese sense for JOSM maintainer to maintain metadata-extractor in the
first place since he's the only user of the library

> This evening the submitter emailed me privately and I discovered that
> meanwhile, a new review request for a newer version of
> metadata-extractor was approved and now it is part of Fedora:
> https://bugzilla.redhat.com/show_bug.cgi?id=1004563

I don't like the naming of the package, both are metadata-extractor 2.x. If
anything new package should have been metadata-extractor26. Technically the
review was OK, the packages do not conflict in any way, but they are helluva
confusing.

All in all, even if JOSM couldn't be ported it would have been better to package
metadata-extractor-compat solely for JOSM and then just update extractor to
latest upstream.

> As I understand now, newer metadata-extractor is required by Apache
> Sorl and Apache Tika, which are not yet part of Fedora.

Already are as was mentioned

> He asked me to "exchange our repository" "to simplify some build with
> maven". And with that I presume that he would like to have his package
> called metadata-extractor because he has troubles to build sorl and
> tika.

Frankly...I'd rather ask for clarification. I have trouble understanding some
people

> I think all this have been handled very badly. He could have told why
> he needed a more recent version of metadata-extractor in the first
> place, the reviewer of #1004563 could have checked if the package
> followed the naming guidelines and/or have checked if the package was
> already in Fedora.

The review was technically OK, there was one question from reviewer missing: Why
cannot you use version already in Fedora and what have you done to fix that?

Other than that the packages don't really conflict or cause any issues to each
other AFAIK.

> I still think that my original plan (i.e. patching JOSM). was more sensible.

Agreed

> What to do now? What do you think?

Ideally? I'd say:

1. Update metadata-extractor to latest upstream, add maven metadata, shell
script in /usr/bin/ etc. Basically overwrite metadata-extractor with current
metadata-extractor2
2. Sort out JSOM breakage afterwards. Either package metadata-extractor-compat,
or patch JSOM (ideally going to upstream with the patch afterwards)
3. Obsolete/deprecate metadata-extractor2
4. Wham someone with a cluestick

> If it helps, if it makes things easier, I can release the ownership of
> metadata-extractor and someone else can have good care. I just
> packaged it because, as an openstreetmap mapper, I longed to have JOSM
> in Fedora

Libraries should be generally maintained by people who are actually using them
in some application. But it's up to you after all said and done if you want to
keep maintaining it.

-- 
Stanislav Ochotnicky 
Software Engineer - Developer Experience

PGP: 7B087241
Red Hat Inc.   http://cz.redhat.com
-- 
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: The trouble with metadata-extractor

[punto...@libero.it]

Il 22/10/2013 18:33, Stanislav Ochotnicky ha scritto:

Ideally? I'd say:

1. Update metadata-extractor to latest upstream, add maven metadata, shell
 script in/usr/bin/  etc. Basically overwrite metadata-extractor with 
current
 metadata-extractor2
2. Sort out JSOM breakage afterwards. Either package metadata-extractor-compat,
 or patch JSOM (ideally going to upstream with the patch afterwards)
3. Obsolete/deprecate metadata-extractor2
4. Wham someone with a cluestick


it was just that I was referring to in my private email. from which 
badly was extracted part of the contents

regards

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

File Test-Output-1.02.tar.gz uploaded to lookaside cache by pghmcfc

[Paul Howarth]

A file has been added to the lookaside cache for perl-Test-Output:

d80890160737cdf4c3241d48428d33ab  Test-Output-1.02.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: bcache-tools and bcache support in other linux packages

[Rolf Fokkens]

On 10/21/2013 06:47 PM, Piergiorgio Sartor wrote:


Interesting, then logic would suggest to (b)cache
the components of the RAID.
Of, even better, to (b)cache /dev/sd[ab] (in this
case) and cover, in this way, everything.
Well, I agree, there's more to it. Like cost. One could consider to pair 
serveral HHD' each with a dedicated bcache SSD. And from that one could 
build a RAID array. This RAID array has excellent (read) performance 
because of the combined SSD performance. This storage system does break 
when one of the HDD's or SDD's breaks, which is also a nice feature. So 
if it weren't for the cost (and the number of availbale SATA connectors) 
this could be interresting. But it's all a matter of requirements of course.

It's a desktop PC, I notice that performances
mainly depend on the storage subystem, the rest
(CPU, memory, GPU) is fine for me.


In my desktop PC I'm running singls SSD bcache on a RAID5 array. The 
performance is fine, and when the SSD breaks, well, I hope the FS on the 
HDD can be recovered. And if not? Well, it's only a desktop PC.


And when using multiple SSD's for reduncancy, the following article 
covers some interresting features in bcache:


http://www.linux.com/news/featured-blogs/200-libby-clark/728209-about-the-linux-kernel-bcache

Quote "Multiple SSDs will allow us to mirror dirty data and metadata, 
but not clean data - you get redundancy without wasting SSD space 
duplicating clean cached data".

--
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: communications and community [was Re: Lack of response about sponsorship]

[Bill Nottingham]

Kevin Fenzi (ke...@scrye.com) said: 
> > As a first step, I suggest clearing up the intended usage of "devel"
> > list. There's too much traffic on that list. 792 messages so far in
> > October. Even if one uses filtering, the recurring task of skimming
> > over the devel list folder is tiresome, since it's not the only list
> > one is subscribed to. Not even meetings logs are posted to
> > devel-announce list, however.
> 
> Good idea. What items could we move to announce that would be more
> useful for folks that don't have as much time/energy to skim the main
> list?
> 
> fesco meeting agenda/minutes? (note that this would be weekly, so
> increase the announce list a good deal)
> Any other things that would be better as announcements?

I would think that if we are in a situation where people who do development
don't subscribe to the devel list because of 'energy' reasons
(disillusionment, feelings of either a) pointlessness b) fait-accompli,
etc.), then just moving things to -announce is not actually solving the
problem.

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

Orphaning ghemical and related packages

[Carl Byington]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

ghemical
libghemical
liboglappth
mopac7
mpqc

I hope someone is able to pick them up.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAlJm7LYACgkQL6j7milTFsEY/ACbBCxTi5Z21XwHMIPOTPSMK/4I
ywsAoIEwfZ9J+r63sFe56r1u00TScDXi
=uTZg
-END PGP SIGNATURE-


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

Schedule for Wednesday's FESCo Meeting (2013-10-23)

[Kevin Fenzi]

Following is the list of topics that will be discussed in the FESCo
meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2013-10-23 18:00 UTC'

Links to all tickets below can be found at: 
https://fedorahosted.org/fesco/report/9

= Followups =

#topic ticket #1164 F20 Changes - Process on Changes Freeze
.fesco 1164

#topic ticket #1181 Fedora still vulnerable to BEAST
.fesco 1181

#topic ticket #1182 F21/F22 System Wide Change: Python 3
as the Default Implementation -
https://fedoraproject.org/wiki/Changes/Python_3_as_Default
.fesco 1182

#topic ticket #1170 Working Group call for Volunteers
.fesco 1170

= New business =

#topic ticket #1183 Don't enable prelink by default in Fedora
.fesco 1183

= Open Floor = 

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.

[signature.asc  application/pgp-signature (836 bytes)] 


signature.asc
Description: PGP signature
-- 
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: --Wl, -z, relro in LDFLAGS required?/Inconsistency when not using %configure

[Kevin Kofler]

Michael Schwendt wrote:
> Agreed. It's a trade-off. Guards aren't bad, but in this case their
> benefit is questionable. It probably doesn't work completely anyway, since
> if the build framework uses Autotools, there likely are no pregenerated
> Makefiles, and only a successful run on the configure script will generate
> them.

Well, the "exit" in the guard would fail the build even before that, whereas 
the "%configure || :" would just succeed if %configure succeeds, and then 
the subsequent "make" would run too. (That said, that's not necessarily a 
problem, it just makes the "|| :" redundant. Failing %configure would fail 
"make" too anyway, for the reason you describe.)

What the guard does not catch is if the package only ships configure.ac and 
expects you to run autoconf yourself, or if it uses CMake or some other 
configury tool. But then the "make" will likely fail anyway for the reason 
you describe.

Kevin Kofler

-- 
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: pycairo

[Zbigniew Jędrzejewski-Szmek]

On Sun, Oct 20, 2013 at 11:27:22AM +0800, Christopher Meng wrote:
> Hi list,
> 
> I'm building some packages which depend on the latest version of
> pycairo, and an inprogress feature also needs its
> rebuild(https://bugzilla.redhat.com/show_bug.cgi?id=1005447) as well.
> 
> However the version in Fedora hasn't been updated for more than a
> year, and also there is a name change request to change it to
> python-pycairo(https://bugzilla.redhat.com/show_bug.cgi?id=731891).
So, is this Review request still "live" and waiting for a reviewer,
or is is "dead", and waiting for a new prospective maintainer?
It would be great if the involved parties could provide some hints.

Zbyszek
-- 
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: pycairo

[Mathieu Bridon]

On Wed, 2013-10-23 at 05:21 +0200, Zbigniew Jędrzejewski-Szmek wrote:
> On Sun, Oct 20, 2013 at 11:27:22AM +0800, Christopher Meng wrote:
> > Hi list,
> > 
> > I'm building some packages which depend on the latest version of
> > pycairo, and an inprogress feature also needs its
> > rebuild(https://bugzilla.redhat.com/show_bug.cgi?id=1005447) as well.
> > 
> > However the version in Fedora hasn't been updated for more than a
> > year, and also there is a name change request to change it to
> > python-pycairo(https://bugzilla.redhat.com/show_bug.cgi?id=731891).
> So, is this Review request still "live" and waiting for a reviewer,
> or is is "dead", and waiting for a new prospective maintainer?
> It would be great if the involved parties could provide some hints.

Note that the package was renamed anyway, without waiting for the rename
review request to be completed:
http://pkgs.fedoraproject.org/cgit/pycairo.git/commit/?id=c700bd496bee56d8f0de03ef4d57a34d1a97bcf0


-- 
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

Re: pycairo

[Christopher Meng]

On Wed, Oct 23, 2013 at 11:21 AM, Zbigniew Jędrzejewski-Szmek
 wrote:
> So, is this Review request still "live" and waiting for a reviewer,
> or is is "dead", and waiting for a new prospective maintainer?
> It would be great if the involved parties could provide some hints.

Dead de facto. But it has many comaintainers. I hope we can finish
this review but unfortunately J5 is not working on this area now,
thusly we need someone else.

Essentially, this package should get an update first as the latest
version was released in 2011, then we can see if it's possible to
change its name. But now as name change bug has been posted for
years(from f15 era, then dup of this one), we should think about both
simultaneously.

All comaintainers of this package are not willing to do that:

https://admin.fedoraproject.org/pkgdb/acls/name/pycairo

alexl
caillon
caolanm
hadess
mclasen
rhughes
rstrode
ssp
xiphmont

This package is pretty old comparing with other distros, this is not
bleeding edge but really need an update. And if someone want to set
python3 as default interpreter, you will find Fedora doesn't have its
py3 version, which is also being required by at least these on py2.x
version:

bkchem
dogtail
gnome-activity-journal
gnome-desktop
graphite-web
gtg
icaro
labyrinth
lv2-fil-plugins
pitivi
pycairo-devel
pygobject3
pygtk2
python-cairosvg
python-matplotlib
python-pycha
python-xdot
yumex

So? I don't know.

I hope some people like rhughes/hadness(who is of course alive and has
commit acl, too) can update it. But I think my words are tiny.
--

Yours sincerely,
Christopher Meng

Fєdоґa ї₴ al$о a кїпd оf нaт lїкє Яёd Haт.

http://cicku.me
-- 
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: pycairo

[Christopher Meng]

On Wed, Oct 23, 2013 at 11:40 AM, Mathieu Bridon
 wrote:
> Note that the package was renamed anyway, without waiting for the rename
> review request to be completed:
> http://pkgs.fedoraproject.org/cgit/pycairo.git/commit/?id=c700bd496bee56d8f0de03ef4d57a34d1a97bcf0

And I would ask why he can do that without reviews?

http://fedoraproject.org/wiki/Package_Renaming_Process

Just because he is working at Red Hat and has such power inherited?
-- 
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: pycairo

[Mathieu Bridon]

On Wed, 2013-10-23 at 11:46 +0800, Christopher Meng wrote:
> On Wed, Oct 23, 2013 at 11:40 AM, Mathieu Bridon
>  wrote:
> > Note that the package was renamed anyway, without waiting for the rename
> > review request to be completed:
> > http://pkgs.fedoraproject.org/cgit/pycairo.git/commit/?id=c700bd496bee56d8f0de03ef4d57a34d1a97bcf0
> 
> And I would ask why he can do that without reviews?
> 
> http://fedoraproject.org/wiki/Package_Renaming_Process
> 
> Just because he is working at Red Hat and has such power inherited?

Or more likely, because I was wrong: the renaming was done in Git long
before the review request was opened.

So the more likely explanation is that Matthew (who renamed the package
in Git) didn't know about the process, and John tried to fix things up
by creating the review request when he realized it.

Remember: assume good faith and double check the dates (that last one is
for me) ;)


-- 
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

Re: Is rpmbuild reentrant?

[Petr Pisar]

On 2013-10-22, Neil Horman  wrote:
> On Tue, Oct 22, 2013 at 03:03:44PM +, Petr Pisar wrote:
>> Is it healty to execute rpmbuild while building a package?
>> 
>> I have tests for perl dependencency generator filters. I.e. the tests
>> build a package using rpmbuild with redefeined all the `_*dir' macros,
>> then use librpm to query requires and provides from built package, and
>> then do checks on the values.
>> 
>> I'm thinking how to plug the tests into Fedora. The simplest solution is
>> to run the tests in %check phase of a package (I don't know which one,
>> but it does not matter which one).
>> 
>> I've already heard warnings that calling rpm from package scriptlets is
>> not recommend.
>> 
>> What the situation with rpmbuild?
>> 
> I'm not sure how re-entrant-safe rpmbuild is, but doing the above seems a bit
> dodgy in general.  Could you instead package the test separately from the
> dependency generator rpm, make the latter depedent on the former, and then use
> chain-build in koji to build them at the same time?
>
Do you say to create a dummy package in Fedora? Package which itself has
dummy (possibly) unsatisfied dependencies? Package that ends up in
Fedora repositories? That's fishy.

-- Petr

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

[Test-Announce] 2013-10-23 @ 16:00 UTC - F20 Beta Blocker Bug Review #5

[Adam Williamson]

# F20 Beta Blocker Review meeting #5
# Date: 2013-10-23
# Time: 16:00 UTC (12:00 EDT, 09:00 PDT)
# Location: #fedora-blocker-review on irc.freenode.net

It's time for some more blocker review fun tomorrow, folks. Scheduled to
be the last one before Beta, but it's not looking that way :(

We'll be running through the final blockers and freeze exception bugs.
The current list is available at:
http://qa.fedoraproject.org/blockerbugs/current

We'll be reviewing the bugs to determine ...

1. Whether they meet the beta release criteria [1] and should stay on
the list
2. Whether they are getting the attention they need

[1] http://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria

For guidance on Blocker and FreezeException bugs, please refer to
  - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
  - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

For the blocker review meeting protocol, see
  -https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

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