Re: package kbackup is blocked for tag...

[Mamoru Tasaka]

Alain Portal wrote, at 01/15/2010 01:50 AM +9:00:
> Hi,
> 
> I´m trying to build updates of kbackup but built failed with the following 
> error message :  "package kbackup is blocked for tag dist-*".
> 
> Can somebody tell me where is the problem?
> 
> Regards,
> Alain
> 

Please file a ticket on rel-eng trac:

https://fedorahosted.org/rel-eng/

with the information that you are going to reintroduce orphaned
"kbackup" package (as the re-review request:
https://bugzilla.redhat.com/show_bug.cgi?id=553739 was approved)
and you want rel-eng team to unblock kbackup on koji.

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

Re: gvfs causes hangs

[Mamoru Tasaka]

Steve Grubb wrote, at 01/23/2010 10:42 PM +9:00:
> Hello,
> 
> I have been running into something on F-12 that is really annoying and was 
> wondering if anyone else is seeing this. When I use kmail and want to attach 
> a 
> file that is not in my Documents folder and go up one level to my homedir, it 
> hangs. I can't do anything with kmail except kill the email I was composing.
> 
> Digging into this further, if you run lsof, it hangs when it gets to ~/.gvfs:
> 



> 
> Is this a defective file system or are a whole bunch of apps needing to be 
> fixed? Also, do other people notice the same thing?
> 
> -Steve

Perhaps this issue:
https://fedoraproject.org/wiki/Common_F12_bugs#FUSE_mounts_may_hang
https://bugzilla.redhat.com/show_bug.cgi?id=493565

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

Re: Non-responsive maintainer: Deji Akingunola

[Mamoru Tasaka]

Robert Scheck wrote, at 08/09/2010 04:39 AM +9:00:
> Hi,
> as per non-responsive maintainer policy at 
>https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
> 
> I have filed:
>https://bugzilla.redhat.com/show_bug.cgi?id=600992
> 
> Does somebody know how to contact Deji Akingunola? I've been unsuccessful
> via e-mail and Red Hat Bugzilla so far. And it seems he isn't around in the
> IRC.
> 
> Greetings,
>Robert
> 

I surely think that deji is active:
http://koji.fedoraproject.org/koji/userinfo?userID=217

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

Re: [HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Mamoru Tasaka]

Lennart Poettering wrote, at 08/12/2010 10:28 PM +9:00:
> On Thu, 12.08.10 00:52, Jesse Keating (jkeat...@redhat.com) wrote:
>
>>
>> Yes, that is correct.  An already built version on f15 will always be
>> "newer" than anything coming up from f14.
>
> Can I "undo" such a build? I did that mostly because I forgot that the
> branching already happened when I built systemd the first time after the
> branching.
>
> I'd prefer having to maintain a single package only, not two.
>
> Lennart
>

Instead you can manually tag a build built for dist-f14-updates-candidate
also for dist-f15, for example:

$ koji tag-pkg dist-f15 systemd-7-2.fc14
With this systemd-7-2.fc14 will have dist-f14-updates-candidate and
dist-f15 tags (currently dist-f15 tag is not locked).

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

Re: Problems when compiling a package which uses boost::signals2.

[Mamoru Tasaka]

Peng Wu wrote, at 08/17/2010 03:36 PM +9:00:
> Hi,
>I tried to rebuild ibus-pinyin package for Fedora 14 which uses 
> boost::signals2, but it failed.
>Later I write a very simple test file, compiling use:
>$g++ -c boost_test.cpp
>And the test file content and compiling error log are attached.
>It still fails, but it compiles ok on Fedora 13.
>Please help me on this.
> Thanks in advance,
>Peng Wu
>

Looks like it is better that you file a bug against boost
for this.

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

Re: [gsettings-desktop-schemas] 0.0.1

[Mamoru Tasaka]

Matthias Clasen wrote, at 08/25/2010 04:52 AM +9:00:
> commit a29d94655cb277aec27bc0751f446d7934b8560b
> Author: Matthias Clasen
> Date:   Tue Aug 24 15:43:57 2010 -0400
>
>  0.0.1
>
>   .gitignore |1 +
>   gsettings-desktop-schemas.spec |7 +--
>   sources|2 +-
>   3 files changed, 7 insertions(+), 3 deletions(-)
> ---
> diff --git a/.gitignore b/.gitignore
> index b0255f1..47d2653 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -1 +1,2 @@
>   gsettings-desktop-schemas-0.0.1.git20100729.tar.bz2
> +/gsettings-desktop-schemas-0.0.1.tar.bz2
> diff --git a/gsettings-desktop-schemas.spec b/gsettings-desktop-schemas.spec
> index 263781d..5ce788d 100644
> --- a/gsettings-desktop-schemas.spec
> +++ b/gsettings-desktop-schemas.spec
> @@ -1,6 +1,6 @@
>   Name:   gsettings-desktop-schemas
>   Version:0.0.1
> -Release:1.git20100729%{?dist}
> +Release:2%{?dist}
>   Summary:A collection of GSettings schemas
>
>   Group:  System Environment/Libraries
> @@ -9,7 +9,7 @@ License:LGPLv2+
>   URL:
> http://bugzilla.gnome.org/enter_bug.cgi?product=gsettings-desktop-schemas
>   #VCS: git:git://git.gnome.org/gsettings-desktop-schemas
>   # Source0:
> http://download.gnome.org/sources/%{name}/0.0/%{name}-%{version}.tar.bz2
> -Source0:%{name}-%{version}.git20100729.tar.bz2
> +Source0:%{name}-%{version}.tar.bz2
>   BuildArch:  noarch
>
>   BuildRequires: glib2-devel>= 2.25.11
> @@ -73,5 +73,8 @@ fi
>
>
>   %changelog
> +* Tue Aug 24 2010 Matthias Clasen  - 0.0.1-2
> +- Update to 0.0.1
> +
>   * Tue Aug  3 2010 Tomas Bzatek  - 0.0.1-1.git20100729
>   - Initial packaging
> diff --git a/sources b/sources
> index 156b309..1a2f796 100644
> --- a/sources
> +++ b/sources
> @@ -1 +1 @@
> -a42f3b8d2cffc73a4adf091ab1a18b04  
> gsettings-desktop-schemas-0.0.1.git20100729.tar.bz2
> +6c8986b4b3101c61baadc9795f52ec3a  gsettings-desktop-schemas-0.0.1.tar.bz2


According to
https://bugzilla.redhat.com/show_bug.cgi?id=619383#c0
and also
http://git.gnome.org/browse/gsettings-desktop-schemas/

the previous gsettings-desktop-schemas was already using post-0.0.1-release
git tarball.

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

Re: Rawhide Koji borked??

[Mamoru Tasaka]

Randall Berry wrote, at 09/05/2010 05:06 PM +9:00:
>
>   I tried building a package on Koji against rawhide and got an error
> before the build even began.[1] I tried to build the same package
> locally with mock and it built just fine. Is there a problem with Koji?
>
> It bombs with:
> BuildrootError: could not init mock buildroot, mock exited with status
> 30; see root.log for more information[2]
>
> More specifically:
> Error: Package: nss-3.12.7.99.3-1.fc15.x86_64 (build)
>   Requires: nss-util>= 3.12.8
>   Available: nss-util-3.12.7.99.3-1.fc15.x86_64 (build)
>   nss-util = 3.12.7.99.3-1.fc15
> You could try using --skip-broken to work around the problem
>
> Error: Package: nss-3.12.7.99.3-1.fc15.i686 (build)
>   Requires: nss-util>= 3.12.8
>   Installing: nss-util-3.12.7.99.3-1.fc15.i686 (build)
>   nss-util = 3.12.7.99.3-1.fc15
> You could try using --skip-broken to work around the problem
>
>
> 1) https://koji.fedoraproject.org/koji/taskinfo?taskID=2447749
> 2) https://koji.fedoraproject.org/koji/getfile?taskID=2447750&name=root.log
>

Looks like this build broke rawhide buildtree:
http://koji.fedoraproject.org/koji/buildinfo?buildID=193736

koji sysadmin or build submitter, would you revoke this build?

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

Re: Fedora rawhide FTBFS status 2010-09-01 x86_64

[Mamoru Tasaka]

Matt Domsch wrote, at 09/07/2010 11:24 AM +9:00:
> Fedora Fails To Build From Source Results for x86_64
> using rawhide from 2010-09-01
>
> Full rebuild of all packages.  Each failed package was retried two
> additional times.  Those listed below have failed at least three
> attempts to build.
>
> Sorry I can't mail to everyone individually this round, we've grown to
> so many contributors that I've hit a scaling problem in FAS so I can't
> convert all the package owners to their real email addresses tonight.
>
> Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/
>

Well, now you are going to file FTBFS bugs with the message like
"foo-V-R Failed To Build From Source against the _rawhide_ tree"
and to make these bugs block _F14FTBFS_ .

Would you clarify if this build results are for rawhide (i.e. F-15)
tree or for F-14 tree?

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

Re: ImageMagick soname bump for F14

[Mamoru Tasaka]

Pavel Alexeev (aka Pahan-Hubbitus) wrote, at 09/17/2010 05:10 PM +9:00:
>   16.09.2010 18:35, Orion Poplawski wrote:
>> Do we really want to do this, especially for a FTBS issue presumably
>> against F15?
>>
>> https://admin.fedoraproject.org/updates/ImageMagick-6.6.4.1-13.fc14
>>
> Please excuse me what I did not ask early. Now I call to maintainers of
> dependent packages - please rebuild it against new version of ImageMagick.
>

Well, currently:
$ koji latest-pkg dist-f14-build ImageMagick
Build Tag   Built by
    
ImageMagick-6.6.2.1-11.fc14   dist-f14  mtasaka

So to build against dist-f14-updates-candidate newest
ImageMagick-6.6.4.1-13.fc14, this ImageMagick should be tagged as
override by rel-eng team.

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

Re: ImageMagick soname bump for F14

[Mamoru Tasaka]

Pavel Alexeev (aka Pahan-Hubbitus) wrote, at 09/17/2010 10:26 PM +9:00:
>   17.09.2010 12:56, Mamoru Tasaka пишет:
>> Pavel Alexeev (aka Pahan-Hubbitus) wrote, at 09/17/2010 05:10 PM +9:00:
>>>16.09.2010 18:35, Orion Poplawski wrote:
>>>> Do we really want to do this, especially for a FTBS issue presumably
>>>> against F15?
>>>>
>>>> https://admin.fedoraproject.org/updates/ImageMagick-6.6.4.1-13.fc14
>>>>
>>> Please excuse me what I did not ask early. Now I call to maintainers of
>>> dependent packages - please rebuild it against new version of ImageMagick.
>>>
>> So to build against dist-f14-updates-candidate newest
>> ImageMagick-6.6.4.1-13.fc14, this ImageMagick should be tagged as
>> override by rel-eng team.
>>
>> Regards,
>> Mamoru
> Currently it tagged as override. So, we can continue build dependencies.

ruby-RMagick rebuilt as ruby-RMagick-2.13.1-4.fc14

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

Re: libnotify issue on F14 and rawhide

[Mamoru Tasaka]

Pavel Alexeev (aka Pahan-Hubbitus) wrote, at 09/24/2010 06:11 PM +9:00:
>   I have packaged xneur, which on review [1] and its build fine on Fedora 12 
> and 13. On Fedora 14 it is failed [2] with error:
>
> /usr/include/libnotify/notification.h:28:21: fatal error: gtk/gtk.h: No such 
> file or directory
>
> I try figure out what happened and go step by step add includes in CFLAGS 
> like:
> make %{?_smp_mflags} CFLAGS="%{optflags} -I%{_includedir}/gtk-2.0"
> after many attempts and googling I finally arrived to:
> make %{?_smp_mflags} CFLAGS="%{optflags} %( pkg-config --cflags --libs 
> gtk+-2.0 )"
>
> which work like a charm.
>
> But I can't understand why I should provide it manually
> and why it does not required in previous releases?
>
> I slightly dig more and found it happened on linking with libnotify library. 
> And finaly result:
> On Fedora 13:
> $ pkg-config --cflags "libnotify >= 0.4.0"
> -pthread -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 
> -I/usr/lib/glib-2.0/include -I/usr/include/dbus-1.0 
> -I/usr/lib/dbus-1.0/include -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 
> -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/pixman-1 
> -I/usr/include/freetype2 -I/usr/include/libpng12
> On Fedora 14 (f14-test.scrye.com):
> $ pkg-config --cflags "libnotify >= 0.4.0"
> -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include 
> -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include
>
> Should I fill bug on libnotify or it is the expected behavior?
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=623604
> [2] http://koji.fedoraproject.org/koji/getfile?taskID=2482272&name=build.log 
> 
>

This change on libnotify is intentional.
http://git.gnome.org/browse/libnotify/commit/?id=0eb56b2fcf16d5381011e0bae2cf942416dae55c
https://bugzilla.gnome.org/show_bug.cgi?id=622550

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

rawhide buildtree broken with the newest perl

[Mamoru Tasaka]

Hello.

Currently rawhide buildtree seems broken with the newest perl:

http://koji.fedoraproject.org/koji/taskinfo?taskID=2506686
http://koji.fedoraproject.org/koji/getfile?taskID=2506686&name=root.log

DEBUG util.py:260:  Error: Package: 4:perl-5.12.2-137.fc15.x86_64 (build)
DEBUG util.py:260: Requires: libperl.so()(64bit)
DEBUG util.py:260:   You could try using --skip-broken to work around the 
problem
DEBUG util.py:260:   You could try running: rpm -Va --nofiles --nodigest

Would someone untag this build? Thank you.

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

Re: Chain builds for non-rawhide

[Mamoru Tasaka]

Jesse Keating wrote, at 10/06/2010 05:58 AM +9:00:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/5/10 1:36 PM, Severin Gehwolf wrote:
>> Hi,
>>
>> I am maintaining eclipse-egit and eclipse-jgit. Since
>> eclipse-egit depends on eclipse-jgit it makes sense to
>> use chain-builds when building them (this is simply
>> faster than waiting for eclipse-jgit to build, and
>> become available in the repos before eclipse-git can
>> be built).
>>
>> Ok, that works for rawhide.
>>
>> Unfortunately this isn't possible for non-rawhide releases.
>>
>> I could start speculating and think of reasons as to why
>> that's the case, but rather ask the more knowledgeable :)
>>
>> So, what were the reasons for not allowing chain-builds
>> for non-rawhide?
>>
>> Many thanks!
>> Severin
>>
>> P.S.: The error message:
>>   Could not initiate build: Packages in destination tag
>>   dist-f14-updates-candidate are not inherited bybuild
>>   tag dist-f14-build
>> doesn't mean much to me. Perhaps an error message
>> indicating that chain-build is not available would be
>> more meaningful.
>
> Sorry that it's terse.  Once we branch a release away, we do not have a
> direct relationship between "it built" and "it will be in the public
> repo".  As such, it is dangerous to allow just-built items into the
> buildroot for future builds, as this could lead to a package being built
> against software that is never released.  A variety of problems happen
> in this scenario.  As such, we carefully maintain what goes into the
> buildroots, only by default taking things which have been marked as
> "stable" via bodhi, or things we explicitly tag in for a short period of
> time in order to accomplish a set of builds.
>
> The way to "chain" build for a branch is to request a buildroot override:
>
> https://fedoraproject.org/wiki/Package_update_HOWTO#Working_with_packages_in_the_stable_branches
>
> That should be easier to find, kudos to anybody that works on making it so.
>
> - --
> Jesse Keating

Well, how about creating "dist-f14-for-chainbuild" build target and allow
people to tag or untag build as/from that tag freely?

For example currently
http://koji.fedoraproject.org/koji/buildtargetinfo?targetID=67
says that build target "dist-f14-kde" uses "dist-f14-kde" tagged packages
for buildroot, and built packages are tagged as "dist-f14-kde" and
the destination tag "dist-f14-kde" is not locked.
(and on the other hand build target "dist-f14" still exists, using
  "dist-f14-build" tagged packages when building but the destination
  "dist-f14" is locked)
So as far as I am correct, we can freely do chain-build using dist-f14-kde
build target for F-14 packages. And actually this status was used
when fixing ImageMagick related dependency breakage on F-14
(see latest ImageMagick group update request on F-14 on bodhi,
  and tag history on koji for ImageMagick-6.6.4.1-13.fc14,
  autotrace-0.31.1-24.fc14.1 for example)
  
So creating build target for chain-build purpose only seems reasonable
to me.

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

Re: Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757

[Mamoru Tasaka]

Jesse Keating wrote, at 10/06/2010 07:27 AM +9:00:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> As you might be aware, there was a period of roughly two weeks where a
> gcc build (gcc-4.5.1-3.fc14) in the buildroots for both Fedora 14 and
> Fedora 15.  Items built with this could have undefined behavior, which
> could lead to data corruption.
>

>
> To handle the F14 scene I've come up with this strategy:
> * For things tagged in dist-f14 and no newer build elsewhere, do a bump,
> build and tag directly into dist-f14.  While there is some risk of
> breakage, it is quite minimal and with discussion from QA we are willing
> to take that chance.  This work is ongoing.
>
> * For things tagged in dist-f14-updates-testing, do a bump, build and
> then edit the bodhi ticket to add the new build, and re-push to
> updates-testing.  This work will begin soon.
>
> * for things tagged in dist-f14-updates-candidate, do a bump and build.
>   Then look for an open bodhi ticket for that package, adjusting as
> needed.  If no bodhi ticket is found, do not create a new one, just
> leave the build as is.  This work will begin soon.
>

How does this strategy go for packages that the latest dist-f14 one
was rebuilt using gcc-4.5.1-3.fc14, and there is newer 
dist-f14-updates-candidate
one rebuilt using gcc-4.5.1-3.fc14 but no bodhi submission yet?

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

Re: Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757

[Mamoru Tasaka]

Hello:

Jesse Keating wrote, at 10/06/2010 07:27 AM +9:00:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> As you might be aware, there was a period of roughly two weeks where a
> gcc build (gcc-4.5.1-3.fc14) in the buildroots for both Fedora 14 and
> Fedora 15.  Items built with this could have undefined behavior, which
> could lead to data corruption.
>
> Unfortunately I'm told that it is impossible to look at a generated
> binary and detect whether or not the binary would be effected by this
> bug.  The only reliable way to tell would be to re-create the build
> environment exactly, except replace GCC with one that will detect the
> error scenario and print something.  As this is a significant amount of
> work, I decided instead to just rebuild the potential problem builds.
>

Would you update the current status of this issue?

For example I checked the current status of ruby-gnome2 (because
I was going to upgrade ruby-gnome2 on F-14) and
- still the latest ruby-gnome2 on F-14 is ruby-gnome2-0.90.2-1.fc14
- this one uses the problematic gcc
- while it seemed that ruby-gnome2 was rebuilt against newer gcc
   (with EVR: ruby-gnome2-0.90.2-1.fc14.1), this new ruby-gnome2 was
   never pushed into dist-f14 or submitted on bodhi.

So are there any list file which suggests what packages still need
repush (after rebuild or update) for this gcc issue?

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

Re: mass rebuild of mysql packages in F-15

[Mamoru Tasaka]

Tom Lane wrote, at 03/25/2011 12:23 AM +9:00:
> =?UTF-8?B?TWFyY2VsYSBNYcWhbMOhxYhvdsOh?=  writes:
>>> Kevin Kofler  writes:
 Probably needs BR flex-static.
>
>> I've applied BR and build ser
>> http://koji.fedoraproject.org/koji/taskinfo?taskID=2940159
>
> Thanks for that.  As of now we have 75 packages in dist-f15-mysql,
> with the following dependencies having failed to build:
>
> collectd  complains about "nut"?
>  http://koji.fedoraproject.org/koji/getfile?taskID=2937228&name=build.log
> gmyth pre-existing FTBFS #564741
> gstreamer-plugins-bad-freebuildrequires gmyth which FTBFS
> pure-ftpd pre-existing FTBFS #690346
> snort pre-existing FTBFS, orphaned
> zoneminderpre-existing FTBFS #672707
>

gmyth built, now gstreamer-plugins-bad-free is waiting for new-repo
on chain-build.

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

Re: LD Changes To Implicit DSO Linking Update

[Mamoru Tasaka]

Parag N(पराग़) wrote, at 02/10/2010 02:58 AM +9:00:
> On Tue, Feb 9, 2010 at 11:18 PM, Jakub Jelinek  wrote:
>> On Tue, Feb 09, 2010 at 11:09:50PM +0530, Parag N(पराग़) wrote:
>>>  Anyway I find adding missing DSO to CFLAGS in SPEC is easy solution for 
>>> now.
>> They don't belong to CFLAGS, those are flags for compilation.  You want
>> LDFLAGS or even better add it in configure to LIBS.
> 
>   I am not sure then what's wrong with my package. Here is how it
> failed 
> http://koji.fedoraproject.org/koji/getfile?taskID=1970866&name=build.log

This build.log says:

/usr/bin/ld: keyevent.o: undefined reference to symbol 'XKeysymToString'
/usr/bin/ld: note: 'XKeysymToString' is defined in DSO /usr/lib/libX11.so.6 so 
try adding it to the linker command line
/usr/lib/libX11.so.6: could not read symbols: Invalid operation
collect2: ld returned 1 exit status

And actually src/keyevent.c reads:

   275  if (key_disable_overwrite) {
   276  key_event->keycode = -1;
   277  key_event->keysym = 0;
   278  g_print("Not allowed to overwrite KeyCode for %s",
   279  XKeysymToString(keysym));
   280  return;
   281  }


You should add "AC_CHECK_LIB(X11, XKeysymToString)" to configure.in,
for example.

> and then modifying CFLAGS its successful build at
> http://kojipkgs.fedoraproject.org/packages/iok/1.3.9/1.fc13/data/logs/i686/build.log
> 
> Parag.

Regards,
Mamoru

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

Re: Fedora 13 has been branched!!

[Mamoru Tasaka]

Jesse Keating wrote, at 02/17/2010 01:10 PM +9:00:
> That's right folks, we are now branched for Fedora 13.  What does this
> mean to you?  Well that depends on who "you" are, here are some "you"s
> that we wrote about:
> https://fedoraproject.org/wiki/No_frozen_rawhide_announce_plan#Use_Cases

>From me currently two questions.

A. How does this affect http://koji.fedoraproject.org/static-repos/ ?
B. As other person already asked, will daily "rawhide changes" report
   (containing broken deps) be reported also for F-13 to devel list,
   or just changes for F-14 only will be reported (i.e. daily broken
   deps report will no longer be available for F-13)?

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

Re: Orphaning some Ruby gems...

[Mamoru Tasaka]

Darryl L. Pierce wrote, at 02/22/2010 10:37 PM +9:00:
> Since I have little time and no use for the packages, I'm orphaning the
> following items:
> 
>  * rubygem-activeldap
>  * rubygem-gruff
>  * rubygem-hoe
>  * rubygem-RedCloth
>  * rubygem-rubyforge
>  * rubygem-rufus-scheduler
>  * rubygem-state_machine
> 
> If you are interested in taking them on, please let me know so we can
> transfer them. But I won't be pushing any further updates for them.

I will take rubygem-activeldap and rubygem-hoe.

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

Re: What happened to mercurial-1.5-2.fc11?

[Mamoru Tasaka]

Neal Becker wrote, at 03/11/2010 09:52 PM +9:00:
> fc13 and fc12 are shown here:
> https://admin.fedoraproject.org/updates/search/mercurial?_csrf_token=9d135a7a59b1892cc911a5f075633fb7dd4ef993
> 
> But not fc11.  So I tried to rebuild, and got:
> 2046149 build (dist-f11-updates-candidate, 
> /cvs/pkgs:rpms/mercurial/F-11:mercurial-1_5-2_fc11): open 
> (ppc03.phx2.fedoraproject.org) -> FAILED: GenericError: Build already exists 
> (id=160549, state=COMPLETE): {'name': 'mercurial', 'task_id': 2046149, 
> 'pkg_id': 2518, 'epoch': None, 'completion_time': None, 'state': 0, 
> 'version': '1.5', 'owner': 286, 'release': '2.fc11', 'id': 160549}
>   0 free  0 open  1 done  1 failed
> 
> OK, then where is it?
> 

It seems that you solved this issue by yourself now (I guess
you just forgot to submit push request before).

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

Re: How to become someone's sponsor when they are already sponsored

[Mamoru Tasaka]

Jim Meyering wrote, at 03/18/2010 09:24 PM +9:00:
> Dan Horák wrote:
>> Richard W.M. Jones píše v Čt 18. 03. 2010 v 12:01 +:
>>> Jim Meyering (FAS username: meyering) was sponsored by Warren Togami.
>>> It seems that Jim can no longer set the fedora-review flag on packages
>>> that he's reviewed, and this may be connected with Warren leaving Red
>>> Hat for new pastures yesterday.  In any case I've agreed with Jim that
>>> I'll become his sponsor.
>> Those 2 events shouldn't be connected. The inability to set flags in
>> bugzilla is usually caused by using an email as login in bugzilla that's
>> not registered in FAS.
> 
> Hi Dan,
> 
> Thanks for the quick reply.
> I've just changed my email in FAS to match the one in bugzilla,
> confirmed it, then tried to set the flag again.  Same failure.
> 
> Jim

My recognition is that if you change your email in FAS it may take
about an hour or so for RH bugzilla database to recognize it.

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

Re: review request - pre-review done, needing actual reviewer

[Mamoru Tasaka]

David Timms wrote, at 03/18/2010 09:38 PM +9:00:
> Hi, I would love to get tnef (an ms lookout email attachment lister / 
> extractor) review completed for F13 (ie before next week). Anyone 
> reviewer like to take a look (I can't convince every acquaintance to 
> stop sending ms "rich text" which this application fixes for me :~).
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=522920 if interested.
> 
> Cheers, David Timms


Just FYI Naoki is already sponsored and he can review this ticket
by himself if he want.

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

Re: help with build error : fixxref.py

[Mamoru Tasaka]

Ankur Sinha wrote, at 03/26/2010 01:34 PM +9:00:
> hey,
> 
> I'm trying to build pyclutter from the latest git release. 
> 
> This is what I get from the tail of my build.log. 
> Can someone please tell me how to work around it?
> 
> -- Installing ../docs/html/pt04.html
> -- Installing ../docs/html/pyclutter.devhelp
> -- Installing ./html/index.sgml
> make[4]: execvp: /usr/share/pygobject/xsl/fixxref.py: Permission denied
> make[4]: *** [install-data-hook] Error 127
>
> This is the srpm:
> 
> http://ankursinha.fedorapeople.org/pyclutter/pyclutter-1.0.2-1.git.fc12.src.rpm
> 

On my system /usr/share/pygobject/xsl/fixxref.py has 0644 permission (i.e.
not with executable permission), so I guess
--
87  install-data-hook:
88  @$(PYGOBJECT_FIXXREF) -i $(PYGOBJECT_PYGDOCS) 
$(DESTDIR)$(TARGET_DIR)
--
is failing. Perhaps chaging this line to "@python $(PYGOBJECT_FIXXREF) "
or so will make build succeed (I have not tried yet)

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

Re: help with build error : fixxref.py

[Mamoru Tasaka]

Mamoru Tasaka wrote, at 03/26/2010 02:01 PM +9:00:
> Ankur Sinha wrote, at 03/26/2010 01:34 PM +9:00:
>> hey,
>>
>> I'm trying to build pyclutter from the latest git release. 
>>
>> This is what I get from the tail of my build.log. 
>> Can someone please tell me how to work around it?
>>
>> -- Installing ../docs/html/pt04.html
>> -- Installing ../docs/html/pyclutter.devhelp
>> -- Installing ./html/index.sgml
>> make[4]: execvp: /usr/share/pygobject/xsl/fixxref.py: Permission denied
>> make[4]: *** [install-data-hook] Error 127
>>
>> This is the srpm:
>>
>> http://ankursinha.fedorapeople.org/pyclutter/pyclutter-1.0.2-1.git.fc12.src.rpm
>>
> 
> On my system /usr/share/pygobject/xsl/fixxref.py has 0644 permission (i.e.
> not with executable permission), so I guess
> --
> 87  install-data-hook:
> 88  @$(PYGOBJECT_FIXXREF) -i $(PYGOBJECT_PYGDOCS) 
> $(DESTDIR)$(TARGET_DIR)
> --
> is failing. Perhaps chaging this line to "@python $(PYGOBJECT_FIXXREF) "
> or so will make build succeed (I have not tried yet)

These lines are in docs/Makefile.am

> 
> Regards,
> Mamoru

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

Re: help with build error : fixxref.py

[Mamoru Tasaka]

Chen Lei wrote, at 03/26/2010 02:12 PM +9:00:


/usr/share/pygobject/xsl/fixxref.py has a shebang, but doesn't 
have execute permission. So I think there's probably a packaging error 
in pypygobject.


(please avoid top posting:
http://fedoraproject.org/wiki/Communicate/MailingListGuidelines#Proper_posting_style
 )


On 2010-03-26 13:07:21??"Mamoru Tasaka"  Wrote??

Mamoru Tasaka wrote, at 03/26/2010 02:01 PM +9:00:

Ankur Sinha wrote, at 03/26/2010 01:34 PM +9:00:

hey,

I'm trying to build pyclutter from the latest git release. 

This is what I get from the tail of my build.log. 
Can someone please tell me how to work around it?


-- Installing ../docs/html/pt04.html
-- Installing ../docs/html/pyclutter.devhelp
-- Installing ./html/index.sgml
make[4]: execvp: /usr/share/pygobject/xsl/fixxref.py: Permission denied
make[4]: *** [install-data-hook] Error 127

This is the srpm:

http://ankursinha.fedorapeople.org/pyclutter/pyclutter-1.0.2-1.git.fc12.src.rpm



On my system /usr/share/pygobject/xsl/fixxref.py has 0644 permission (i.e.
not with executable permission), so I guess
--
87  install-data-hook:
88  @$(PYGOBJECT_FIXXREF) -i $(PYGOBJECT_PYGDOCS) 
$(DESTDIR)$(TARGET_DIR)
--
is failing. Perhaps chaging this line to "@python $(PYGOBJECT_FIXXREF) "
or so will make build succeed (I have not tried yet)


These lines are in docs/Makefile.am



Note that while I am not familiar with this script, this script (fixxref.py)
is in pygobject2-"doc", and usually adding executable permission in the
files in document rpms is not desired.
(e.g. see the explanation of $ rpmlint -I doc-file-dependency)

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

Re: What are the rules for which package we build against in F-13?

[Mamoru Tasaka]

Denis Leroy wrote, at 04/07/2010 03:20 PM +9:00:
> On 03/08/2010 04:37 PM, Josh Boyer wrote:
>> The buildroots are populated from packages in the:
>>
>> dist-f13
>> dist-f13-override
>> dist-f12-updates
>>
>> tags.  If a package isn't in one of those tags, it's not going to be in the
>> buildroot.  If you need to build against a newer version of a package, then 
>> you
>> need to file a ticket on the rel-eng trac instance asking for a buildroot
>> override (which will get it tagged into dist-f13-override).
> 
> Sorry to revive this old thread, but does this imply that one cannot use 
> 'make chain-build' for F-13 updates then ?

Yes.

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

Orphaning manedit

[Mamoru Tasaka]

Hello, all:

I've just released the ownership of manedit since I don't use this anymore.
If you are interested in maintaining manedit, please take the ownership of
this package.

https://admin.fedoraproject.org/pkgdb/acls/name/manedit
http://freshmeat.net/projects/manedit/

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

Re: How to control (or avoid) brp-python-bytecompile

[Mamoru Tasaka]

Debarshi Ray wrote, at 04/30/2010 04:43 AM +9:00:
> Anjuta carries a bunch of template sources which are filled up at
> runtime to generate source files for various kinds of projects. These
> are placed in /usr/share/anjuta/project. Now
> /usr/lib/rpm/brp-python-bytecompile is trying to byte compile the
> Python templates, which are obviously not syntactically correct Python
> sources. This is failing the build:
> http://koji.fedoraproject.org/koji/getfile?taskID=2146714&name=build.log
>
> How do I work around this?
>
> Thanks,
> Debarshi

Looking at /usr/lib/rpm/brp-python-bytecompile, it reads:
-
  1  #!/bin/bash
  2  errors_terminate=$2
-

and rpm --showrc shows:
-
-14: __os_install_post
 /usr/lib/rpm/redhat/brp-compress
 %{!?__debug_package:
 /usr/lib/rpm/redhat/brp-strip %{__strip}
 /usr/lib/rpm/redhat/brp-strip-comment-note %{__strip} %{__objdump}
 }
 /usr/lib/rpm/redhat/brp-strip-static-archive %{__strip}
 /usr/lib/rpm/brp-python-bytecompile %{__python} 
%{?_python_bytecompile_errors_terminate_build}
 /usr/lib/rpm/redhat/brp-python-hardlink
 %{!?__jar_repack:/usr/lib/rpm/redhat/brp-java-repack-jars}
%{nil}
-

So adding "%global _python_bytecompile_errors_terminate_build 0"
will perhaps workaround this issue (default is 1).

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

Re: /lib64/libm.so.6: could not read symbols: Invalid operation

[Mamoru Tasaka]

Eric "Sparks" Christensen wrote, at 11/21/2010 01:47 PM +9:00:
> I'm working on updating the GPredict package for F13, F14, F15, and EL6.
>   The package builds fine on F14 and F15 but on F13 it fails with the
> error '/lib64/libm.so.6: could not read symbols: Invalid operation'.
> You can see the logs and such in koji[0].
>
> Anyone have any ideas?  I thought this was dealing with the DSO problem
> but I thought I had ruled that out.
>
> [0] http://koji.fedoraproject.org/koji/taskinfo?taskID=2613802
>
>
> Thanks,
> Eric

Try to add "-lm". F-15 build contains -lm so it came from somewhere
else by chance, however F-13 build does not.

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

koji server down?

[Mamoru Tasaka]

Hello.

It seems koji is currently down (no hosts seems enabled)
http://koji.fedoraproject.org/koji/hosts
and many tasks are hanging.

Were there any announcement I may have missed or is the
current status unexpected?

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

Re: Is there any value to per-Fedora branch ACLs?

[Mamoru Tasaka]

Jesse Keating wrote, at 12/08/2010 03:20 AM +9:00:
> While I'm looking into the git setup and ACLs and all this, I have a
> question.
>
> Is anybody seeing any real value of having different commit ACLs per
> Fedora branch?  I've seen some argument for EPEL vs Fedora, but is there
> real value in ACLs for f13, f14, devel, etc...?
>

There can be a case that F-13 package and F-14 package are completely
"different", even if the packages have the same name.

For example there may be a case that a package of older version
shipped in F-13 is written in perl, and new version shipped in F-14 is complete
rewritten in python (and I know one example, and for this case
re-review request for newer python version was submitted by the person
who was not the primary maintainer of perl version). In this case
for F-13 it may be reasonable that perl-sig is added in watchcommits,
however on F-14 it is perhaps meaningless. And even they may want to
change primary maintainer between these two (although for this case
the primary maintainer did not change finally).

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

Re: g++ -shared -pthread doesn't link -lpthread ?

[Mamoru Tasaka]

Rex Dieter wrote, at 12/08/2010 11:50 PM +9:00:
> I'm trying to find the best solution to:
> https://bugzilla.redhat.com/show_bug.cgi?id=661115
>
> Where a shlib is generated using
> g++ -shared -pthread ...
> but the result is a library with undefined symbols to pthread_create (and
> friends).
>
> Do I really need to explicity link -lpthread , or is there a better
> solution?
>
> -- Rex
>


Maybe this?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25460
-pthread should have priority over -nostdlib -> CLOSED INVALID

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

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Mamoru Tasaka]

Thomas Moschny wrote, at 12/10/2010 08:19 PM +9:00:
> That seems by far the cleanest solution to me. Especially
> development-oriented packages often contain example directories;
> removing x-bits there only puts extra-burden on someone trying to play
> with the examples.

Indeed some examples/ directory contains some executable scripts
which are useful to understand what the package can do.
I think "%doc files must not have executable permissions" must be
reverted.


> On a related note, rpmlint also warns (don't know if we have a
> corresponding guideline) about empty files, even when in %doc, but in
> some cases these might indeed be wanted.

Exactly. Removing empty files sometimes causes unexpected failures
so if there is some reason this rpmlint can simply be ignored.

> Thomas

Regards,
Mamoru

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

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Mamoru Tasaka]

Toshio Kuratomi wrote, at 12/11/2010 02:00 AM +9:00:
> On Fri, Dec 10, 2010 at 08:40:23PM +0900, Mamoru Tasaka wrote:
>> Thomas Moschny wrote, at 12/10/2010 08:19 PM +9:00:
>>> That seems by far the cleanest solution to me. Especially
>>> development-oriented packages often contain example directories;
>>> removing x-bits there only puts extra-burden on someone trying to play
>>> with the examples.
>>
>> Indeed some examples/ directory contains some executable scripts
>> which are useful to understand what the package can do.
>> I think "%doc files must not have executable permissions" must be
>> reverted.
>>
> To my mind, if you have examples that you want to be runnable by the user
> and you want them to not have to perform chmod 0755 to achieve that, you'd
> also want rpm to ensure that the dependencies for those examples are
> installed.

So, when a package
- contains some example scripts
- the packager thinks that such scripts are useful and many people actually
  want to execute them
- but such scripts need additional dependencies
then the packager actually may want to add additional dependencies.

So
- Loosen the guideline to "%doc files should not add "too much" additional
  dependency"
- If executing %doc scripts want some "large" additional dependency, move such 
scripts
  to somewhere else (out of /usr/share/doc, e.g. %_libdir/%name/examples), 
  or create subpackage like %name-examples
?
(By the way I think in most cases additional dependencies are actually
 not needed)

Regards,
Mamoru

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

Re: help with build failure

[Mamoru Tasaka]

gia...@gmail.com wrote, at 12/14/2010 06:50 AM +9:00:
> Hi all,
> I'm trying to fix the F15 build failure for gpointing-device-settings
> reported here:
> https://bugzilla.redhat.com/show_bug.cgi?id=660864
>
> and I'd need some help to understand what's going on. The main issue
> was related to a newer gtk version, this one is now fixed.
>
> The other one is trickier (at least for me), as the package which is
> building fine in mock for F14, fails with something like:
>
> /usr/bin/ld: .libs/libpointing_device_la-gsd-pointing-device-plugin.o:
> relocation R_386_GOTOFF against undefined symbol
> `gsd_mouse_extension_plugin_class_finalize' can not be used when
> making a shared object
> /usr/bin/ld: final link failed: Bad value
> collect2: ld returned 1 exit status
>
> scratch build here:
> http://koji.fedoraproject.org/koji/getfile?taskID=2661197&name=build.log
>
> Can anyone help me fix it?
>

This is due to this change in gnome-settings-daemon:
http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=0dda56c4462e070

It seems at least you have to define
gsd_mouse_extension_plugin_class_finalize(GsdMouseExtensionPluginClass *klass)
in modules/gnome-settings-daemon-plugins/gsd-pointing-device-plugin.c

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

Re: @core in F14 pulls in libX11

[Mamoru Tasaka]

Garrett Holmstrom wrote, at 01/22/2011 03:54 PM +9:00:
> It seems that the "core" yum group pulls in X11 libraries, at the very
> least on x86_64, via the following dependency chain:
>
> policycoreutils
> dbus-glib
> gobject-introspection
> cairo
> libX11
>
> Does that much seriously need to be in what we consider a bare minimum
> Fedora install?

Seems it is fixed in rawhide  (ingobject-introspection)
http://lists.fedoraproject.org/pipermail/fedora-server-list/2010-September/000185.html

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

Re: Problems with Perl in Rawhide?

[Mamoru Tasaka]

Richard W.M. Jones wrote, at 01/27/2011 09:51 PM +9:00:
> On Wed, Jan 26, 2011 at 10:04:45AM -0700, Kevin Fenzi wrote:
>> Yes, perl was broken. I have untagged it and notified the maintainer
>> (who was already looking at it).
>>
>> Things should work again as soon as the buildroot rebuilds.
>
> So is Perl still broken?  I'm getting lots of emails like:
>
>  vhostmd-0.4-11.fc14.x86_64 requires /usr/bin/perl
>  vhostmd-0.4-11.fc14.x86_64 requires perl(strict)
>
> Rich.
>

I received mails about broken deps not only on perl, like:
On i386:
mfiler3-4.2.1-1.fc15.i686 requires saphire >= 0:1.1.8
mfiler3-4.2.1-1.fc15.i686 requires libsaphire.so.1
On i386:
rubygem-mechanize-1.0.1-0.1.beta.20110107104205.fc15.noarch requires 
rubygem(net-http-persistent)

So currently I guess this is not perl problem but repoclosure is
broken in some way (I don't know well)

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

Re: apel -> emacs-apel

[Mamoru Tasaka]

Michael Schwendt wrote, at 02/24/2011 08:48 PM +9:00:
> On Thu, 24 Feb 2011 12:45:54 +0100, Michael wrote:
>
>> On Thu, 24 Feb 2011 12:46:09 +0900 (JST), Akira wrote:
>>
>>> BN>  Orphan: apel
>>> BN>  ddskk requires apel = 10.7-4.fc12
>>> BN>  emacs-common-w3m requires apel = 10.7-4.fc12
>>> BN>  emacs-w3m requires apel = 10.7-4.fc12
>>> BN>  flim requires apel = 10.7-4.fc12
>>> BN>  migemo-emacs requires apel = 10.7-4.fc12
>>> BN>  migemo-xemacs requires apel = 10.7-4.fc12
>>>
>>> apel has just been renamed to emacs-apel because of the
>>> naming guidelines. the above packages has to be rebuilt
>>> against emacs-apel instead of apel.
>>
>> When renaming a package you would normally add a good Obsoletes/Provides
>> pair for the old name and drop that only after an appropriate period of
>> time (e.g. 2-3 dist releases). Has that been done for "apel"?
>
> $ repoquery --whatprovides apel
> apel-0:10.7-4.fc12.noarch
> emacs-apel-0:10.8-1.fc14.noarch
> apel-0:10.7-4.fc12.noarch
>
> What do the other packages require a specific VR of apel?
> Is that necessary or just too strict?

Well, I just checked one example and
http://koji.fedoraproject.org/koji/rpminfo?rpmID=2376622
says that emacs-w3m has just "Requires: apel" and does not have
such strict version-specific dependency.

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

Re: Bugs in debuginfo packages

[Mamoru Tasaka]

Roland McGrath wrote, at 02/25/2011 10:16 AM +9:00:
>> component: CCfits (sergiopr)
>>file: 
>> CCfits-debuginfo-2.3-2.fc15.i686/usr/lib/debug/.build-id/da/7236759b8c63fab2925bd308123b9b277a238c
>> - unused debuginfo, binary is not packaged: /usr/bin/cookbook
>
> The debuginfo is collected from the %buildroot directories.  There is an
> rpmbuild check that barfs if there are any unpackaged files in there, so
> that should have broken the build.  There is some macro magic to disable
> that check, but Fedora spec files should not be using that (if it isn't
> formally disallowed in the packaging guidelines to turn this check off,
> it should be).  So I'm not sure how that could happen.

This can happen when %exclude is used. %exclude'd files must be installed
under %buildroot (otherwise rpmbuild raises error about missing files), do
find-debuginfo.sh collects debuginfo from %exclude'd binary and it will be
packaged in -debuginfo rpm, however the original binary won't be packaged.

(So in these cases I always recommend to explicitly remove unneeded files
  from %buildroot instead of using %exclude)

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

Re: F-13 libtool broken by gcc update

[Mamoru Tasaka]

Tom Lane wrote, at 05/04/2010 03:30 AM +9:00:
> F-13 builds requiring libtool are now failing with
>
> DEBUG util.py:256:  libtool-2.2.6-18.fc13.x86_64 from build has depsolving 
> problems
> DEBUG util.py:256:-->  Missing Dependency: gcc = 4.4.3 is needed by 
> package libtool-2.2.6-18.fc13.x86_64 (build)
> DEBUG util.py:256:  Error: Missing Dependency: gcc = 4.4.3 is needed by 
> package libtool-2.2.6-18.fc13.x86_64 (build)
> DEBUG util.py:256:   You could try using --skip-broken to work around the 
> problem
>
> apparently as a result of the fact that gcc was updated to 4.4.4 over
> the weekend.  Could we have a fix for this ASAP, please?  And why
> weren't there loud bleats from broken-dependencies checking?
>
>   regards, tom lane

$ TZ=UTC koji list-tag-history --build=gcc-4.4.4-1.fc13
Sat May  1 00:57:24 2010: Tagged gcc-4.4.4-1.fc13 with 
dist-f13-updates-candidate [still active]
Mon May  3 15:58:06 2010: Tagged gcc-4.4.4-1.fc13 with dist-f13-override
Mon May  3 17:37:31 2010: Untagged gcc-4.4.4-1.fc13 from dist-f13-override

The dependency was broken only for this 2 hours (perhaps to rebuild libtool for 
gcc 4.4.4).
Now:
$ koji latest-pkg dist-f13-build gcc libtool
Build Tag   Built by
    
gcc-4.4.3-18.fc13 dist-f13  jakub
libtool-2.2.6-18.fc13 dist-f13  jakub

Once newrepo is created, dependency will be recovered again.

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

Re: F-13 libtool broken by gcc update

[Mamoru Tasaka]

Jakub Jelinek wrote, at 05/04/2010 05:17 AM +9:00:
> On Mon, May 03, 2010 at 03:35:44PM -0400, Tom Lane wrote:
>> Mamoru Tasaka  writes:
>>> $ TZ=UTC koji list-tag-history --build=gcc-4.4.4-1.fc13
>>> Sat May  1 00:57:24 2010: Tagged gcc-4.4.4-1.fc13 with 
>>> dist-f13-updates-candidate [still active]
>>> Mon May  3 15:58:06 2010: Tagged gcc-4.4.4-1.fc13 with dist-f13-override
>>> Mon May  3 17:37:31 2010: Untagged gcc-4.4.4-1.fc13 from dist-f13-override
>>
>>> The dependency was broken only for this 2 hours (perhaps to rebuild libtool 
>>> for gcc 4.4.4).
>>> ...
>>> Once newrepo is created, dependency will be recovered again.
>>
>> BTW, it's now two hours later and gcc 4.4.4 is still in the buildroot.
>> There is no newrepo task running for F-13, and no evidence that one has
>> been launched recently.  Perhaps an untag event fails to force a repo
>> rebuild?  If so seems like a bug.
>
> So what is
> http://koji.fedoraproject.org/koji/taskinfo?taskID=2158992
> then?
>
>   Jakub

Well, it seems usually koji runs 3 newrepo tasks at the same time, but
two of them were hanging for 9 hours (for dist-rawhide and dist-rawhide)
so newrepo tasks were rolling very slowly (I noticed this because
I submitted one chain-build for dist-rawhide but it failed because wait-repo
failed).

I requested to cancel hanging 2 newrepo tasks and they were cancelled.
Now newrepo tasks seem to be going well and new F-13 build already appeared as
Jakub said above.

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

Re: F-13 libtool broken by gcc update

[Mamoru Tasaka]

Mamoru Tasaka wrote, at 05/04/2010 05:31 AM +9:00:

> Well, it seems usually koji runs 3 newrepo tasks at the same time, but
> two of them were hanging for 9 hours (for dist-rawhide and dist-rawhide)

small correction: for dist-rawhide and for dist-f14

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

Re: Quake3 security issue and non-responsive maintainer: Xavier Lamien

[Mamoru Tasaka]

Michael Schwendt wrote, at 05/11/2010 06:37 PM +9:00:
> On Tue, 11 May 2010 14:37:22 +0530, Rahul wrote:
>
>> Hi
>>
>> https://admin.fedoraproject.org/pkgdb/acls/bugs/quake3
>>
>> Quake 3 engine needs to be updated.  The current version has security
>> issues and breaks multiplayer in a couple of Quake3 based games such as
>> OpenArena.  The maintainer has not responded in bugzilla since March and
>> has not responded to private email either.  I would like to invoke the
>> fast track process.   Meanwhile, I will be much obliged if someone
>> updates Quake 3 to the latest version available and push out updates for
>> Fedora 13 and 12.
>>
>> Rahul
>
> Correction to:
>
> | The maintainer has not responded in bugzilla since March and
> | has not responded to private email either.
>
> None of the currently open tickets have seen a reply by the maintainer,
> and they date back to 2008 (including the CVEs).

Xavier responsed to rubygem-json related bug recently:
https://bugzilla.redhat.com/show_bug.cgi?id=589801

So I guess trying to re-contact him is better.

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

Re: Errors in packaging kupfer

[Mamoru Tasaka]

Ratnadeep Debnath wrote, at 05/26/2010 08:46 PM +9:00:
> On Wed, May 26, 2010 at 2:05 PM, Chen Lei  wrote:
>> CFLAGS="$RPM_OPT_FLAGS" LDFLAGS="-lm" waf configure --prefix=%{_prefix}
>> ->
>> waf configure --prefix=%{_prefix} --no-runtime-deps
>>
>>
>> All python modules are not needed in runtime, don't check them. Also,
>> the package is noarch, optflags is not needed.
>
> That does not answer the current topic.
> Also, the checking is done by the waf script, not by the rpm packaging method.
> The question is :
> Why waf is not able to detect the gtk python module during rpmbuild?
> pygtk and concerned gtk packages are installed.
>
> Thanks,
> rtnpro

With Fedora's pygtk2, "import gtk" fails if DISPLAY environment is
not set, and DISPLAY environment is always unset during rpmbuild
process. You see;

Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.sxcUp9
+ umask 022
+ cd /home/rtnpro/rpmbuild/BUILD
+ cd kupfer-v200
+ LANG=C
+ export LANG
+ unset DISPLAY  <


Note that why I said "Fedora's pygtk2" is that with Fedora's pygtk2
the following patch is applied:
http://cvs.fedoraproject.org/viewvc/rpms/pygtk2/devel/pygtk-nodisplay-exception.patch?view=log

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

Re: ImageMagick update

[Mamoru Tasaka]

Pavel Alexeev (aka Pahan-Hubbitus) wrote, at 05/30/2010 11:59 PM +9:00:
> 22.05.2010 17:28, Hans de Goede пишет:
>> This is not necessarily good advice either:
>> 1) As these la files are for plugins which are located outside of %{_libdir},
>> they do no harm
>> 2) In the past there have been cases with plugins where the libraries plugins
>> loading mechanism relies on the .la files being present, that might very well
>> be the case here.
>>
>> Regards,
>>
>> Hans
>>
> Very interesting.
> Actually spec file contain string to delete in root build directory:
> rm $RPM_BUILD_ROOT%{_libdir}/*.la
> What can happened bad if I do:
> find $RPM_BUILD_ROOT -type f -name "*.la" -exec rm -f {} \;
> as Chen Lei suggested before?
>
> Actually I done that, but update is not pushed yet.

At least you have to check if removing libtool files in module directory
won't raise this issue again:
https://bugzilla.redhat.com/show_bug.cgi?id=185237

Regards,
Mamoru

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

Re: Fedora rawhide FTBFS status 2010-05-27 i386

[Mamoru Tasaka]

Nathanael D. Noblet wrote, at 06/01/2010 03:03 AM +9:00:
> On 05/31/2010 11:44 AM, Matt Domsch wrote:
>> Fedora Fails To Build From Source Results for i386
>> using rawhide from 2010-05-27
>>
>> This is a full rebuild, the first for Fedora 14's rawhide.  The
>> builders all have Fedora 13 installed.
>>
>> Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/
>
>> barry-0.17-0.1.20100329git.fc14 (build/make) quantumburnz,gnat
>
>
> Looking at the build logs
>
> In file included from BackupWindow.cc:22:
> BackupWindow.h:22:19: error: gtkmm.h: No such file or directory
> BackupWindow.h:23:24: error: libglademm.h: No such file or directory
>
> It seems that it is missing gtkmm24-devel and a few other of the
> required BuildRequires that are in the spec. Its a bit odd since it only
> fails to build on i386... x86_64 no FTBFS...
>
> Ideas?
>

Well, from
http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/i386/pkgconfig-0.24-5.fc14.src.rpm/
maybe pkgconfig-0.24-5.fc14 is used for this build test. This pkgconfig
can cause segfault somewhat easily, so if build uses the result of "pkg-config 
--cflags"
(and when pkg-config segfaults), needed header files cannot be included and
build can fail.
This issue is fixed in -6.fc14 and the newest pkgconfig is 0.25-1.fc14 (see 
changelog).

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

Re: culmus-fonts packaging bug / Non-responsive maintainer

[Mamoru Tasaka]

Michael Schwendt wrote, at 06/02/2010 06:49 PM +9:00:
> http://bugzilla.redhat.com/570819
>
> A ticket opened on March 5th, but Pravin Satpute just doesn't
> respond.
>
> Does anyone know the languages involved here (lang=he, lang=yi)
> and can fix this fonts package, please? Thanks in advance.

I will vote that this must be fixed in yum side (or fontconfig or rpm).

This provides is automatically generated by /usr/lib/rpm/fontconfig.prov
and this reads:

 13  fcquery=/usr/bin/fc-query
 14
 15  [ -x $fcquery ] || exit 0
 16
 17  # filter out anything outside main fontconfig path
 18  grep /usr/share/fonts/ |
 19  while read fn; do
 20  $fcquery --format '%{=pkgkit}' "${fn}" 2> /dev/null
 21  done
-

So:
$ fc-query --format '%{=pkgkit}' MiriamCLM-Bold.ttf
font(miriamclm)
font(מרים)
font(:lang=he)
font(:lang=yi)

Also:
[tasa...@localhost ~]$ rpm -q vlgothic-p-fonts
vlgothic-p-fonts-20100416-3.fc14.noarch
[tasa...@localhost ~]$ rpm -q --provides vlgothic-p-fonts | grep "ゴシック"
font(vlpゴシック)

So I guess this issue will affect other fonts related packages.

Regards,
Mamoru

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

Re: culmus-fonts packaging bug / Non-responsive maintainer

[Mamoru Tasaka]

Mamoru Tasaka wrote, at 06/02/2010 08:12 PM +9:00:
> Michael Schwendt wrote, at 06/02/2010 06:49 PM +9:00:
>> http://bugzilla.redhat.com/570819
>>
>> A ticket opened on March 5th, but Pravin Satpute just doesn't
>> respond.
>>
>> Does anyone know the languages involved here (lang=he, lang=yi)
>> and can fix this fonts package, please? Thanks in advance.
>
> I will vote that this must be fixed in yum side (or fontconfig or rpm).
>
> This provides is automatically generated by /usr/lib/rpm/fontconfig.prov
> and this reads:
> 
>   13  fcquery=/usr/bin/fc-query
>   14
>   15  [ -x $fcquery ] || exit 0
>   16
>   17  # filter out anything outside main fontconfig path
>   18  grep /usr/share/fonts/ |
>   19  while read fn; do
>   20  $fcquery --format '%{=pkgkit}' "${fn}" 2>  /dev/null
>   21  done
> -
>
> So:
> $ fc-query --format '%{=pkgkit}' MiriamCLM-Bold.ttf
> font(miriamclm)
> font(מרים)
> font(:lang=he)
> font(:lang=yi)
>
> Also:
> [tasa...@localhost ~]$ rpm -q vlgothic-p-fonts
> vlgothic-p-fonts-20100416-3.fc14.noarch
> [tasa...@localhost ~]$ rpm -q --provides vlgothic-p-fonts | grep "ゴシック"
> font(vlpゴシック)
>
> So I guess this issue will affect other fonts related packages.
>

By the way "מרים" ("\xd7\x9e\xd7\xa8\xd7\x99\xd7\x9d") itself seems a valid 
UTF-8 string.

Mamoru

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

Re: culmus-fonts packaging bug / Non-responsive maintainer

[Mamoru Tasaka]

Toshio Kuratomi wrote, at 06/02/2010 11:51 PM +9:00:
> On Wed, Jun 02, 2010 at 08:12:08PM +0900, Mamoru Tasaka wrote:
>> Michael Schwendt wrote, at 06/02/2010 06:49 PM +9:00:
>>> http://bugzilla.redhat.com/570819
>>>
>>> A ticket opened on March 5th, but Pravin Satpute just doesn't
>>> respond.
>>>
>>> Does anyone know the languages involved here (lang=he, lang=yi)
>>> and can fix this fonts package, please? Thanks in advance.
>>
>> I will vote that this must be fixed in yum side (or fontconfig or rpm).
>>
> What's a commandline I can use to reproduce the warning?  I can look at
> converting all of the data into bytes if I know how to test.

Well, I just looked at the bug and I don't know how to reproduce this
bug exactly.

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

Re: Fedora rawhide FTBFS status 2010-06-01 x86_64

[Mamoru Tasaka]

Hedayat Vatankhah wrote, at 06/04/2010 03:07 PM +9:00:
> Hi,
> My packages (rcsslogplayer and rcssmonitor) are being failed because of the 
> lack of Qt dependencies (QtNetwork requires ssl and crypto libraries from 
> openssl-devel package, and gobject-2.0 from glib2-devel). As these packages 
> are required by Qt, I think they should be added to qt-devel dependencies. 
> Should I fill a bug against Qt?
>
> Thanks,
> Hedayat
>

For now I just checked rcssmonitor and the cause for build failure is that
- While rcssmonitor explicitly uses Libs.private (from m4/qt.m4 in your source
   tarball) like
---
$ pkg-config --static --libs-only-l QtNetwork
-lQtNetwork -lssl -lcrypto -lQtCore -lpthread -lz -lm -ldl -lgthread-2.0 -lrt 
-lglib-2.0
---
qt(4)-devel does pull openssl-devel or so in.

However this is Libs.private dependency and man pkg-config says:
---
Libs.private:
This line should list any private libraries in use.  Private libraries are 
libraries which are not exposed through
your library, but are needed in the case of static linking. This differs 
from Requires.private in that  it  refer‐
ences libraries that do not have package files installed.
---
So as we don't do static linking, this should not be needed.

I tried to add
---
sed -i.nostatic \
 -e 's|--static||g' m4/qt.m4
---
and this seems to make build succeed (I just also tried the same fix for
rcsslogplayer and it succeeds)

http://koji.fedoraproject.org/koji/taskinfo?taskID=2229111
http://koji.fedoraproject.org/koji/taskinfo?taskID=2229126

Regards,
Mamoru


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

Re: nss dependency bug seems to prevent any Koji Rawhide builds from working

[Mamoru Tasaka]

Richard W.M. Jones wrote, at 06/09/2010 03:59 AM +9:00:
> The error is:
>
> DEBUG util.py:256:  nss-3.12.6-6.fc14.i686 from build has depsolving problems
> DEBUG util.py:256:-->  Missing Dependency: nss-softokn(x86-32) = 3.12.4 
> is needed by package nss-3.12.6-6.fc14.i686 (build)
> DEBUG util.py:256:  Error: Missing Dependency: nss-softokn(x86-32) = 3.12.4 
> is needed by package nss-3.12.6-6.fc14.i686 (build)
> DEBUG util.py:256:   You could try using --skip-broken to work around the 
> problem
> DEBUG util.py:256:   You could try running: package-cleanup --problems
> DEBUG util.py:256:  package-cleanup --dupes
> DEBUG util.py:256:  rpm -Va --nofiles --nodigest
>
> from:
> http://koji.fedoraproject.org/koji/getfile?taskID=2239082&name=root.log
>
> It seems like this will require rel-eng intervention, since the NSS
> maintainer couldn't even build an update to fix this :-(
>
> Rich.

Looks like for now nss-softokn-3.12.6-3.fc14 was untagged and
buildroot dependency issue is now solved.

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

Re: dist-git project update

[Mamoru Tasaka]

Peter Robinson wrote, at 06/14/2010 05:58 PM +9:00:
> On Mon, Jun 14, 2010 at 6:35 AM, Jesse Keating  wrote:
>> On Sat, 2010-06-12 at 08:22 +0200, Iain Arnell wrote:
>>> On Fri, Jun 11, 2010 at 11:57 PM, Jesse Keating  wrote:
 The current url is
 pkgs.stg.fedoraproject.org/and that works with git:// and
 ssh://.
>>>
>>> Any chance of making that work with http:// and https:// (for pushes) too?
>>>
>>
>> I hadn't planned on it.  Is there really a need for this?  Read only via
>> http is do-able, but undesirable.  Write via https is going to be a long
>> shot.
>
> I think anon git via http is essential. I use the feature all the time
> to verify things on packaged I don't maintain. I don't want to have to
> git clone every time I need to do that.
>
> Peter

And http access is useful when showing Fedora's patches to others
(e.g. to the upstream or to other distros) and discuss them.

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

Re: deluge and flags sub package

[Mamoru Tasaka]

Rahul Sundaram wrote, at 06/15/2010 04:37 AM +9:00:
> On 06/09/2010 09:08 AM, Ankur Sinha wrote:
>>
>> I'll check up this part and update the spec.
>>
>
> Since Ankur doesn't have commit access to Deluge,  I am going to be
> doing the build by tom.  Here is the latest spec
>
> http://ankursinha.fedorapeople.org/deluge/deluge.spec
>
> yell, if you find problems,  anyone.
>
> Rahul

I think such changes to split deluge package into several
subpackages like -gtk -web -console is rather a big
change and it must be done after filing a RFE bug against
the component,

(Personally as one of deluge users I don't like this complicated
  splitting. Also this spec file has packaging-related bugs
  (at least for directory ownership issue) and need fixing (and
  this is one of the reasons I don't like this type of packaging))

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

Re: deluge and flags sub package

[Mamoru Tasaka]

Mamoru Tasaka wrote, at 06/15/2010 04:51 AM +9:00:
> Rahul Sundaram wrote, at 06/15/2010 04:37 AM +9:00:
>> On 06/09/2010 09:08 AM, Ankur Sinha wrote:
>>>
>>> I'll check up this part and update the spec.
>>>
>>
>> Since Ankur doesn't have commit access to Deluge,  I am going to be
>> doing the build by tom.  Here is the latest spec
>>
>> http://ankursinha.fedorapeople.org/deluge/deluge.spec
>>
>> yell, if you find problems,  anyone.
>>
>> Rahul
>
> I think such changes to split deluge package into several
> subpackages like -gtk -web -console is rather a big
> change and it must be done after filing a RFE bug against
> the component,
>
> (Personally as one of deluge users I don't like this complicated
>splitting. Also this spec file has packaging-related bugs
>(at least for directory ownership issue) and need fixing (and
>this is one of the reasons I don't like this type of packaging))

Also currently I cannot guess what happens if just "yum update"
is executed. If only deluge-common (in this spec file) is to be
installed, many users may complain "why deluge gtk cannot be found
anymore?"

Anyway I think filing a bug is needed beforehand.

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

About mass-piled bugs for gtk-doc dependency

[Mamoru Tasaka]

Dear all:

Please don't fix your packages for this issue until enough discussion
is done on fedora-packaging mailing list.
https://bugzilla.redhat.com/show_bug.cgi?id=604169

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

Re: rawhide report: 20100622 changes

[Mamoru Tasaka]

> Compose started at Tue Jun 22 08:15:10 UTC 2010

> Broken deps for i386
> --

>   ruby-RMagick-2.13.1-1.fc14.2.i686 requires ImageMagick = 0:6.6.2.1

> ImageMagick-6.6.0.2-9.fc14
> --
> * Tue Jun 01 2010 Marcela Maslanova  - 6.6.0.2-9
> - Mass rebuild with perl-5.12.0

Well, it seems that with the retag of packages rebuilt for perl-5.12.0,
ImageMagick was downgraded implicitly.
The "latest" ImageMagick is 6.6.2.1-10.fc14:
http://koji.fedoraproject.org/koji/buildinfo?buildID=176226
However koji says the latest dist-f14 ImageMagick is ImageMagick-6.6.0.2-9.fc14:

$ koji latest-pkg dist-f14 ImageMagick
Build Tag   Built by
    
ImageMagick-6.6.0.2-9.fc14dist-f14  mmaslano

Can we query what packages were "downgraded" due to this mass 
perl-5.12.0-rebuild
retag?

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

Re: rawhide report: 20100622 changes

[Mamoru Tasaka]

Ralf Corsepius wrote, at 06/23/2010 03:16 PM +9:00:
> On 06/23/2010 06:50 AM, Jesse Keating wrote:
>> On Wed, 2010-06-23 at 02:25 +0900, Mamoru Tasaka wrote:
>>> Can we query what packages were "downgraded" due to this mass
>>> perl-5.12.0-rebuild
>>> retag?
> In most occasions, his would not be sufficient. You would have to
> rebuild them.

Just record that the package discussed here (ImageMagick) is not
my package, however I just rebuilt it.

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

Re: Firefox conflicts xulrunner

[Mamoru Tasaka]

Frank Murphy wrote, at 06/24/2010 05:13 PM +9:00:
> Are these not symbiotic?
>
>
> Resolving Dependencies
> -->  Running transaction check
> --->  Package firefox.x86_64 0:3.6.3-4.fc14 set to be installed
> -->  Processing Conflict: firefox-3.6.3-4.fc14.x86_64 conflicts xulrunner
>> = 1.9.2.4
> -->  Finished Dependency Resolution
>

firefox-3.6.3-4.fc14 has "Conflicts: xulrunner >= 1.9.2.4".
Should be fixed in next firefox:
http://koji.fedoraproject.org/koji/buildinfo?buildID=179343

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

Re: rawhide report: 20100625 changes

[Mamoru Tasaka]

Richard Jones wrote, at 06/25/2010 10:40 PM +9:00:
> Sorry, I'm away from the office this week and don't have access
> to my email, but I noticed:
>
>> 1:libguestfs-1.3.8-2.fc14.i686 requires [etc]
>
> This is really strange because the latest libguestfs package built in
> Rawhide is 1.3.21, see:
>
> http://koji.fedoraproject.org/koji/packageinfo?packageID=8391
>
> Version 1.3.8 is from months ago and it looks like somehow it has
> magically resurfaced.
>
> So I've no idea what's going on here, but something is very wrong.
>
> Rich.

You are seeing the same issue as this (i.e. related to perl-5.12.0 rebuild
retag)
http://lists.fedoraproject.org/pipermail/devel/2010-June/137816.html

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

Re: samba4 NVR koji issue

[Mamoru Tasaka]

Ralf Corsepius wrote, at 06/28/2010 02:53 PM +9:00:
> Hi,
>
> The samba4 package in rawhide would need a rebuild for perl-5.12.x.
> However building fails with strange error message[1]:
>
> samba4-4.0.0-23.alpha11.fc14.2 (180065) failed on
> ppc06.phx2.fedoraproject.org (noarch):
> pg.DatabaseError: error 'ERROR:  duplicate key value violates unique
> constraint "rpminfo_unique_nvra"
> ' in 'INSERT INTO rpminfo (id,name,version,release,epoch,
>   build_id,arch,buildtime,buildroot_id,
>   external_repo_id,
>   size,payloadhash)
>   VALUES (2040153,'libldb','0.9.10','23.fc14',NULL,
>   180065,'x86_64',1277703280,817980,
>   0,
>   92284,'d6b89d2b4392b352ca380da7b2565b13')
>
> Any explanation? How to fix this?
>
> Ralf
>
> [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=2276457

rawhide samba4.spec says;

  1  %define main_release 23

 13  %define samba4_release %{main_release}.%{pre_release}%{?dist}

 16  %define talloc_release %{main_release}%{?dist}
 17  %define tdb_release %{main_release}%{?dist}
 18  %define tevent_release %{main_release}%{?dist}
 19  %define ldb_release %{main_release}%{?dist}

 43  Name: samba4
 44  Version: %{samba4_version}
 45  Release: %{samba4_release}.2

263  %package -n libldb
267  Release: %{ldb_release}
--

So %ldb_release has not changed since the previous build and koji raises
error. Changing %main_release will fix the error.

Mamoru

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

Re: who is Petr Pisar from redhat ?

[Mamoru Tasaka]

Chitlesh GOORAH wrote, at 07/02/2010 04:09 AM +9:00:
> Hello there,
>
> I would appreciate if someone else who is NEITHER a co-maintainer NOR
> FESCo member don't version bump my packages, without notifying me.
>
> Petr Pisar seems to mess with my packages.
>
> It's simply disgusting !!
>
> Chitlesh !

Apart from politeness, I want to clarify what actually occurred here:

Perhaps Chitlesh complained about this change:
http://lists.fedoraproject.org/pipermail/scm-commits/2010-May/433306.html
http://cvs.fedoraproject.org/viewvc/rpms/perl-SystemPerl/devel/?pathrev=perl-SystemPerl-1_334-1_fc14

However, looking carefully:
---
Author: mmaslano  <

Update of /cvs/pkgs/rpms/perl-SystemPerl/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv26946

Modified Files:
.cvsignore perl-SystemPerl.spec sources
Log Message:
* Thu May 13 2010 Petr Pisar  - 1.334-1
- Version bump
- Disable parallel make (https://rt.cpan.org/Public/Bug/Display.html?id=57469)
---
So the actually committer is not ppisar but mmaslano.
Actually as far as I checked the pkgdb / FAS, ppisar does not have any acls
for perl-SystemPerl.

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

Re: who is Petr Pisar from redhat ?

[Mamoru Tasaka]

Kalev Lember wrote, at 07/02/2010 05:51 PM +9:00:
> On 07/02/2010 11:35 AM, Mamoru Tasaka wrote:
>> Chitlesh GOORAH wrote, at 07/02/2010 04:09 AM +9:00:
>>> Hello there,
>>>
>>> I would appreciate if someone else who is NEITHER a co-maintainer NOR
>>> FESCo member don't version bump my packages, without notifying me.
>>>
>>> Petr Pisar seems to mess with my packages.
>>>
>>> It's simply disgusting !!
>>>
>>> Chitlesh !
>>
>> Apart from politeness, I want to clarify what actually occurred here:
>>
>> Perhaps Chitlesh complained about this change:
>> http://lists.fedoraproject.org/pipermail/scm-commits/2010-May/433306.html
>> http://cvs.fedoraproject.org/viewvc/rpms/perl-SystemPerl/devel/?pathrev=perl-SystemPerl-1_334-1_fc14
>
> Lets see if I got this right:
> 2009-09-15 chitlesh updates to 1.331, build fails
> 2009-12-07 kasal does mass perl 5.10.1 rebuild, build fails
> 2010-05-12 mmaslano does mass perl 5.10.2 rebuild, build fails
> 2010-05-14 mmaslano checks in ppisar's change which fixes the build
> 2010-07-01 chitlesh sends this mail

It seems so.
http://koji.fedoraproject.org/koji/packageinfo?packageID=8618

> So, the build was broken for 8 months, then mmaslano (a provenpackager)
> checked in a fix. After another 7 weeks, Chitlesh finally notices
> someone has fixed the package and says its disgusting.
>

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

Re: Need help for Gimp 2.7.1

[Mamoru Tasaka]

Luya Tshimbalanga wrote, at 07/03/2010 07:10 PM +9:00:
> Hello,
>
> I attempted to build a new version of Gimp 2.7.1 using Koji scratch method but
> ended up with that result[1]. Here is attached spec file borrowed from Nils 
> as I
> wanted to experiment that version along with Design. Can anyone check what 
> went
> wrong.
>
> Thanks
>
>
> [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=2291828
>

build.log says:
-
extracting debug info from 
/builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimpbase-2.0.so.0.701.0
extracting debug info from 
/builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimpcolor-2.0.so.0.701.0
extracting debug info from 
/builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimpmath-2.0.so.0.701.0
extracting debug info from 
/builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimpconfig-2.0.so.0.701.0
extracting debug info from 
/builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimpmodule-2.0.so.0.701.0
extracting debug info from 
/builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimpthumb-2.0.so.0.701.0
extracting debug info from 
/builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimpwidgets-2.0.so.0.701.0
extracting debug info from 
/builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimp-2.0.so.0.701.0
extracting debug info from 
/builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimpui-2.0.so.0.701.0
--

So it seems that %minorver macro needs changing.

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

Re: rpms/shared-mime-info/devel shared-mime-info.spec,1.84,1.85

[Mamoru Tasaka]

Colin Walters wrote, at 07/04/2010 03:23 AM +9:00:
> Author: walters
>
> Update of /cvs/pkgs/rpms/shared-mime-info/devel
> In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv21405
>
> Modified Files:
>   shared-mime-info.spec
> Log Message:
> * Sat Jul  3 2010 Colin Walters  - 0.71-3
> - Requires(pre) on glib, since update-mime-database uses it

Why is this needed, although calling update-mime-database appears in
%post scriptlet?

Regards,
Mamoru

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

Re: rpms/shared-mime-info/devel shared-mime-info.spec,1.84,1.85

[Mamoru Tasaka]

Colin Walters wrote, at 07/06/2010 11:29 PM +9:00:
> On Sat, Jul 3, 2010 at 2:40 PM, Mamoru Tasaka
>   wrote:
>> Colin Walters wrote, at 07/04/2010 03:23 AM +9:00:
>>> Author: walters
>>>
>>> Update of /cvs/pkgs/rpms/shared-mime-info/devel
>>> In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv21405
>>>
>>> Modified Files:
>>>shared-mime-info.spec
>>> Log Message:
>>> * Sat Jul  3 2010 Colin Walters- 0.71-3
>>> - Requires(pre) on glib, since update-mime-database uses it
>>
>> Why is this needed, although calling update-mime-database appears in
>> %post scriptlet?
>
> Ah, it should be Requires(post) I guess?

If you want to avoid potential dependency loop, it should be
Requires(post).

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

Re: Help with Koji error: "error: possibly undefined macro: AS_MESSAGE_LOG_FDdnl"

[Mamoru Tasaka]

Richard W.M. Jones wrote, at 07/07/2010 02:42 AM +9:00:
> I get this build failure trying to build vhostmd:
>
> http://koji.fedoraproject.org/koji/taskinfo?taskID=2298698
>
> http://koji.fedoraproject.org/koji/getfile?taskID=2298704&name=build.log
>
> + autoreconf
> configure:11354: error: possibly undefined macro: AS_MESSAGE_LOG_FDdnl
>If this token and others are legitimate, please use m4_pattern_allow.
>See the Autoconf documentation.
> autoreconf: /usr/bin/autoconf failed with exit status: 1
>
> I can't reproduce it locally on my nearly up to date Rawhide machine,
> and the literal string 'AS_MESSAGE_LOG_FDdnl' doesn't appear anywhere
> in the source.  The fact that 'dnl' immediately follows 'AS_MESSAGE_LOG_FD'
> might imply some sort of corruption of some m4 file.
>
> No ideas ...  anyone?
>
> Rich.
>

I already files this issue (for now) against autoconf:

https://bugzilla.redhat.com/show_bug.cgi?id=611781
PKG_CHECK_MODULES macro fails with autoconf 2.66 (perhaps)

It seems this issue was also reported on autoconf mailing list:
http://lists.gnu.org/archive/html/autoconf/2010-07/msg00011.html

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

Re: webkitgtk abi bump

[Mamoru Tasaka]

Michel Alexandre Salim wrote, at 07/05/2010 10:04 AM +9:00:
> On Fri, Jul 2, 2010 at 4:36 PM, Matthias Clasen  wrote:
>> Just a headsup: I've just built webkitgtk-1.3.2 in rawhide, which
>> changes library sonames, so things depending on it will have to be
>> rebuilt.
> ...
>> seed
> Does not build right now due to the reorganization of files in
> gtk2-2.21.x for parallel installation with gtk3; it looks like some
> gtk2 headers still expect to find gdk-pixbuf in its old place.
>
> In file included from /usr/include/gtk-2.0/gdk/gdkcairo.h:28,
>   from /usr/include/gtk-2.0/gdk/gdk.h:33,
>   from seed-cairo.c:22:
> /usr/include/gtk-2.0/gdk/gdkpixbuf.h:37:35: error:
> gdk-pixbuf/gdk-pixbuf.h: No such file or directory
>
> Filed as https://bugzilla.redhat.com/show_bug.cgi?id=611364 with a
> minimal test case.
>
> Thanks,
>

Now seed is rebuild with new webkitgtk (fix is in gtk2), the details is in
the above bug report.

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

Re: glibc heads up

[Mamoru Tasaka]

Richard W.M. Jones wrote, at 07/22/2010 03:45 PM +9:00:
> On Wed, Jul 21, 2010 at 10:54:32AM -0500, Dennis Gilmore wrote:
>> right now a glibc build is going on that has --enablekernel=2.6.32
>>
>> from Jakub
>>
>> Bumping that from 2.6.18 used currently means e.g. to get rid of compat
>> bloat for private futexes, utimensat, fallocate, O_CLOEXEC/pipe2 etc. (lots
>> of cloexec/nonblocking stuff), ADJ_OFFSET_SS_READ, accept4, realtime clocks
>> in futexes, missing AT_RANDOM, preadv/pwritev, F_GETOWN_EX.
>>
>> Especially private futexes and the cloexec/nonblock stuff affects quite a
>> lot of glibc code.
>
> At least it'll indirectly "fix" the broken preadv emulation bug:
>
> http://www.mail-archive.com/qemu-de...@nongnu.org/msg25242.html
>
>> what this does mean is that you can no longer use rhel5 to build  fedora 14
>> and newer packages.  though you had to jump though hoops already to do this
>
> Won't this break Koji builds?  I thought they were still done on
> RHEL 5.
>
> Rich.
>

Well, as I firstly thought so, I tried scratch build with adding "uname -a" and
it returned the below, for example.

Linux x86-09.phx2.fedoraproject.org 2.6.32-44.el6.x86_64 #1 SMP Wed Jul 7 
15:47:50 EDT 2010 i686 i686 i386 GNU/Linux

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

Re: Partial mass rebuild for Python 2.7 coming soon (I hope)

[Mamoru Tasaka]

Jeff Spaleta wrote, at 07/22/2010 03:11 PM +9:00:
> On Wed, Jul 21, 2010 at 10:00 PM, David Malcolm  wrote:
>> - numpy is segfaulting during %check; am waiting on a gdb build to
>> finish (linked against 2.7) before I debug; this blocks pygtk2 which
>> blocks various things
>
> Sigh... of course it does.  Since numpy pretty much blocks all the
> packages important to me personally that I maintain...shoot me a
> pointer to the failure logs if you need help tracking this down.
>
> -jef

build.log on koji can be found at:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2337411

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

Re: Python 2.7 rebuild: maintainer help needed (please!)

[Mamoru Tasaka]

David Malcolm wrote, at 07/24/2010 03:07 AM +9:00:
> mtasaka (1):
> wallpapoz 

Was waiting for gnome-python2 rebuild. Now succeeded.
http://koji.fedoraproject.org/koji/buildinfo?buildID=186114

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

Re: Seeking to merge python 2.7 into rawhide

[Mamoru Tasaka]

David Malcolm wrote, at 07/27/2010 10:27 AM +9:00:
> Current status: 114 failing builds
> http://dmalcolm.fedorapeople.org/python-packaging/failures-2010-07-26-02.html
>
> See also the notes on:
> https://fedoraproject.org/wiki/Features/Python_2.7#Current_status
>
> Many of these appear to be pre-existing FTBFS; as far as I can make out,
> the #includes for parts of the GTK stack are substantially broken in
> rawhide.
>
> Can we get all of the hundreds of successful builds into rawhide before
> it drifts further?
>
> Dave
>

By the way, it seems that in your list, the packages which don't have
"Requires: python(abi) = 2.6" dependency but have dependency for
"libpython2.6.so.1.0" are missing.

For example:
libpeas:
http://koji.fedoraproject.org/koji/packageinfo?packageID=10531
vim-enhanced:
http://koji.fedoraproject.org/koji/packageinfo?packageID=216

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

Re: rpms/python-sexy/devel python-sexy-gdk-pixbuf.patch, NONE, 1.1 python-sexy.spec, 1.15, 1.16

[Mamoru Tasaka]

Orcan Ogetbil wrote, at 07/28/2010 02:44 PM +9:00:
> Author: oget
>
> Update of /cvs/pkgs/rpms/python-sexy/devel
> In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv31418
>
> Modified Files:
>   python-sexy.spec
> Added Files:
>   python-sexy-gdk-pixbuf.patch
> Log Message:
> * Wed Jul 28 2010 Orcan Ogetbil  - 0.1.9-12
> - Fix gdk-pixbuf header location issue on F-14
>

I think this should be fixed in pygtk2, not in python-sexy.

The previous build (which failed) was:
http://koji.fedoraproject.org/koji/buildinfo?buildID=185665
build.log says:
---
  gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/python2.7 -pthread 
-I/usr/include/pygtk-2.0 -I/usr/lib64/libffi-3.0.9/include 
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -pthread 
-I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include 
-I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 
-I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 
-I/usr/include/libpng12 -I/usr/include/libxml2 -O2 -g -pipe -Wall 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -m64 -mtune=generic -c sexy.c  -fPIC -DPIC -o 
.libs/sexy_la-sexy.o
In file included from /usr/include/gtk-2.0/gdk/gdkcairo.h:28:0,
  from /usr/include/gtk-2.0/gdk/gdk.h:33,
  from /usr/include/gtk-2.0/gtk/gtk.h:32,
  from /usr/include/pygtk-2.0/pygtk/pygtk.h:8,
  from sexy.override:8:
/usr/include/gtk-2.0/gdk/gdkpixbuf.h:37:35: fatal error: 
gdk-pixbuf/gdk-pixbuf.h: No such file or directory
---

The cflags used here comes from "pkg-config --cflags pygtk-2.0 libsexy". The 
problem
here is that (as seen in this build.log) pygtk2 header file 
(/usr/include/pygtk-2.0/pygtk/pygtk.h)
tries to include header file in gtk2, however
- pygtk-2.0.pc says
-
Requires: pygobject-2.0
-
- pygobject-2.0.pc says
-
Requires: gobject-2.0
-
So needed gdk-pixbuf headers cannot be included.

I think pygtk-2.0.pc should have "Requires: pygobject-2.0 gtk-2.0".

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

Re: rpms/python-sexy/devel python-sexy-gdk-pixbuf.patch, NONE, 1.1 python-sexy.spec, 1.15, 1.16

[Mamoru Tasaka]

Orcan Ogetbil wrote, at 07/28/2010 03:19 PM +9:00:
> On Wed, Jul 28, 2010 at 2:09 AM, Mamoru Tasaka wrote:
>> Orcan Ogetbil wrote, at 07/28/2010 02:44 PM +9:00:
>>>
>>> Author: oget
>>>
>>> Update of /cvs/pkgs/rpms/python-sexy/devel
>>> In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv31418
>>>
>>> Modified Files:
>>> python-sexy.spec
>>> Added Files:
>>> python-sexy-gdk-pixbuf.patch
>>> Log Message:
>>> * Wed Jul 28 2010 Orcan Ogetbil-
>>> 0.1.9-12
>>> - Fix gdk-pixbuf header location issue on F-14
>>>
>>
>> I think this should be fixed in pygtk2, not in python-sexy.
>>
>
> Yes, you are most probably right. Sorry, I had a few other packages
> that depend on python-sexy, so I wanted to get it fixed asap. So many
> python packages are flying around my head... Maybe I need some sleep.
> I'll correct this tomorrow in case someone else doesn't. Feel free to
> fix it.
>
> Thanks for the warning.
>
> Orcan
>

Yes, actually python-sexy is one of the packages which prevents me
from updating python 2.7 on my box.

For pygtk2 issue, I filed:
https://bugzilla.redhat.com/show_bug.cgi?id=618944

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

Re: fedora-packager and Python 2.7 problem

[Mamoru Tasaka]

Richard W.M. Jones wrote, at 07/30/2010 09:22 PM +9:00:
>
> Because of the Python 2.7 transition, it's not possible at the moment
> to install fedora-packager (or for me to fix the problems, because I
> can't check in stuff).
>
> It appears there are only 1 package which is causing all the issues:
>
> $ sudo yum --enablerepo=koji --exclude="*.i686" install fedora-packager
> [...]
> Error: Package: notify-python-0.1.1-8.fc12.x86_64 (fedora)
> Requires: python(abi) = 2.6
> Removing: python-2.6.5-2.fc14.x86_64 (@koji/12)
> Available: compat-python24-2.4.6-1.fc13.x86_64 (rpmfusion-free)
> Available: python-2.6.4-20.fc13.x86_64 (fedora)
> Installing: python-2.7-7.fc14.x86_64 (koji)
> Available: python3-3.1.2-6.fc13.x86_64 (updates-testing)
> Available: python3-3.1.2-12.fc14.x86_64 (koji)
>
> Rich.
>

Well, I think what prevents notify-python from being rebuilt
against notify-python is in pygtk2 side (see bug 618944 I have filed), the
workaround exists. Should the workaround be applied for now?

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

Re: fedora-packager and Python 2.7 problem

[Mamoru Tasaka]

Mamoru Tasaka wrote, at 07/30/2010 09:30 PM +9:00:
> Richard W.M. Jones wrote, at 07/30/2010 09:22 PM +9:00:
>>
>> Because of the Python 2.7 transition, it's not possible at the moment
>> to install fedora-packager (or for me to fix the problems, because I
>> can't check in stuff).
>>
>> It appears there are only 1 package which is causing all the issues:
>>
>> $ sudo yum --enablerepo=koji --exclude="*.i686" install fedora-packager
>> [...]
>> Error: Package: notify-python-0.1.1-8.fc12.x86_64 (fedora)
>>  Requires: python(abi) = 2.6
>>  Removing: python-2.6.5-2.fc14.x86_64 (@koji/12)
>>  Available: compat-python24-2.4.6-1.fc13.x86_64 (rpmfusion-free)
>>  Available: python-2.6.4-20.fc13.x86_64 (fedora)
>>  Installing: python-2.7-7.fc14.x86_64 (koji)
>>  Available: python3-3.1.2-6.fc13.x86_64 (updates-testing)
>>  Available: python3-3.1.2-12.fc14.x86_64 (koji)
>>
>> Rich.
>>
>
> Well, I think what prevents notify-python from being rebuilt
> against notify-python is in pygtk2 side (see bug 618944 I have filed), the
> workaround exists. Should the workaround be applied for now?

Oops, I meant "from being rebuilt againt python 2.7".

Mamoru

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

Re: fedora-packager and Python 2.7 problem

[Mamoru Tasaka]

Orcan Ogetbil wrote, at 07/30/2010 09:36 PM +9:00:
> On Fri, Jul 30, 2010 at 8:30 AM, Mamoru Tasaka wrote:
>> Richard W.M. Jones wrote, at 07/30/2010 09:22 PM +9:00:
>>>
>>> Because of the Python 2.7 transition, it's not possible at the moment
>>> to install fedora-packager (or for me to fix the problems, because I
>>> can't check in stuff).
>>>
>>> It appears there are only 1 package which is causing all the issues:
>>>
>>> $ sudo yum --enablerepo=koji --exclude="*.i686" install fedora-packager
>>> [...]
>>> Error: Package: notify-python-0.1.1-8.fc12.x86_64 (fedora)
>>>  Requires: python(abi) = 2.6
>>>  Removing: python-2.6.5-2.fc14.x86_64 (@koji/12)
>>>  Available: compat-python24-2.4.6-1.fc13.x86_64 (rpmfusion-free)
>>>  Available: python-2.6.4-20.fc13.x86_64 (fedora)
>>>  Installing: python-2.7-7.fc14.x86_64 (koji)
>>>  Available: python3-3.1.2-6.fc13.x86_64 (updates-testing)
>>>  Available: python3-3.1.2-12.fc14.x86_64 (koji)
>>>
>>> Rich.
>>>
>>
>> Well, I think what prevents notify-python from being rebuilt
>> against notify-python is in pygtk2 side (see bug 618944 I have filed), the
>> workaround exists. Should the workaround be applied for now?
>>
>
> I vote +1.
>
> This package is vital. We need to get things going.
>
> Orcan

Well, workaround added in notify-python-0.1.1-13.fc1{4,5}. For F-14
I submitted push request.

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

Massive broken deps and tagging into dist-f14?

[Mamoru Tasaka]

Hello, all:

This morning I receided massive broken deps on F-14 and then received
massive mails of tagging into dist-f14 tree. Can I assume that
I can ignore these broken deps report or there is something I have
to do for this?

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

Re: Massive broken deps and tagging into dist-f14?

[Mamoru Tasaka]

Jesse Keating wrote, at 07/31/2010 11:36 AM +9:00:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 7/30/10 7:13 PM, Mamoru Tasaka wrote:
>> This morning I receided massive broken deps on F-14 and then received
>> massive mails of tagging into dist-f14 tree. Can I assume that
>> I can ignore these broken deps report or there is something I have
>> to do for this?
>>
>
> Yes, you can ignore this.  It was my fault.  Tomorrow a better compose
> should go through.
>

Thank you.

Now another question for tag issue. Currently how is it going about
the inheritance of "dist-rawhide" tag?

About pygtk2 618944 bug I saw Toshio rebuilt pygtk2-0.17.0-7.fc14,
however I firstly thought that this new pkg was not rebuild for rawhide
yet because:

[tasa...@localhost ~]$ koji latest-pkg dist-f14-build pygtk2
Build Tag   Built by
    
pygtk2-2.17.0-7.fc14  dist-f14-override toshio
[tasa...@localhost ~]$ koji latest-pkg dist-rawhide pygtk2
Build Tag   Built by
    
pygtk2-2.17.0-6.fc14  dist-f14  dmalcolm

So I tried to rebuild pygtk2 also on "rawhide" but it failed with koji's
reporting that "it already exists". Actually:
[tasa...@localhost ~]$ koji latest-pkg dist-f15 pygtk2
Build Tag   Built by
    
pygtk2-2.17.0-7.fc15  dist-f15  toshio

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

Re: Massive broken deps and tagging into dist-f14?

[Mamoru Tasaka]

Michael Schwendt wrote, at 07/31/2010 05:44 PM +9:00:
> On Sat, 31 Jul 2010 11:13:49 +0900, Mamoru wrote:
>
>> Hello, all:
>>
>> This morning I receided massive broken deps on F-14 and then received
>> massive mails of tagging into dist-f14 tree. Can I assume that
>> I can ignore these broken deps report or there is something I have
>> to do for this?
>
> Why did we receive mails about tagging into dist-f14?
>
> | qosmic-1.4.2-4.fc13 successfully tagged into dist-f14 by jkeating
>
> I'm not subscribed to that package in koji, and I'm not a comaintainer
> of it either.

I guess because you built it (that EVR).

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

Re: f14 boost-1.44.0 upgrade: pushed

[Mamoru Tasaka]

Neal Becker wrote, at 08/01/2010 08:07 PM +9:00:
> Benjamin Kosnik wrote:
>
>>
>> The boost maintainers have updated the boost package to the current
>> release (1.44.0) in rawhide for F14. More info here:
>>
>> https://fedoraproject.org/wiki/Features/F14Boost144
>>
>> Rebuilds for devel packages that require boost are mandatory, as SONAME
>> was bumped. Help from package maintainers with rebuilding packages with
>> boost dependencies is appreciated.
>>
>> -benjamin
>
> The current release is 1.43
>
>

https://bugzilla.redhat.com/show_bug.cgi?id=607615
http://www.boost.org/development/index.html
say that the formal boost 1.44 is to be released tomorrow.

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

Re: F-14 Branched report: 20100802 changes

[Mamoru Tasaka]

Stephen Gallagher wrote, at 08/03/2010 01:24 AM +9:00:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>>  python-recaptcha-client-1.0.5-3.fc14.noarch requires python(abi) = 0:2.6
>
> This has been built in Koji since July 30th (1)
>
> Why is it not making it into composes?
>
>
> (1) http://koji.fedoraproject.org/koji/buildinfo?buildID=186994

This is the report for F-14 tree, not rawhide (F-15).

Regards,
Mamoru

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

Re: Heads up: glibmm/gtkmm now requires -std=c++11

[Mamoru TASAKA]

Kalev Lember wrote on 09/23/2015 09:35 AM:

Hi,

A quick heads up to anybody who might run into cryptic build errors when
building apps that use glibmm/gtkmm:

Latest glibmm/gtkmm stack in rawhide and F23 now uses C++11 features in
header files. This means when building other programs that use those
headers, the C++ compiler needs to be in C++11 mode now.

The fix is simple: make sure -std=c++11 is passed to the compiler.

It can be done in either in upstream build scripts or hacked in
downstream in spec files. I would usually always suggest to go for
upstreamable fixes, but I think in this case it's fine to do it
downstream as well. The reason is that the workaround is just a
temporary measure until GCC switches to use C++11 by default, which is
probably going to happen in F24 when GCC 6 lands.

Here's an example how to do it in a spec file:
http://pkgs.fedoraproject.org/cgit/inkscape.git/commit/?id=fc745c8687dd8a362235340bd3481ff18925dbaf

And here's how to do it in an upstreamable way:
https://git.gnome.org/browse/gnome-system-monitor/commit/?id=e5d3ac014d7acc73c5f508a937c5656ffa8f08ad
or
https://git.gnome.org/browse/gnome-system-monitor/commit/?id=d81fe60bc3d6a481b6bc330490fd079b5cc30acc


Rather, can't be pkgconfig file in gtkmm30 modified for now to add -std=c++11
to Cflags?

Regards,
Mamoru


--
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: Some orphaned packages

[Mamoru TASAKA]

Hello:

Toshio Kuratomi wrote on 08/15/2014 02:01 AM:

As some of you may know from flock or following the FPC meeting minutes, I'm
taking a break from Fedora.  As part of that, I've reassigned most of my
packages to others that can  care for them.  A few packages don't have
obvious owners (mostly in specific branches) So I've orphaned them.  If
you'd like to pick them up, please go to the pkgdb and do so:





gprof2dot => orphan


Taken.

Mamoru

--
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: Versioning preloader

[Mamoru TASAKA]

Hello:

> I am packaging proxychains-ng[1] which make use of the .so file by its
> preloader only, and is not for any usable development. Hence, the
> upstream maintainer does not want[2] to version this .so file.
> 
> To inhibit the rpmlint's unversioned so file warning, I have currently
> written a patch, and making use of it while packaging. But, I was
> wondering of any other alternatives that we might have here.
> 
> Any ideas ? Or should I stick with the patch ?
> 
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1147013
> [2] https://github.com/rofl0r/proxychains-ng/issues/46
> 

I wrote some comments.

Regards,
Mamoru


-- 
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: gdk-pixbuf2 package splitting

[Mamoru TASAKA]

Hello:

Richard Hughes wrote on 03/20/2015 11:51 PM:

I've just pushed two new gdk-pixbuf2 builds to rawhide *not* F22.

* The first splits out the modules (e.g. the ico, jpeg, gif loaders)
to a separate subpackage called gdk-pixbuf2-modules -- which we'll
certainly need on workstation but really not on cloud or text-only
installs
* The second splits out the xlib code which hasn't been touched
upstream since about 2008. It's the only thing that drags in half of
Xorg onto the cloud image thanks to the
PackageKit->AppStreamGlib->GdkPixbuf dep chain.



Looking at gdk-pixbuf2-2.31.3-3.fc23, gdk-pixbuf2-xlib-devel
contains pkgconfig files, libgdk_pixbuf_xlib-2.0.so symlink but no headers?
So how can we know what API (functions) needs -lgdk_pixbuf_xlib-2.0
linking when using them?

i.e. Looks like /usr/include/gdk-pixbuf-2.0/gdk-pixbuf-xlib/ should also be
moved to gdk-pixbuf2-xlib-devel.



For the first change I'm also going to add the -modules dep to gtk2
and gtk3 so we just do the right thing on upgrades. For the second I
think everything should be okay without any rebuilds, as rpm will be
able to drag on the right subpackage for the
libgdk_pixbuf_xlib-2.0.so.0()(64bit) dep.

The second change has the potential to break the following packages if
they are not using pkgconfig-style deps:

alltray-0:0.71b-8.fc21.x86_64
camorama-0:0.19-14.fc21.x86_64
icewm-0:1.3.8-4.fc21.x86_64
libreoffice-core-1:4.3.2.2-5.fc21.x86_64
sawfish-0:1.11-1.fc21.x86_64
superkb-0:0.22-6.fc21.x86_64
w3m-img-0:0.5.3-18.fc21.x86_64
xscreensaver-base-1:5.32-10.fc21.x86_64

I'm going to go through the list now and make sure everything still builds fine.

Richard.



Regards,
Mamoru

--
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: Removing packages that have broken dependencies in F22 tree

[Mamoru TASAKA]

Vít Ondruch wrote on 04/28/2015 11:52 PM:

Dne 28.4.2015 v 11:35 Kalev Lember napsal(a):

On 04/28/2015 10:16 AM, Vít Ondruch wrote:

Dne 28.4.2015 v 00:45 Kalev Lember napsal(a):

rubygem-rugged  tdawson


I am not maintainer of this, but please do not remove this. Rugged was
broken by unannounced libgit2 update and there is still not official
release fixing the compatibility. Removing this rubygem will mean just
more work for everybody involved.

libgit2 is at 0.22.2 and looks like there's a matching new Rugged
release at https://rubygems.org/gems/rugged/versions/0.22.1b1 and the
package just needs updating. I am not sure what's up with the
maintainer, but maybe you could help them out by comaintaining
rubygem-rugged?


If you take a look on version history [1],  you'll notice that the "b"
in version stands for beta. I have not checked with upstream what is the
plan, though.

[1] https://rubygems.org/gems/rugged/versions


But this is branched as "maint/v0.22", and I think using this beta
is much preferable than to keep broken deps, thought?

By the way, I am not a maintainer of rubygem-rugged, either, and
I don't use rubygem-rugged (currently). Anyway I want to know
how the current maintainer think of the current status.
If the current maintainer has no interest on this package,
maybe it is better to get this retired.



When it comes to shipping F22, I don't think it makes sense to include a
package that is so horribly broken that it cannot even be installed. But
if you guys are actively working on fixing it, I am sure we can try and
convince releng to give it a few more days before blocking so that it
can be pulled in through the freeze through the FE process:
https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

Also, please note that Fedora policies allow adding new packages in the
updates repo, so even if something gets dropped now, it can always be
fixed and shipped in the updates repo at a later date.



Which means re-review ...

Vít



Regards,
Mamoru
--
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: Package name for EPEL7 branch

[Mamoru TASAKA]

Hello:

Greg Hellings wrote on 01/14/2016 01:30 PM:

I'm working with a package (rubygem-minitest) which already exists in
the core EL packages on the 4.x series. In order to enable a whole
slew of new packages to be created in EPEL7, it will be necessary to
package the 5.x series. However, since we don't want to mask the EL
package it has been proposed and agreed to that the EPEL package be
named rubygem-minitest5.

In order to bring this about, would I need to submit a Review Request
for a new package named rubygem-minitest5 and go through the normal
new package process? Or is there an expedited way I can just get
rubygem-minitest5 added to the tags for epel7 in koji?

--Greg


If you would accept review swap, when you submit a review request
I can review it.

Regards,
Mamoru

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Retiring packages due to broken deps

[Mamoru TASAKA]

Tom Callaway wrote, at 11/14/2012 02:26 AM +9:00:

Since the following packages seem to be unmaintained and have broken
deps in Fedora 18, I propose that they be retired and blocked before
release:

ruby-revolution


Currently waiting for the upstream reply.


Additionally, these packages are already retired in Rawhide, I propose
that they also be blocked in Fedora 18:

rubygem-linecache
rubygem-ruby-debug
rubygem-ruby-debug-base


https://fedorahosted.org/rel-eng/ticket/5388

Regards,
Mamoru


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

RE: %ifarch note

[Mamoru TASAKA]

> Since I hit this, I'd imagine other people might.
> If your package has:
> 
> BuildArch: noarch
> 
> It will set %{_target_cpu} to "noarch".
> 
> If you also use %ifarch in that spec file, you might be expecting it to
> match %{_arch} (the architecture of the build server). It does not. It
> matches %{_target_cpu}.
> 
> If you need to conditionalize on the value of %{_arch} in such a spec
> file, you need to do it explicitly:
> 
> %if %{_arch} == x86_64 || %{_arch} == i686
> 
> Hope that helps other folks,
> 
> ~tom

Using %if %{_arch} == x86_64 || %{_arch} == i686 seems to break building srpm
on arm koji:
http://koji.fedoraproject.org/koji/taskinfo?taskID=6049393
(when making srpm on i686 or x86_64, it seems okay).

Perhaps when building srpm on arm, _arch is not defined on koji.

Regards,
Mamoru





-- 
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: RE: %ifarch note

[Mamoru TASAKA]

> On Oct 11, 2013 1:55 PM, "Mamoru TASAKA"  wrote:
> >
> > > Since I hit this, I'd imagine other people might.
> > > If your package has:
> > >
> > > BuildArch: noarch
> > >
> > > It will set %{_target_cpu} to "noarch".
> > >
> > > If you also use %ifarch in that spec file, you might be expecting it to
> > > match %{_arch} (the architecture of the build server). It does not. It
> > > matches %{_target_cpu}.
> > >
> > > If you need to conditionalize on the value of %{_arch} in such a spec
> > > file, you need to do it explicitly:
> > >
> > > %if %{_arch} == x86_64 || %{_arch} == i686
> > >
> > > Hope that helps other folks,
> > >
> > > ~tom
> >
> > Using %if %{_arch} == x86_64 || %{_arch} == i686 seems to break building 
> > srpm
> > on arm koji:
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=6049393
> > (when making srpm on i686 or x86_64, it seems okay).
> >
> > Perhaps when building srpm on arm, _arch is not defined on koji.
> >
> > Regards,
> > Mamoru

> Till just told me about %ifnarch %{arm}.
> Is it better?

This is explained in the original spot's mail (, which 
is included in this mail), i.e.
when "BuildArch: noarch" exists, %ifarch or %ifnarch
doesn't work as expected (when building binary rpm).

(Currently my reply seems to create new thread...)

Regard,
Mamoru




-- 
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: Replies tearing threads apart [Was: %ifarch note]

[Mamoru TASAKA]

> On 10/11/2013 09:26 AM, Mamoru TASAKA wrote:
> > (Currently my reply seems to create new thread...)
> Are you replying from a SmartPhone or other Android-Device?
> 
> I have been observing this issue for quite a while and when ever asking 
> senders about their equipement they replied "Android-SmartPhone".
> 
> Seems to me, as if some Android-MUAs might not be able to preserve 
> threads or might tweak them in a way, thunderbird isn't able to sort 
> them correctly.
> 
> Ralf

No, currently I (have to) use a web mail service. When I am back
I can use thunderbird.

Regards,
Mamoru




-- 
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: abrt server report: 20130321

[Mamoru TASAKA]

Josh Boyer wrote, at 03/21/2013 11:18 PM +9:00:

On Thu, Mar 21, 2013 at 10:13 AM, Richard Marko  wrote:

On 03/21/2013 02:50 PM, Richard Marko wrote:

In last two weeks these components were crashing the most:

1. kernel seen 45496 times (36% of all reports)
 http://retrace.fedoraproject.org/faf/problems/586553/
 http://retrace.fedoraproject.org/faf/problems/258569/

2. xulrunner seen 12020 times (9% of all reports)
 http://retrace.fedoraproject.org/faf/problems/244577/
 http://retrace.fedoraproject.org/faf/problems/294757/



These two quite popular problems both contain proprietary modules so I would
like to use this opportunity to start a discussion about inclusion of
reports containing proprietary or non-supported modules in our statistics.

My questions are:
  - are these helpful or not?


For the kernel, no.  ABRT won't even file to bugzilla if the proprietary
taint flag is set, so we will never look at them.


Oh, does this explain that xscreensaver (which I am the maintainer)
was listed as "most destabilized components" with 203 jumps, however I
did not receive such many bug reports?
(I guess most of these crash reports are related to hacks using OpenGL,
 so maybe many of them are related to proprietary X drivers??)

Regards,
Mamoru



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

Review swaps

[Mamoru TASAKA]

Hello, all:

I have 6 rubygems related review requests which need reviewers

rubygem-unf_ext - Unicode Normalization Form support
https://bugzilla.redhat.com/show_bug.cgi?id=892314

rubygem-unf Wrapper library to bring Unicode Normalization Form support to 
Ruby/JRuby
(needs rubygem-unf_ext)
https://bugzilla.redhat.com/show_bug.cgi?id=904639

rubygem-domain_name - Domain Name manipulation library for Ruby (needs 
rubygem-unf)
https://bugzilla.redhat.com/show_bug.cgi?id=904640

rubygem-gdk3 - Ruby binding of GDK-3.x
https://bugzilla.redhat.com/show_bug.cgi?id=912960

rubygem-gtk3 - Ruby binding of GTK+-3.x (needs rubygem-gdk3)
https://bugzilla.redhat.com/show_bug.cgi?id=912961

rubygem-syck - Gemified version of Syck from Ruby's stdlib
https://bugzilla.redhat.com/show_bug.cgi?id=922460

I would like to swap these review requests with one of yours.

Regards,
Mamoru


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

RE: Koji failure in f19: : tag requiresadmin permission

[Mamoru Tasaka]

Hello:

> Subject: libguestfs-1.21.25-1.fc19 unsuccessfully tagged into f19 by rjones
> 
> Package: libguestfs
> NVR: libguestfs-1.21.25-1.fc19
> User: rjones
> Status: failed
> Tag Operation: tagged
> Into Tag: f19
> 
> libguestfs-1.21.25-1.fc19 unsuccessfully tagged into f19 by rjones
> Operation failed with the error:
> : tag requires admin permission
> 
> 
> What does this mean and how to fix it?
> 
> Rich.
> 


I guess your build was hit by F-19 alpha change freeze:
http://lists.fedoraproject.org/pipermail/devel/2013-April/180922.html

You may try tagging your build as f19-candidate. If it doesn't succeed,
just bumping release and rebuilding is simple way. Anyway you have to
submit your build on bodhi.

Regards,
Mamoru




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

Re: bison, flex have broken deps in rawhide

[Mamoru TASAKA]

Michael Schwendt wrote, at 04/04/2013 11:41 PM +9:00:

On Thu, 4 Apr 2013 09:32:24 -0500, Bruno Wolff III wrote:


On Thu, Apr 04, 2013 at 09:59:36 -0400,
Tom Lane  wrote:

DEBUG util.py:264:  Error: Package: bison-2.7-1.fc20.x86_64 (build)
DEBUG util.py:264: Requires: m4 >= 1.4
DEBUG util.py:264:  Error: Package: flex-2.5.37-1.fc20.x86_64 (build)
DEBUG util.py:264: Requires: m4
DEBUG util.py:264:   You could try using --skip-broken to work around the 
problem
DEBUG util.py:264:   You could try running: rpm -Va --nofiles --nodigest
DEBUG util.py:354:  Child return code was: 1

Somebody please fix?


Note that this is needed to rebuild postgresql to fix an important security
issue for which information how to exploit it are now public. It would be
really nice to have this fixed today even if that involves untagging the
m4 build from this morning (assuming that would fix the issue) in order
to get postgresql 9.2.4 built before doing a real fix.


If "Requires: m4" for buildroot creation fails, this could only mean that
the package is not included anymore or obsoleted by accident somewhere else.
Today's build of m4 satisfies the >= 1.4 requirement, too, btw. Odd that
m4 would be missing completely.

Thu Apr  4 15:02:52 2013 m4-1.4.16-8.fc20 tagged into f20 by vcrhonek [still 
active]



Note that on i686 building buildroot seemed successful (but was canceled due to
x86_64 side buildroot creating failure:
http://kojipkgs.fedoraproject.org//work/tasks/2571/5212571/root.log
task root:
http://koji.fedoraproject.org/koji/taskinfo?taskID=5212558

And I just remembered that I saw similar strange issue on f18-candidate:
http://koji.fedoraproject.org/koji/taskinfo?taskID=5210441
In this one, creating buildroot on x86_64 was successful, however on i686
it failed. I just withdraw rubygem-glib2-1.2.5-1.fc18 override request and
resubmitted override request, then next time buildroot was correctly created
on both i686 and x86_64.

So I guess repoclosure process is somewhat broken on koji.
Regards,
Mamoru


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

Re: Mission Impossible #1: qt without gtk

[Mamoru TASAKA]

Adam Williamson wrote, at 05/12/2013 04:22 AM +9:00:

On Sat, 2013-05-11 at 22:01 +0400, Eugene Pivnev wrote:

Problematic dependencies that I found:



xscreensaver_base -> libglade2 -> gtk2;



These ones look a bit more significant. xscreensaver-base's dep on gtk2
in particular looks odd.


The question is - are these dependencies unbreakable?


Indeed...


xscreensaver-demo, which is for configuring xscreensaver (daemon),
requires gtk2.

Regards,
Mamoru



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

Re: Mission Impossible #1: qt without gtk

[Mamoru TASAKA]

Rahul Sundaram wrote, at 05/12/2013 12:59 PM +9:00:

On 05/11/2013 11:19 PM, Mamoru TASAKA wrote:


xscreensaver-demo, which is for configuring xscreensaver (daemon),
requires gtk2.


IIRC KDE can use xscreensaver modules and if so, the user has no real need
of the demo command.  It may be better to move xscreensaver-demo into its own 
package

Rahul


In this discussion xscreensaver dependency is not for xscreensaver modules
in KDE, but for razorqt{-panel}. It seems that razorqt _really_ wants to
launch xscreensaver daemon, so splitting out xscreensaver-demo from 
xscreensaver-base
does not help here.

Regards,
Mamoru


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

Re: Mission Impossible #1: qt without gtk

[Mamoru TASAKA]

No top-post please.

Eugene Pivnev wrote, at 05/12/2013 10:06 PM +9:00:

Sorry, but as I found in xsceensaver-base (not xscreensaver itself!) - it 
contains as xsceensaver as xscreensaver demo (/usr/bin/xscreensaver-demo, glade 
based).
And no one xscreensaver config tool.


xscreensaver-demo is the xscreensaver daemon configuration tool.



12.05.2013 13:21, Mamoru TASAKA:

Rahul Sundaram wrote, at 05/12/2013 12:59 PM +9:00:

On 05/11/2013 11:19 PM, Mamoru TASAKA wrote:


xscreensaver-demo, which is for configuring xscreensaver (daemon),
requires gtk2.


IIRC KDE can use xscreensaver modules and if so, the user has no real need
of the demo command.  It may be better to move xscreensaver-demo into its own 
package

Rahul


In this discussion xscreensaver dependency is not for xscreensaver modules
in KDE, but for razorqt{-panel}. It seems that razorqt _really_ wants to
launch xscreensaver daemon, so splitting out xscreensaver-demo from 
xscreensaver-base
does not help here.


Regards,
Mamoru



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

Re: Mission Impossible #1: qt without gtk

[Mamoru TASAKA]

Eugene Pivnev wrote, at 05/12/2013 10:09 PM +9:00:

12.05.2013 13:21, Mamoru TASAKA:

It seems that razorqt _really_ wants to launch xscreensaver daemon, so 
splitting out xscreensaver-demo from xscreensaver-base
does not help here.


You mean - xscreensaver daemon depends on glade and/or gtk2 too?


Again xscreensaver configuration tool is written using glade and gtk2.

Regards,
Mamoru


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

RE: Koji doensn't resolve package dependency

[Mamoru Tasaka]

Hello:

> Hallo,
> 
> I have got an odd issue with koji on building gnustep-base-1.24.4-7.fc19.
> http://koji.fedoraproject.org/koji/buildinfo?buildID=419373
> 
> Koji told me, that the requirement gnustep-make >= 2.6.4-13
> could not been resolved.
> 
> An research on bodhi told me, that gnustep-make-2.6.4-13.fc19 is tagged
> as stable. So it may be nice, if anyone can give me a hint to solve this
> issue.
> 
> Best Regards:
> 
> Jochen Schmitt

$ koji latest-pkg f19-build gnustep-make
Build Tag   Built by
    
gnustep-make-2.6.4-12.fc19f19-override  s4504kr

Expire the override request for gnustep-make-2.6.4-12.fc19 (and also
gnustep-make-2.6.4-13.fc19), and the really latest gnustep-make will
put into F-19 buildroot.

Regards,
Mamoru




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