Re: looking for co-maintainer / new owner

[Dan Mashal]

On Fri, Apr 19, 2013 at 9:12 AM, Nathanael D. Noblet  wrote:
> Hello,
>
>   The package barry is used to sync a blackberry device with a desktop. I
> took it over awhile ago when I owned a blackberry. I've since moved on to
> own various other devices and don't see myself returning to a blackberry
> anytime soon. As such I'm wondering if anyone wants to take ownership.
>
>   There is a semi-active upstream. They have new releases and a few
> community members contributing. A very responsive main developer - any
> issues we've had he's helped resolve and accepts patches readily. Its a low
> maintenance package by most accounts. I'll continue to maintain it if no one
> steps up for a little. If no one takes it I'll likely drop it around F20 or
> so.
>
> --
> Nathanael d. Noblet
> t 403.875.4613
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel


As a Blackberry owner of the 9930 and the Z10 I will be happy to help.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Alex G.]

On 04/19/2013 09:44 PM, Adam Williamson wrote:
> On 19/04/13 06:16 PM, Alex G. wrote:
>> On 04/15/2013 05:30 AM, Richard Hughes wrote:
>>> Is there any guidance as when to trim %changelog down to size? Some
>>> packages have thousands of lines of spec file dating back over 15
>>> years which seem kinda redundant now we're using git.
>>>
>>
>> I've always seen the %changelog as a relic from times when we didn't
>> have reliable source SCMs. For me, it is redundant (and boring) to have
>> to update the %changelog, while I have the exact same information in the
>> git history.
>>
>> I think the best way to go is to obsolete %changelog, and extract the
>> changelog directly from git history. I don't care as much about how far
>> back it should go. As far as knowing the package version (i.e. 1.2.3-6)
>> for each commit, that can easily be handled with a git hook.
>>
>> So, why bother putting similar information in two places when there are
>> better ways to go?
> 
> Thanks - I just won a small bet with myself as to when this thread would
> circle back to that discussion yet again...

I respectfully disagree with the assertion that the discussion is circular.
I might have been vague when I said "extract". What I meant was to
 - [have 'fedpkg build' automatically] create a changelog from the git
history
 - include that changelog in the rpm headers
 - the changelog is visible with 'rpm -q --changelog'.
Now both %changelog lovers and git lovers are happy campers.

Anyway, I see my argument will be going nowhere pretty soon.

Best wishes,
Alex
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Login to Koji

[Dennis Gilmore]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

El Thu, 18 Apr 2013 14:37:34 -0700 (PDT)
Ravindra Kumar  escribió:
> > We are adjusting anything that tells you you need to set this up. 
> > Where did you see it? From fedora-packager-setup? 
> 
> Yes. It generates a cert for browser and asks it to be imported
> in the browser.
> 
> BTW, fedora-packager-setup has not generated ~/.koji directory
> for me,
> https://fedoraproject.org/wiki/Using_the_Koji_build_system#Koji_Config
> 
> Hopefully, last problem is how do I specify proxy for koji commands?
> Does it not support proxies? I found this being asked earlier,
> http://www.redhat.com/archives/rhl-devel-list/2008-August/msg00667.html?
> 
> Thanks in advance,
> Ravindra

Koji doesnt support proxies. the ssl code opens sockets directly

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

iEYEARECAAYFAlFyEBYACgkQkSxm47BaWfer4ACgiru3VOZQ2DQxr4JSmFWmZF2u
gtwAn3bu/PoJReeIrXpZ/VyzPY335o0r
=4AjA
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Adam Williamson]

On 19/04/13 06:16 PM, Alex G. wrote:

On 04/15/2013 05:30 AM, Richard Hughes wrote:

Is there any guidance as when to trim %changelog down to size? Some
packages have thousands of lines of spec file dating back over 15
years which seem kinda redundant now we're using git.



I've always seen the %changelog as a relic from times when we didn't
have reliable source SCMs. For me, it is redundant (and boring) to have
to update the %changelog, while I have the exact same information in the
git history.

I think the best way to go is to obsolete %changelog, and extract the
changelog directly from git history. I don't care as much about how far
back it should go. As far as knowing the package version (i.e. 1.2.3-6)
for each commit, that can easily be handled with a git hook.

So, why bother putting similar information in two places when there are
better ways to go?


Thanks - I just won a small bet with myself as to when this thread would 
circle back to that discussion yet again...

--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Alex G.]

On 04/15/2013 05:30 AM, Richard Hughes wrote:
> Is there any guidance as when to trim %changelog down to size? Some
> packages have thousands of lines of spec file dating back over 15
> years which seem kinda redundant now we're using git.
> 

I've always seen the %changelog as a relic from times when we didn't
have reliable source SCMs. For me, it is redundant (and boring) to have
to update the %changelog, while I have the exact same information in the
git history.

I think the best way to go is to obsolete %changelog, and extract the
changelog directly from git history. I don't care as much about how far
back it should go. As far as knowing the package version (i.e. 1.2.3-6)
for each commit, that can easily be handled with a git hook.

So, why bother putting similar information in two places when there are
better ways to go?

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

Re: Trimming (or obsoleting) %changelog?

[Toshio Kuratomi]

On Fri, Apr 19, 2013 at 12:51:05PM -0700, Adam Williamson wrote:
> On 19/04/13 10:18 AM, Ralf Corsepius wrote:
> 
> >Last time, we've had this kind of discussions, people were claiming they
> >were querying changelogs from _binary_ rpms and from installed rpms (rpm
> >-q --changelog)
> 
> I do that. All the time. Sometimes going back a long, long time.
> 
> I could certainly work around the limitation if the binary RPM
> changelogs were cut off, but it would require me to change, if anyone
> cares.

Is there a cutoff date that would cover maybe 90% of your use cases?  I
think that one year would be too short for my use cases as well.  But there
are packages in the distro with changelogs going back to the RHL/fedora.us
days and I personally never go back even half that far.  If we chose a date
two years or three years or even four years in the past, it might be a
reasonable compromise for everyone.

-Toshio


pgpvzCAe3t65N.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Another UEFI testing request

[Adam Williamson]

On 19/04/13 01:50 PM, Chris Adams wrote:

Once upon a time, Chris Adams  said:

The system is a Zotac Zbox nano AD10.  I downloaded the image from the
above URL and put it on an SD card and did a UEFI boot.  I don't have
anything current on the drive, so I chose not to preserve anything.  I
tried a minimal install; no problems up to the bootloader, which gave me
an "unknown error".


I had time to try this again (if it still matters).  When installing the
bootloader failed, I switched over to a console and poked around.  I do
see this in the /tmp/anaconda-tb-xxx file (I assume this is the
problem):

20:27:54,549 WARNING kernel:[ 2404.617141] efivars: set_variable() failed: 
status=8009

This is with the Alpha-TC5 netinst boot image (installer kernel
3.9.0-0.rc4.git10.1.fc19.x86_64), using a local mirror of current
development/19 and updates/testing/19.

I am running the latest BIOS on my Zbox.


Hi, Chris. Testing should be with RC3 or RC4 - I'm still interested in 
the results, though we signed off on Alpha already. Thanks!


There are still likely to be some failures even with RC4 (bronze): 
https://bugzilla.redhat.com/show_bug.cgi?id=949786#c28 explains why, and 
why we're not holding Alpha any longer.

--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Another UEFI testing request

[Chris Adams]

Once upon a time, Chris Adams  said:
> The system is a Zotac Zbox nano AD10.  I downloaded the image from the
> above URL and put it on an SD card and did a UEFI boot.  I don't have
> anything current on the drive, so I chose not to preserve anything.  I
> tried a minimal install; no problems up to the bootloader, which gave me
> an "unknown error".

I had time to try this again (if it still matters).  When installing the
bootloader failed, I switched over to a console and poked around.  I do
see this in the /tmp/anaconda-tb-xxx file (I assume this is the
problem):

20:27:54,549 WARNING kernel:[ 2404.617141] efivars: set_variable() failed: 
status=8009

This is with the Alpha-TC5 netinst boot image (installer kernel
3.9.0-0.rc4.git10.1.fc19.x86_64), using a local mirror of current
development/19 and updates/testing/19.

I am running the latest BIOS on my Zbox.
-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Review swap

[Lokesh Mandvekar]

On Fri, Apr 19, 2013 at 02:20:32PM -0400, Rahul Sundaram wrote:
> Hi
> 
> 
> On Fri, Apr 19, 2013 at 5:44 AM, Lokesh Mandvekar  wrote:
> 
> > T.C.: thanks for the reviews. And I didn't know the fedora-review tool
> > existed. I'll review the first 2 for sure, perhaps all 4 (now that I know
> > fedora-review makes it so easy)
> >
> 
> It is probably less advertised than it should be. I have added a note to
> 
> https://fedoraproject.org/wiki/Package_Review_Process
> 
> Rahul

Thanks, Rahul.

Rahul, T.C. and others: If possible, I'd appreciate feedback on the review I 
did for
https://bugzilla.redhat.com/show_bug.cgi?id=921847 .


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

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

Re: Trimming (or obsoleting) %changelog?

[Adam Williamson]

On 19/04/13 10:18 AM, Ralf Corsepius wrote:


Last time, we've had this kind of discussions, people were claiming they
were querying changelogs from _binary_ rpms and from installed rpms (rpm
-q --changelog)


I do that. All the time. Sometimes going back a long, long time.

I could certainly work around the limitation if the binary RPM 
changelogs were cut off, but it would require me to change, if anyone cares.

--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Appropriate location for cmake support files

[Mario Ceresa]

Thanks Rex and Orion for the response!

Mario

On 18 April 2013 22:44, Orion Poplawski  wrote:
> On 04/18/2013 02:23 PM, Rex Dieter wrote:
>>
>> Mario Ceresa wrote:
>>
>>> Hi all,
>>> does anybody know where should I put cmake support files such as:
>>>
>>> OpenIGTLinkBuildSettings.cmake
>>> OpenIGTLinkConfig.cmake
>>> UseOpenIGTLink.cmake
>>>
>>> in order for cmake to find them automatically? Can I put them in
>>> /usr/share/cmake/Modules/ ?
>>>
>>> I read a lot of tutorials on how cmake's find_package works, but I'm
>>> still a bit confused... Maybe there is a packaging guideline somewhere
>>> and I missed it?
>>
>>
>> Under something like %_datadir/cmake/ or %_libdir/cmake/
>> depending
>> on if this is arch-specific or not (I'm guessing yes, so most often the
>> latter)
>>
>> -- rex
>>
>
> Where  is probably %{name}.  There probably should be a guideline for
> this somewhere, but hopefully projects will install them in the proper
> place.
>
>
> --
> Orion Poplawski
> Technical Manager 303-415-9701 x222
> NWRA, Boulder/CoRA Office FAX: 303-415-9702
> 3380 Mitchell Lane   or...@nwra.com
> Boulder, CO 80301   http://www.nwra.com
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Login to Koji

[Ralph Bean]

On Fri, Apr 19, 2013 at 07:51:37PM +0200, Thomas Moschny wrote:
> 2013/4/19 Kevin Fenzi :
> > It's true that you cannot do that from the command line interface.
> >
> > However, there's a bunch of other ways to get that info:
> >
> > - Subscribe to the koji recent builds rss feed:
> > http://koji.fedoraproject.org/koji/recentbuilds
> > and alert on whatever builds you care about.
> >
> > - Join the #fedora-fedmsg channel on irc and setup notify for whatever
> >   packages you care about and what part of the build (since it will
> >   send a message on build start, build end, success or failure, tagging
> >   into tag, etc).
> >
> > - Setup fedmsg-notify on your desktop and set it to look for the same
> >   above messages.
> >
> > - Setup your own fedmsg consumer to look for the messages and do
> >   whatever you want on getting them. email you?
> >
> > IMHO we should really move to using fedmsg for these things instead of
> > a non standard difficult interface in a specific app. ;)
> 
> Agreed in principle. On the other hand, all these possible solutions
> require something running on my side permanently :(

In theory, the infrastructure team could build a webapp that:

1) Allows you to manage centralized notification preferences.
2) Listens to the bus and sends emails as appropriate.

It could be cool.  We could host it at, say,
apps.fedoraproject.org/busmail.

I've created a ticket to track it as an idea.  If you're interested in
having such a thing around, please chime in there with a :+1: and any
special requirements:
https://github.com/fedora-infra/fedmsg/issues/134


pgpmINkKm2LvI.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Retina 13" Macbook pro and fedora19

[Adam Williamson]

On 19/04/13 06:54 AM, Joseph Marrero wrote:

Fedora 19 boots ok and the installer opens,
but as soon The installation starts and Anaconda tries to mount the efi
partition it crashes. Saying the efi partition can not be mounted.


You should have an option to report the crash to Bugzilla. Can you 
please do that? Thanks!

--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Review swap

[Rahul Sundaram]

Hi


On Fri, Apr 19, 2013 at 5:44 AM, Lokesh Mandvekar  wrote:

> T.C.: thanks for the reviews. And I didn't know the fedora-review tool
> existed. I'll review the first 2 for sure, perhaps all 4 (now that I know
> fedora-review makes it so easy)
>

It is probably less advertised than it should be. I have added a note to

https://fedoraproject.org/wiki/Package_Review_Process

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

Re: Login to Koji

[Thomas Moschny]

2013/4/19 Kevin Fenzi :
> It's true that you cannot do that from the command line interface.
>
> However, there's a bunch of other ways to get that info:
>
> - Subscribe to the koji recent builds rss feed:
> http://koji.fedoraproject.org/koji/recentbuilds
> and alert on whatever builds you care about.
>
> - Join the #fedora-fedmsg channel on irc and setup notify for whatever
>   packages you care about and what part of the build (since it will
>   send a message on build start, build end, success or failure, tagging
>   into tag, etc).
>
> - Setup fedmsg-notify on your desktop and set it to look for the same
>   above messages.
>
> - Setup your own fedmsg consumer to look for the messages and do
>   whatever you want on getting them. email you?
>
> IMHO we should really move to using fedmsg for these things instead of
> a non standard difficult interface in a specific app. ;)

Agreed in principle. On the other hand, all these possible solutions
require something running on my side permanently :(

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

Re: Trimming (or obsoleting) %changelog?

[Chris Adams]

Once upon a time, Ralf Corsepius  said:
> Last time, we've had this kind of discussions, people were claiming they 
> were querying changelogs from _binary_ rpms and from installed rpms (rpm 
> -q --changelog)

_This_ time, I've said I do that, especially when looking for CVE and
other security fixes.
-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Login to Koji

[Ralph Bean]

On Fri, Apr 19, 2013 at 11:37:16AM -0600, Kevin Fenzi wrote:
> - Setup your own fedmsg consumer to look for the messages and do
>   whatever you want on getting them. email you? 

If you want help doing this, feel free to ask in #fedora-apps on
freenode.

http://www.fedmsg.com/en/latest/consuming/#naive-consuming


pgpamTmiWIXnX.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Christopher Meng]

On Sat, Apr 20, 2013 at 12:25 AM, Richard W.M. Jones 
 wrote:

I have just tested this by adding it to a random package that I
maintain, and it appears to work.

The changelog in the RPM I just built is trimmed to 1 year, even
though the spec file contains a much longer changelog.

One possible problem -- maybe it's not -- is that the generated
.src.rpm changelog also gets truncated, but the spec file inside is
intact.



Do we have an option for trimming by releases ? Maybe in the last 1 
year one package just has changelog of Fedora xx Mass Rebuilding...In 
this case, what should we do?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Login to Koji

[Kevin Fenzi]

On Fri, 19 Apr 2013 11:46:56 +0200
Thomas Moschny  wrote:

> Almost everything can be done using the koji command line, but one
> thing I couldn't find: Koji's web interface let me "create a
> notification", so I get notified whenever a selected package is build
> (optionally selecting a tag, and optionally on success only).
> 
> How can I add/modify/remove such notification subscriptions without
> the web interface?

It's true that you cannot do that from the command line interface. 

However, there's a bunch of other ways to get that info:

- Subscribe to the koji recent builds rss feed: 
http://koji.fedoraproject.org/koji/recentbuilds
and alert on whatever builds you care about. 

- Join the #fedora-fedmsg channel on irc and setup notify for whatever
  packages you care about and what part of the build (since it will
  send a message on build start, build end, success or failure, tagging
  into tag, etc). 

- Setup fedmsg-notify on your desktop and set it to look for the same
  above messages. 

- Setup your own fedmsg consumer to look for the messages and do
  whatever you want on getting them. email you? 

IMHO we should really move to using fedmsg for these things instead of
a non standard difficult interface in a specific app. ;) 

kevin



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

Re: Login to Koji

[Kevin Fenzi]

On Fri, 19 Apr 2013 10:36:16 +0800
Mathieu Bridon  wrote:

> The Koji web interface still has a "login" button, maybe it should be
> removed completely?

Perhaps so. 

kevin



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

Re: Login to Koji

[Kevin Fenzi]

On Thu, 18 Apr 2013 14:37:34 -0700 (PDT)
Ravindra Kumar  wrote:

> > We are adjusting anything that tells you you need to set this up. 
> > Where did you see it? From fedora-packager-setup? 
> 
> Yes. It generates a cert for browser and asks it to be imported
> in the browser.

Yeah, soon it will stop doing that. ;) 

> BTW, fedora-packager-setup has not generated ~/.koji directory
> for me,
> https://fedoraproject.org/wiki/Using_the_Koji_build_system#Koji_Config

You don't need one. I fixed the wiki page. ;) 

> Hopefully, last problem is how do I specify proxy for koji commands?
> Does it not support proxies? I found this being asked earlier,
> http://www.redhat.com/archives/rhl-devel-list/2008-August/msg00667.html?

I think it uses the normal http_proxy and https_proxy env variables... 

kevin





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

Re: Trimming (or obsoleting) %changelog?

[Ralf Corsepius]

On 04/19/2013 06:57 PM, Tom Callaway wrote:

On 04/19/2013 12:25 PM, Richard W.M. Jones wrote:

On Fri, Apr 19, 2013 at 11:17:09AM -0400, Tom Callaway wrote:

On 04/18/2013 11:34 AM, Richard W.M. Jones wrote:

%global _changelog_trimtime %(date +%s -d "1 year ago")


If that actually works, we could make fedpkg set it.


I have just tested this by adding it to a random package that I
maintain, and it appears to work.

The changelog in the RPM I just built is trimmed to 1 year, even
though the spec file contains a much longer changelog.

One possible problem -- maybe it's not -- is that the generated
.src.rpm changelog also gets truncated, but the spec file inside is
intact.


If the spec file is intact, that should be sufficient. I don't think
people are regularly querying changelog info from SRPMs.


Last time, we've had this kind of discussions, people were claiming they 
were querying changelogs from _binary_ rpms and from installed rpms (rpm 
-q --changelog)


Ralf


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

Re: Package-split upgrade path

[Sandro Mani]

On 19.04.2013 17:58, Rex Dieter wrote:

Sandro Mani wrote:


Hello,

In python-pillow (the python imaging fork which replaced PIL in F19+),
there is a module (ImageQt) which requires PyQt4, but that dependency is
missing in python-pillow (and in python-imaging before). I don't really
like adding PyQt4 as a dependency to the main package, since it pulls in
lots of stuff. So, I'd go for creating a python-pillow-qt subpackage
(albeit with just one file), and now am wondering about the upgrade
path. From what I can see, there is just one package which uses the
ImageQt module (pony, which actually looks to be rather unmaintained).
Question: What is the best way to proceed?

make python-pillow-qt include

Obsoletes: python-pillow <  #last_EVR_before_qt_subpkg_existed#
Requires: python-pillow = %{version}-%{release}


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

Re: Trimming (or obsoleting) %changelog?

[Tom Callaway]

On 04/19/2013 12:25 PM, Richard W.M. Jones wrote:
> On Fri, Apr 19, 2013 at 11:17:09AM -0400, Tom Callaway wrote:
>> On 04/18/2013 11:34 AM, Richard W.M. Jones wrote:
>>> %global _changelog_trimtime %(date +%s -d "1 year ago")
>>
>> If that actually works, we could make fedpkg set it.
> 
> I have just tested this by adding it to a random package that I
> maintain, and it appears to work.
> 
> The changelog in the RPM I just built is trimmed to 1 year, even
> though the spec file contains a much longer changelog.
> 
> One possible problem -- maybe it's not -- is that the generated
> .src.rpm changelog also gets truncated, but the spec file inside is
> intact.

If the spec file is intact, that should be sufficient. I don't think
people are regularly querying changelog info from SRPMs.

~tom

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

[perl-boolean/f18] (2 commits) ...update to 0.30

[Iain Arnell]

Summary of changes:

  a4b3654... - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass (*)
  7e028ee... update to 0.30 (*)

(*) This commit already existed in another branch; no separate mail sent
--
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

[perl-boolean/f19] update to 0.30

[Iain Arnell]

Summary of changes:

  7e028ee... update to 0.30 (*)

(*) This commit already existed in another branch; no separate mail sent
--
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

[perl-boolean] update to 0.30

[Iain Arnell]

commit 7e028ee68b15e93785274d09ed8f4c864b53927a
Author: Iain Arnell 
Date:   Fri Apr 19 10:29:18 2013 -0600

update to 0.30

 .gitignore|1 +
 perl-boolean.spec |   10 +++---
 sources   |2 +-
 3 files changed, 9 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 7c1adce..4c2c850 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,3 +4,4 @@ boolean-0.20.tar.gz
 /boolean-0.26.tar.gz
 /boolean-0.27.tar.gz
 /boolean-0.28.tar.gz
+/boolean-0.30.tar.gz
diff --git a/perl-boolean.spec b/perl-boolean.spec
index 11312a6..4afaca8 100644
--- a/perl-boolean.spec
+++ b/perl-boolean.spec
@@ -1,6 +1,6 @@
 Name:   perl-boolean
-Version:0.28
-Release:5%{?dist}
+Version:0.30
+Release:1%{?dist}
 Summary:Boolean support for Perl
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -9,6 +9,7 @@ Source0:
http://www.cpan.org/authors/id/I/IN/INGY/boolean-%{version}.tar.
 BuildArch:  noarch
 BuildRequires:  perl >= 0:5.005003
 BuildRequires:  perl(ExtUtils::MakeMaker)
+BuildRequires:  perl(JSON)
 BuildRequires:  perl(Readonly)
 BuildRequires:  perl(Test::More)
 Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
@@ -25,7 +26,7 @@ Most programming languages have a native Boolean data type. 
Perl does not.
 make %{?_smp_mflags}
 
 %install
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+make pure_install DESTDIR=$RPM_BUILD_ROOT
 
 find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
 find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;
@@ -41,6 +42,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Fri Apr 19 2013 Iain Arnell  0.30-1
+- update to latest upstream version
+
 * Thu Feb 14 2013 Fedora Release Engineering  
- 0.28-5
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
 
diff --git a/sources b/sources
index 0efee68..f0507ab 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-488916ac0aa8be172460e896a8a9977a  boolean-0.28.tar.gz
+f4f23302481e82402048a91a8fa2e078  boolean-0.30.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: Review Request 18: Add cgit link to Main Page

[Tim Flink]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard-tflink.rhcloud.com/r/18/#review24
---


I think that it would be good to put the link in the global footer - I get 
asked where the source lives on a semi-regular basis and it might be good to 
make that more obvious :)

Sorry for the delay on this, should have done it a while ago.


blockerbugs/templates/index.html


Why limit this to just the index page instead of adding it to the global 
footer?



blockerbugs/templates/index.html


How about something like: "This application is open source! Get the code 
(with embedded link to cgit) or look at development plans (with link to 
fedora-qa trac report 10)"?



sass/app.scss


If you change the scss, you need to regenerate the css using compass as 
well.



sass/app.scss


What's the advantage to greying this out instead of using the link colors 
that we're using elsewhere in the app?


- Tim Flink


On March 13, 2013, 11:21 a.m., Martin Krizek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard-tflink.rhcloud.com/r/18/
> ---
> 
> (Updated March 13, 2013, 11:21 a.m.)
> 
> 
> Review request for blockerbugs.
> 
> 
> Bugs: 343
> https://fedorahosted.org/fedora-qa/ticket/343
> 
> 
> Repository: blockerbugs
> 
> 
> Description
> ---
> 
> This is maybe trivial to have a review for but two things might be discussed:
> 1. do we want to show the link just on index or on all pages?
> 2. is the wording of the link ok?
> 
> 
> Diffs
> -
> 
>   sass/app.scss 1a4369d0911b77fc411089de0b05c8d5c80e304f 
>   blockerbugs/templates/index.html 088962bfcb16c3f0d163366f2235fc557e0d45dc 
> 
> Diff: http://reviewboard-tflink.rhcloud.com/r/18/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Krizek
> 
>

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

Re: Trimming (or obsoleting) %changelog?

[Richard W.M. Jones]

On Fri, Apr 19, 2013 at 11:17:09AM -0400, Tom Callaway wrote:
> On 04/18/2013 11:34 AM, Richard W.M. Jones wrote:
> > %global _changelog_trimtime %(date +%s -d "1 year ago")
> 
> If that actually works, we could make fedpkg set it.

I have just tested this by adding it to a random package that I
maintain, and it appears to work.

The changelog in the RPM I just built is trimmed to 1 year, even
though the spec file contains a much longer changelog.

One possible problem -- maybe it's not -- is that the generated
.src.rpm changelog also gets truncated, but the spec file inside is
intact.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Review Request 20: Rework Logging Mechanisms

[Tim Flink]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard-tflink.rhcloud.com/r/20/
---

(Updated April 19, 2013, 4:12 p.m.)


Status
--

This change has been marked as submitted.


Review request for blockerbugs.


Bugs: 374
https://fedorahosted.org/fedora-qa/ticket/374


Repository: blockerbugs


Description
---

This is code to rework logging mechanisms for fedora-infra standards. It 
changed a bit from martin's original code, so I'm creating a new review request.


Diffs
-

  sass/app.scss 0f81cbd6d740ff7325ec080c5ccb33ecf642e0b7 
  conf/settings.py.example 7c45c785fa05c12f2c36f2ca06b99bcd41b318ce 
  conf/blockerbugs.cron.example ddfe8f5661854e76887cd727f187f219c80ffdae 
  blockerbugs/util/update_sync.py 9c46ffc7b3c2f07a73c899165044059447858a48 
  blockerbugs/util/bz_interface.py 7dedce924c2f96110ed98bd311b870e03e617887 
  blockerbugs/util/bug_sync.py 6e092aa35c04ec9a7a4b03653fddf2cef27e4ba1 
  blockerbugs/templates/thanks.html f5432900daae6af4d22b3e5abbbc7092df868c4a 
  blockerbugs/templates/layout.html a0b5ebda3ff61a3fa2647d96ef77037ed0d729d2 
  blockerbugs/static/img/repeater-stg.png 
24c56fd10da38d7d6f8a3f684a811bc4b04b56a4 
  blockerbugs/static/img/blockerbugs-logo-light-stg.png 
b94f3891dd4726eac435c8a03c2ac0a2daafef39 
  blockerbugs/static/css/app.css 26e177c1e5c7cec716db5b2bcd428bb4e6a92505 
  blockerbugs/static/css/app-foundation.css 
852272bf1bd1c629b30933b451daceec31812de7 
  blockerbugs/config.py cecca7c88ef25ee9fd81df0cd2aeb2f84030559f 
  blockerbugs/cli.py 5cfc306a9051555ad972fd05c627f906d3b2 
  blockerbugs/__init__.py aebfe96cc9268f6bbeab3d0bb0c9ae3a4218986b 
  blockerbugs.spec 012e980b5d0cf57c09bd9f993b6c21d29c5cc3d8 

Diff: http://reviewboard-tflink.rhcloud.com/r/20/diff/


Testing
---

local and dev VM testing, currently running on 
qa.stg.fedoraproject.org/blockerbugs/ - no issues noticed thus far


Thanks,

Tim Flink

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

looking for co-maintainer / new owner

[Nathanael D. Noblet]

Hello,

  The package barry is used to sync a blackberry device with a desktop. 
I took it over awhile ago when I owned a blackberry. I've since moved on 
to own various other devices and don't see myself returning to a 
blackberry anytime soon. As such I'm wondering if anyone wants to take 
ownership.


  There is a semi-active upstream. They have new releases and a few 
community members contributing. A very responsive main developer - any 
issues we've had he's helped resolve and accepts patches readily. Its a 
low maintenance package by most accounts. I'll continue to maintain it 
if no one steps up for a little. If no one takes it I'll likely drop it 
around F20 or so.


--
Nathanael d. Noblet
t 403.875.4613
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Package-split upgrade path

[Rex Dieter]

Sandro Mani wrote:

> Hello,
> 
> In python-pillow (the python imaging fork which replaced PIL in F19+),
> there is a module (ImageQt) which requires PyQt4, but that dependency is
> missing in python-pillow (and in python-imaging before). I don't really
> like adding PyQt4 as a dependency to the main package, since it pulls in
> lots of stuff. So, I'd go for creating a python-pillow-qt subpackage
> (albeit with just one file), and now am wondering about the upgrade
> path. From what I can see, there is just one package which uses the
> ImageQt module (pony, which actually looks to be rather unmaintained).
> Question: What is the best way to proceed?

make python-pillow-qt include

Obsoletes: python-pillow <  #last_EVR_before_qt_subpkg_existed#
Requires: python-pillow = %{version}-%{release}

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

Re: Trimming (or obsoleting) %changelog?

[Tom Callaway]

On 04/18/2013 11:34 AM, Richard W.M. Jones wrote:
> %global _changelog_trimtime %(date +%s -d "1 year ago")

If that actually works, we could make fedpkg set it.

~tom

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

Retina 13" Macbook pro and fedora19

[Joseph Marrero]

Fedora 19 boots ok and the installer opens,
but as soon The installation starts and Anaconda tries to mount the efi
partition it crashes. Saying the efi partition can not be mounted.

I selected automatic partitions and it created / /home /boot and /boot/efi
I deleted /home and left
/ /boot /boot/efipartitions

In Fedora 18 the installation is OK.

I created the USB-bootable drive using
dd if=~/Fedora-Live-KDE-x86_64-19-Alpha-1.iso of=/dev/disk1
 under OS X for both f18 and f19.

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

F-19 Branched report: 20130419 changes

[Fedora Branched Report]

Compose started at Fri Apr 19 09:15:21 UTC 2013

Broken deps for x86_64
--
[aeolus-conductor]
aeolus-conductor-0.10.6-2.fc19.noarch requires ruby(abi) = 0:1.9.1
[alexandria]
alexandria-0.6.9-4.fc19.noarch requires ruby(abi) >= 0:1.9.1
[amide]
amide-1.0.0-4.fc19.x86_64 requires libvolpack.so.1()(64bit)
[clementine]
clementine-1.1.1-1.fc19.x86_64 requires libprotobuf.so.7()(64bit)
clementine-1.1.1-1.fc19.x86_64 requires libimobiledevice.so.3()(64bit)
[connman]
connman-1.5-4.fc19.i686 requires libxtables.so.7
connman-1.5-4.fc19.i686 requires libgnutls.so.26(GNUTLS_1_4)
connman-1.5-4.fc19.i686 requires libgnutls.so.26
connman-1.5-4.fc19.x86_64 requires libxtables.so.7()(64bit)
connman-1.5-4.fc19.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit)
connman-1.5-4.fc19.x86_64 requires libgnutls.so.26()(64bit)
[deltacloud-core]
deltacloud-core-1.0.5-2.fc19.noarch requires ruby(abi) = 0:1.9.1
[denemo]
denemo-0.9.4-0.fc18.x86_64 requires libgtksourceview-3.0.so.0()(64bit)
[dragonegg]
dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19
[eruby]
eruby-1.0.5-19.fc18.x86_64 requires libruby.so.1.9()(64bit)
eruby-libs-1.0.5-19.fc18.i686 requires ruby(abi) >= 0:1.9.0
eruby-libs-1.0.5-19.fc18.i686 requires libruby.so.1.9
eruby-libs-1.0.5-19.fc18.x86_64 requires ruby(abi) >= 0:1.9.0
eruby-libs-1.0.5-19.fc18.x86_64 requires libruby.so.1.9()(64bit)
[fawkes]
fawkes-firevision-0.5.0-5.fc19.i686 requires libjpeg.so.8(LIBJPEG_8.0)
fawkes-firevision-0.5.0-5.fc19.i686 requires libjpeg.so.8
fawkes-firevision-0.5.0-5.fc19.x86_64 requires 
libjpeg.so.8(LIBJPEG_8.0)(64bit)
fawkes-firevision-0.5.0-5.fc19.x86_64 requires libjpeg.so.8()(64bit)
fawkes-guis-0.5.0-5.fc19.i686 requires libgraph.so.5
fawkes-guis-0.5.0-5.fc19.x86_64 requires libgraph.so.5()(64bit)
fawkes-plugin-clips-0.5.0-5.fc19.i686 requires libclipsmm.so.2
fawkes-plugin-clips-0.5.0-5.fc19.x86_64 requires 
libclipsmm.so.2()(64bit)
fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires 
libgeos-3.3.6.so()(64bit)
fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires 
libboost_thread-mt.so.1.50.0()(64bit)
fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires 
libboost_system-mt.so.1.50.0()(64bit)
fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires 
libboost_signals-mt.so.1.50.0()(64bit)
fawkes-plugin-tabletop-objects-0.5.0-5.fc19.x86_64 requires 
libboost_thread-mt.so.1.50.0()(64bit)
fawkes-plugin-tabletop-objects-0.5.0-5.fc19.x86_64 requires 
libboost_system-mt.so.1.50.0()(64bit)
[flowcanvas]
flowcanvas-0.7.1-8.fc18.i686 requires libgraph.so.5
flowcanvas-0.7.1-8.fc18.x86_64 requires libgraph.so.5()(64bit)
[gcc-python-plugin]
gcc-python2-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 
0:4.7.2-8.fc19
gcc-python2-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19
gcc-python3-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 
0:4.7.2-8.fc19
gcc-python3-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19
[gdcm]
gdcm-2.0.18-6.fc18.i686 requires libpoppler.so.26
gdcm-2.0.18-6.fc18.x86_64 requires libpoppler.so.26()(64bit)
[gearbox]
gearbox-10.11-3.fc19.i686 requires libIceUtil.so.35b
gearbox-10.11-3.fc19.x86_64 requires libIceUtil.so.35b()(64bit)
[gnome-applets]
1:gnome-applets-3.5.92-3.fc18.x86_64 requires 
libgweather-3.so.1()(64bit)
[gnome-panel]
gnome-panel-3.6.2-6.fc19.x86_64 requires 
libgnome-desktop-3.so.5()(64bit)
gnome-panel-devel-3.6.2-6.fc19.i686 requires libgnome-desktop-3.so.5
gnome-panel-devel-3.6.2-6.fc19.x86_64 requires 
libgnome-desktop-3.so.5()(64bit)
[gnome-pie]
gnome-pie-0.5.3-3.20120826git1b93e1.fc19.x86_64 requires 
libbamf3.so.0()(64bit)
[gnomint]
gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26(GNUTLS_2_8)(64bit)
gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit)
gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26()(64bit)
[gooddata-cl]
gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java
[gorm]
gorm-1.2.18-1.fc19.i686 requires libgnustep-gui.so.0.22
gorm-1.2.18-1.fc19.x86_64 requires libgnustep-gui.so.0.22()(64bit)
[kawa]
1:kawa-1.11-5.fc19.x86_64 requires servlet25
[libkolab]
php-kolab-0.4.1-3.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64
php-kolab-0.4.1-3.fc19.x86_64 requires php(api) = 0:20100412-x86-64
[matreshka]
matreshka-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
matreshka-amf-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-amf-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
matreshka-amf-mofext-0.3.0-3.fc19.i68

rawhide report: 20130419 changes

[Fedora Rawhide Report]

Compose started at Fri Apr 19 08:15:25 UTC 2013

Broken deps for x86_64
--
[3Depict]
3Depict-0.0.12-4.fc20.x86_64 requires libmgl.so.5()(64bit)
[aeolus-conductor]
aeolus-conductor-0.10.6-2.fc19.noarch requires ruby(abi) = 0:1.9.1
[amide]
amide-1.0.0-4.fc19.x86_64 requires libvolpack.so.1()(64bit)
[clementine]
clementine-1.1.1-1.fc19.x86_64 requires libprotobuf.so.7()(64bit)
clementine-1.1.1-1.fc19.x86_64 requires libimobiledevice.so.3()(64bit)
[connman]
connman-1.5-4.fc19.i686 requires libxtables.so.7
connman-1.5-4.fc19.i686 requires libgnutls.so.26(GNUTLS_1_4)
connman-1.5-4.fc19.i686 requires libgnutls.so.26
connman-1.5-4.fc19.x86_64 requires libxtables.so.7()(64bit)
connman-1.5-4.fc19.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit)
connman-1.5-4.fc19.x86_64 requires libgnutls.so.26()(64bit)
[deltacloud-core]
deltacloud-core-1.0.5-2.fc19.noarch requires ruby(abi) = 0:1.9.1
[dragonegg]
dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19
[eg]
eg-1.7.5.2-1.fc20.noarch requires perl(one)
eg-1.7.5.2-1.fc20.noarch requires perl(it)
eg-1.7.5.2-1.fc20.noarch requires perl(an)
[flowcanvas]
flowcanvas-0.7.1-8.fc18.i686 requires libgraph.so.5
flowcanvas-0.7.1-8.fc18.x86_64 requires libgraph.so.5()(64bit)
[gcc-python-plugin]
gcc-python2-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 
0:4.7.2-8.fc19
gcc-python2-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19
gcc-python3-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 
0:4.7.2-8.fc19
gcc-python3-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19
[gnome-applets]
1:gnome-applets-3.5.92-3.fc18.x86_64 requires 
libgweather-3.so.1()(64bit)
[gnome-panel]
gnome-panel-3.6.2-6.fc19.x86_64 requires 
libgnome-desktop-3.so.5()(64bit)
gnome-panel-devel-3.6.2-6.fc19.i686 requires libgnome-desktop-3.so.5
gnome-panel-devel-3.6.2-6.fc19.x86_64 requires 
libgnome-desktop-3.so.5()(64bit)
[gnome-pie]
gnome-pie-0.5.3-3.20120826git1b93e1.fc19.x86_64 requires 
libbamf3.so.0()(64bit)
[gnomint]
gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26(GNUTLS_2_8)(64bit)
gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit)
gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26()(64bit)
[gooddata-cl]
gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java
[kawa]
1:kawa-1.11-5.fc19.x86_64 requires servlet25
[libkolab]
php-kolab-0.4.1-3.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64
php-kolab-0.4.1-3.fc19.x86_64 requires php(api) = 0:20100412-x86-64
[mapserver]
php-mapserver-6.0.3-9.fc19.x86_64 requires php(zend-abi) = 
0:20100525-x86-64
php-mapserver-6.0.3-9.fc19.x86_64 requires php(api) = 0:20100412-x86-64
[matreshka]
matreshka-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
matreshka-amf-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-amf-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
matreshka-amf-mofext-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-amf-mofext-0.3.0-3.fc19.x86_64 requires 
libgnat-4.7.so()(64bit)
matreshka-amf-ocl-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-amf-ocl-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
matreshka-amf-uml-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-amf-uml-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
matreshka-amf-utp-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-amf-utp-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
matreshka-fastcgi-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-fastcgi-0.3.0-3.fc19.i686 requires libgnarl-4.7.so
matreshka-fastcgi-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
matreshka-fastcgi-0.3.0-3.fc19.x86_64 requires libgnarl-4.7.so()(64bit)
matreshka-sql-core-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-sql-core-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
matreshka-sql-postgresql-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-sql-postgresql-0.3.0-3.fc19.x86_64 requires 
libgnat-4.7.so()(64bit)
matreshka-sql-sqlite-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-sql-sqlite-0.3.0-3.fc19.x86_64 requires 
libgnat-4.7.so()(64bit)
matreshka-xml-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-xml-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
[mygui]
mygui-3.2.0-4.fc20.i686 requires libCommon.so
mygui-3.2.0-4.fc20.x86_64 requires libCommon.so()(64bit)
mygui-demos-3.2.0-4.fc20.x86_64 requires libCommon.so()(64bit)
mygui-tools-3.2.0-4.fc20.x86_64 requires libCommon.so()(64bit)
[nightv

Re: Login to Koji

[Thomas Moschny]

2013/4/18 Kevin Fenzi :
> There's no reason you ever need to login to the web interface, so just
> don't bother and move on. ;)

Almost everything can be done using the koji command line, but one
thing I couldn't find: Koji's web interface let me "create a
notification", so I get notified whenever a selected package is build
(optionally selecting a tag, and optionally on success only).

How can I add/modify/remove such notification subscriptions without
the web interface?

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

Re: Review swap

[Lokesh Mandvekar]

On Thu, Apr 18, 2013 at 09:57:41PM -0700, T.C. Hollingsworth wrote:
> On Thu, Apr 18, 2013 at 3:04 PM, Lokeszoh Mandvekar  wrote:
> > I'd like to offer a review swap.
> 
> I've taken both.  In return, you may choose from:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=894724
> https://bugzilla.redhat.com/show_bug.cgi?id=921847
> https://bugzilla.redhat.com/show_bug.cgi?id=953699
> https://bugzilla.redhat.com/show_bug.cgi?id=953701

T.C.: thanks for the reviews. And I didn't know the fedora-review tool
existed. I'll review the first 2 for sure, perhaps all 4 (now that I know
fedora-review makes it so easy)

> 
> Thanks!
> -T.C.

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

Re: Bundled copies of the Porter stemmer library

[Florian Weimer]

On 04/18/2013 04:32 PM, Petr Pisar wrote:

On 2013-04-17, Florian Weimer  wrote:

Ugh, hit "Send" too soon.

I found some packages which embed copies of the Porter stemmer library
(PostgreSQL, tracker, pl, etc.).  Should I file bugs once I have the
full list, or should I apply for a bundling exception?

I don't know if the existing copies are patched in significant ways.


The SWI Prologue (pl package) modifies the code and modifes the old
Relase 1 (current Porter's release is
2 ).


I think you're packaging the newer Snowball-generated stemmers.  Those 
are available from , and there are actual 
release tarballs (albeit unversioned ones).  As you can see, upstream 
has added support for additional languages which you still have to pick 
up.  This upstream development activity seems to be a fairly strong 
argument against bundling.


--
Florian Weimer / Red Hat Product Security Team
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Bundled copies of the Porter stemmer library

[Toshio Kuratomi]

On Apr 18, 2013 7:33 AM, "Petr Pisar"  wrote:
>
> On 2013-04-17, Florian Weimer  wrote:
> > Ugh, hit "Send" too soon.
> >
> > I found some packages which embed copies of the Porter stemmer library
> > (PostgreSQL, tracker, pl, etc.).  Should I file bugs once I have the
> > full list, or should I apply for a bundling exception?
> >
> > I don't know if the existing copies are patched in significant ways.
>
> The SWI Prologue (pl package) modifies the code and modifes the old
> Relase 1 (current Porter's release is
> 2 ). I worry unbundling
> will not be easy because upstream does not provide a library but
> a simple C code (no headers, no interface) and because pl changes some
> prototypes to fit better to the pl and of course adds the binding
> helpers. Unified diff has 980 lines of 383 upstream lines now.
>

Yeah, if upstream isn't shipping this as a proper library i'd try to get
this in as either a copylib (guidelines for that already exist) or as a
code snippet (guidelines for that don't yet exist but the fpc has recently
granted several exceptions based on the concept.)

It still needs to go through fpc to grant the exception for two reasons: 1)
confirm that it is in fact a copylib or code snippet 2) to assign it a
virtual provide so packages that bundle it can be notified in case a severe
bug is discovered in the porter stemmer upstream on which these are based.

-Toshio

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