Meld directory compare still broken in f36

[Andrea Musuruane]

Hi,
meld directory compare in f36 is broken.

I opened a bug report last month:
https://bugzilla.redhat.com/show_bug.cgi?id=2091377

Some days later, kiilerix provided a PR to fix this issue:
https://src.fedoraproject.org/rpms/meld/pull-request/6

The PR has been accepted but a new package hasn't been build.

Can the packager or a proven packager please do this?

Thanks,

Andrea
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [cdparanoia] License field fix awaiting to be merged

[Andrea Musuruane]

>
> The issue here is that there's not a way to describe the SRPM license
> separate from the binary RPM license. So that information is important
> for SRPM distribution.
>

But Licensing Guidelines make clear that the License: field refers to the
binary packages not source ones.

BR,

Andrea
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [cdparanoia] License field fix awaiting to be merged

[Andrea Musuruane]

I believe this patch is not correct.

"The License: field refers to the licenses of the contents of the *binary*
rpm."
https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/

In the README file there is writted: "cdparanoia (the command line tool) is
released under the GPLv2.  The interface and paranoia libraries are covered
by the LGPLv2.1."

So, it doesn't really matter if two source files are distributed under
the GPLv2+
license. The resulting binary (i.e. /usr/bin/cdparanoia) will always be
GPLv2.

BR,

Andrea


On Wed, Jun 2, 2021 at 2:03 PM Jiri Kucera  wrote:

> Thanks Neal!
>
> On Wed, Jun 2, 2021 at 1:06 PM Neal Gompa  wrote:
>
>> On Wed, Jun 2, 2021 at 6:54 AM Neal Gompa  wrote:
>> >
>> > On Wed, Jun 2, 2021 at 6:53 AM Jiri Kucera  wrote:
>> > >
>> > > Adding broader audience:
>> https://src.fedoraproject.org/rpms/cdparanoia/pull-request/4
>> > >
>> > > Neither @pjones nor @ajax are responding.
>> > >
>> >
>> > I'll deal with it.
>> >
>>
>> This is done, and updates have been proposed for stable releases:
>>
>> * Fedora 34:
>> https://bodhi.fedoraproject.org/updates/FEDORA-2021-31358601f8
>>
>> * Fedora 33:
>> https://bodhi.fedoraproject.org/updates/FEDORA-2021-4c93fe43a0
>>
>> Please karma them up for release to stable.
>>
>>
>>
>>
>> --
>> 真実はいつも一つ！/ Always, there's only one truth!
>>
>> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

gcompris-qt license change

[Andrea Musuruane]

gcompris-qt changed license from GPLv3+ to AGPLv3 in version 1.1 because
they used a library for analog electricity activity under AGPLv3 causing
the whole software to be licensed under it.

Regards,

Andrea
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Error creating the package RPM: make:*** No rule to make target 'install'.

[Andrea Musuruane]

Hi!

On Thu, Oct 1, 2020 at 1:15 PM Helg Green via devel <
devel@lists.fedoraproject.org> wrote:

> The program is installed in the folder
> /opt/simplest_studio/bin/simplest_studio
>
> A strange error also appeared:
> .
> .
> .
> RPM build errors:
> Empty %files file
> /home/helg/rpmbuild/BUILD/simplest-studio-1.1/debugsourcefiles.list
>

I think  that's because you strip the binary file. Avoid that and the issue
will go away.

BR,

Andrea
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Pinta failed to build on f33/armv7hl

[Andrea Musuruane]

Il lun 17 ago 2020, 19:55 Jeff Law  ha scritto:

> On Fri, 2020-08-14 at 12:03 +0200, Andrea Musuruane wrote:
> > Hi guys,
> >I tried to update pinta to the latest upstream version. It built fine
> except than on f33/armv7hl:
> >
> > https://kojipkgs.fedoraproject.org//work/tasks/1530/49241530/build.log
> >
> > I have no idea why. Can someone please help?
> FWIW, it's not LTO :-)
>

I noticed :-)

I also opened a bug report against mono:
https://bugzilla.redhat.com/show_bug.cgi?id=1869214

The stage thing is that on rawhide everything seems fine but not on F33.

Regards,

Andrea
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Pinta failed to build on f33/armv7hl

[Andrea Musuruane]

Hi guys,
   I tried to update pinta to the latest upstream version. It built fine
except than on f33/armv7hl:

https://kojipkgs.fedoraproject.org//work/tasks/1530/49241530/build.log

I have no idea why. Can someone please help?

Thanks!

Andrea
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Still problems with s390x builds

[Andrea Musuruane]

On Sat, Aug 8, 2020 at 11:28 PM Kevin Fenzi  wrote:

> > I submitted another build. It failed with the same error:
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=48924234
>
> There was some upstream to us work in the iad2 datacenter today:
>
> https://pagure.io/fedora-infrastructure/issue/9200
>
> Please retry now and see if things are better.
>

Now it worked.

Thanks,

Andrea
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Still problems with s390x builds

[Andrea Musuruane]

On Sat, Aug 8, 2020 at 5:46 PM José Abílio Matos  wrote:

> On Saturday, 8 August 2020 16.26.39 WEST Andrea Musuruane wrote:
>
> > Can someone please check?
>
> >
>
> > Thanks!
>
> >
>
> > Andrea
>
>
>
> When that happens I issue another rebuild and the problem is solved. In
> other words this is a transient problem.
>
>
>
I submitted another build. It failed with the same error:
https://koji.fedoraproject.org/koji/taskinfo?taskID=48924234

Regards,

Andrea
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Still problems with s390x builds

[Andrea Musuruane]

Hi guys,
   I was updating gcompris-qt for the newer cmake but I got this error on
the s390x builder:

GenericError: Downloaded rpm
http://kojipkgs-cache01.s390.fedoraproject.org/work/tasks/4182/48924182/gcompris-qt-0.97-6.fc33.src.rpm
is corrupted:
rpm's header can't be extracted:
/var/tmp/koji/tasks/4188/48924188/local/work/tasks/4182/48924182/gcompris-qt-0.97-6.fc33.src.rpm
(rpm error: error reading package header)

Can someone please check?

Thanks!

Andrea
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: s390x weirdness during mass rebuild

[Andrea Musuruane]

Hi guys,
at least one of the packages I maintain was also affected. Fedora
Release Engineering has opened a bug against the package for this issue.
Can you please avoid that? Moreover, would my package be orphaned in 8
weeks because it cannot be built for a builder issue on s390x?

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

BR,

Andrea


On Tue, Jul 28, 2020 at 8:05 AM Guido Aulisi  wrote:

> Il giorno lun 27 lug 2020 alle ore 17:11 Jerry James
>  ha scritto:
> >
> > I don't know if this is related to what we saw during the previous
> > mass rebuild, but on s390x only, the TOPCOM build failed with:
> >
> > BuildrootError: Requested repo (1785306) is DELETED
> I'm having the same issue.
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1548001
>
> FAS: tartina
>
> Ciao
> Guido
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Please BuildRequire python3-setuptools explicitly

[Andrea Musuruane]

On Tue, Jun 23, 2020 at 6:26 PM Tomas Hrnciar  wrote:

> Hello everyone,
>
> there are plenty of Python packages in Fedora currently using setuptools at
> buildtime but not all of them are BuildRequiring it explicitly. This only 
> works
> because python3-devel (transitively) depends on python3-setuptools.
>
> We would like to kindly ask you to add explicit BuildRequires for
> python3-setuptools to packages where setuptools is used. It will help us
> with testing new versions of setuptools in the future or with decoupling
> Python and setuptools. Today, if we want to know if a package is using
> setuptools, we have to do `fedpkg prep` and use grep to search for
> setuptools. Using a repoquery is much more convenient.
>
> Several packages can successfully build either with or without setuptools
> (they use try-except import and fallback to distutils from the standard
> library). Such packages are especially dangerous when not BuildRequiring
> setuptools -- they can produce different results depending on the presence
> of setuptools: either an .egg-info metadata directory (w/setuptools) or
> .egg-info text file (w/distutils). RPM has troubles when upgrading
> directories to files [1].
>
> [1]
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Directory_Replacement/
>
> According to our grep based query on Fedora Rawhide, there are 621 known
> packages using setuptools without BuildRequiring it at this point:
>
> Thank you very much for your help with this.
>
[...]
>
> musuruan   ogr2osm
>

Fixed and rebuilt in rawhide.

BR,

Andrea
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

FEDORA-2019-b55ed79892 ejected from the push

[Andrea Musuruane]

Hi guys,
can someone please tell me what's going on?

https://bodhi.fedoraproject.org/updates/FEDORA-2019-b55ed79892

Thanks!

Andrea
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: List of Python 2 packages to be removed mid-November

[Andrea Musuruane]

HI!

On Tue, Oct 29, 2019 at 4:25 PM Miro Hrončok  wrote:

> Dear maintainers,
> here is a list of packages that (transitively, at build or run time)
> require
> Python 2 and have not yet got a FESCo exception to do so.
> If you were bcced on this e-mail, it affects one or more of your packages.
>
> The default action will be to remove such packages mid-November.
>
> If this took you by surprise, don't panic. It's possible to change the
> default.
> Let us know and we'll work things out.
> The mid-November deadline is not for removing *all* of Python 2, but for
> getting
> exceptions.
>
> [...]

>
> bruno
>qgis
>  (BuildRequires: python2-sip-devel → PY2)
>

It seems there is a wrong dependency in the spec file:

BuildRequires:  sip-devel

Shouldn't this be BuildRequires:  python3-sip-devel?

BR,

Andrea
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Dependency issues with mono on F31?

[Andrea Musuruane]

On Wed, Sep 25, 2019 at 4:40 PM Kevin Fenzi  wrote:

> On Wed, Sep 25, 2019 at 11:37:28AM +0200, Andrea Musuruane wrote:
> > Hi all,
> >  recently it has been opened a bug against pinta:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1755274
> >
> > It seems that for some unknown reason, in F31, the build process is no
> > longer able to determine mono dependencies correctly.
> >
> > Do someone have some hint for this?
>
> I suspect this is a bug in the mono package. It now provides rpm with a
> mono-find-requires script and somehow that might not be working?
>
> Although that script landed in mono on 2019-07-30, and pinta was built
> on the 27th? so, perhaps it just needs a rebuild?
>
> I'd suggest testing a scratch build. If that works, just rebuild it.
> If it doesn't move the bug to mono and see if they can sort out whats
> wrong with the script.
>

Thanks.

The scratch build was fine:
https://koji.fedoraproject.org/koji/taskinfo?taskID=37860248

I'm now rebuilding for F31+.

Bye,

Andrea
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Dependency issues with mono on F31?

[Andrea Musuruane]

Hi all,
 recently it has been opened a bug against pinta:
https://bugzilla.redhat.com/show_bug.cgi?id=1755274

It seems that for some unknown reason, in F31, the build process is no
longer able to determine mono dependencies correctly.

Do someone have some hint for this?

Thanks!

Andrea
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fwd: gcompris-qt: help needed

[Andrea Musuruane]

Hi!

On Sat, Jun 30, 2018 at 6:02 PM, Robert-André Mauchin 
wrote:

> I've Searched for bugs at our ArchLinux fellows and they mentioned this:
>
> https://bugs.archlinux.org/task/57542?project=0=id=desc
> %5B0%5D=closed=gcompris-qt
>
> It seems caused by this change:
> https://bugreports.qt.io/browse/QTBUG-65789
>
> It is fixed by this commit which should then be backported to f28
> https://github.com/qt/qtdeclarative/commit/602a6589
>
> See result of patch: https://imgpile.com/images/nE8RpM.md.png
>
> Then as you can see the first icon is the wrong size, it is too small:
> this
> another bug that is affecting the SVG images once the first one is solved:
> https://bugreports.qt.io/browse/QTBUG-67019
>
> This is fixed by
> https://github.com/qt/qtdeclarative/commit/b1243b8c
>
> Here we go, with both patches, we have the full UI:
> https://imgpile.com/images/nE8bb4.md.png
>
> Now let's make a pull request:
> https://src.fedoraproject.org/rpms/qt5-qtdeclarative/pull-request/2
>
> I'm CCing Rex Dieter, hoping he can merge this PR soon.
>

Thank you very much for your precious help!

Andrea.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LLRRH6RLTZFCEJI5J2N4UCE7GZA6VUD2/

Fwd: gcompris-qt: help needed

[Andrea Musuruane]

Hi!
I'm forwarding this request for help here since it seems there is no
one available on Fedora games.

The strange thing about this issue is that on F27 everything is fine (the
spec file is the same).

Thanks in advance,

Andrea



-- Forwarded message --
From: Andrea Musuruane 
Date: Sat, Jun 23, 2018 at 9:27 PM
Subject: gcompris-qt: help needed
To: Fedora Games 


Hi all!
I'm gcompris-qt maintainer.

gcompris-qt was fine until I upgraded to F28.

After that, it seems the program is no longer able to shows some graphics.
Even a fresh install on a VM shows the same behaviour.

Activity menu icons are not shown even though you can select a group
blindly clicking on an empty box in upper part of the screen. Then related
activities are shown but again without icons and with an textual
description. Even inside an activity some graphics are not shown.

The program shows no error and it seems it does not complain about anything
missing.

Any help is really appreciated.

Thanks,

Andrea
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PSYB66PFPF5UIMV7POW23JCB5GLKON2P/

Re: Packages which call install-info in scriptlets

[Andrea Musuruane]

Hi,

On Sat, Jun 16, 2018 at 2:46 AM, Jason L Tibbitts III 
wrote:

> As of Fedora 28, the 'info' package has gained a file trigger
> (%transfiletrigger) which will automatically rebuild the info directory
> node when any file is installed into %_infodir.  Thus it is no longer
> necessary for packages in F28 or newer to include scriptlets which call
> install-info, nor to include the dependencies on info or
> /sbin/install-info for those scriptlets.  We have updated the packaging
> guidelines (https://fedoraproject.org/wiki/Packaging:Scriptlets#Texinfo)
> to indicate that these scriptlets and dependencies should be removed in
> F28 and newer.  (It is not necessary to push updates for this unless you
> really wish to do so.)
>

I think rpmlint should be amended. Now I get "E:
info-files-without-install-info-postun" on F28.

Regards,

Andrea
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/R27QEJSA2V24WBULTQKOJNTWMSOUREZF/

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Andrea Musuruane]

Hi

On Sun, Feb 18, 2018 at 6:09 PM, Igor Gnatenko <
ignatenkobr...@fedoraproject.org> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Over this weekend I've performed scratch-mass-rebuild without having gcc
> and
> gcc-c++ in buildroot of all Fedora packages, many of which failed due to
> random
> reasons and I grepped all logs for some common errors found by analyzing
> hundreds of build logs.
>


> [...]
>


> List of packages and respective maintainers:
> https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs.txt
>

I fixed mine:

musuruan   abbayedesmorts-gpl ballerburg edgar fbzx flobopuyo hatari
libicns osmctools pinta pipepanic tecnoballz zaz


Bye,

Andrea
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Empty debugsourcefiles.list when building out of source

[Andrea Musuruane]

On Thu, Jan 11, 2018 at 11:45 AM, David Demelier 
wrote:

> Is there a place where you see that we must use this variable?
>
> Anyway, it worked, I changed the CMake invocation to:
>
> cmake ... \
> -DCMAKE_C_FLAGS="${RPM_OPT_FLAGS}" \
> -DCMAKE_CXX_FLAGS="${RPM_OPT_FLAGS}" \
>
> It built fine, thanks!


Actually you should use the %cmake macro:
https://fedoraproject.org/wiki/Packaging:Cmake

Try to expand it to see how it works:
rpm --eval %cmake

Bye,

Andrea
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Raising requirement for application icons in GNOME Software

[Andrea Musuruane]

Hi,

On Fri, Sep 1, 2017 at 9:12 PM, Richard Hughes  wrote:

> Hi all,
>
> At the moment the appstream-builder requires a 48x48px application
> icon[1] to be included in the AppStream metadata. I'm sure it's no
> surprise that 48x48 padded to 64x64 and then interpolated up to
> 128x128 (for HiDPI screens) looks pretty bad. For F28 and higher I'm
> going to raise the minimum size to 64x64 which I hope people realize
> is actually a really low bar. I'm not sure whether to mass file bugs
> or just try to contact maintainers directly.
>

Most maintainers are not graphic artists. Moreover if they had available an
higher resolution icon, they would already ship it.

I also don't think that nagging upstream about these missing icons is
really welcome - most of the times even upstream doesn't have a graphic
artist available.

I believe the correct way to solve this issue is that Fedora Design team
(if available) provides new icons to upstream.

This can be a long process and therefore I don't think it is safe to raise
the minimum size requirement to 64x64 any time soon.

Bye,

Andrea
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Review swap

[Andrea Musuruane]

Hi Volerk,

Hello Andrea!
>
> Please add it to http://fedoraproject.org/wiki/GIS
>

Added!!

Bye,

Andrea
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Review swap

[Andrea Musuruane]

Hi,

On Wed, Aug 23, 2017 at 12:30 PM, Alexander Ploumistos <
alex.ploumis...@gmail.com> wrote:

> Hello Andrea,
>
> I've taken it, but my ISP is giving me some trouble at the moment,
> they said they'll get things sorted out within the hour.
>
> I don't have a package ready for review yet, but I think I might have
> one by next week.
>

No problem at all.

Let me know when your package will be ready.

Bye,

Andrea
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Review swap

[Andrea Musuruane]

Hi!
I'm looking for a reviewer for

osmctools - Tools to manipulate OpenStreetMap files:
https://bugzilla.redhat.com/show_bug.cgi?id=1464777

Maybe some other OSM mapper is interested?

I'm happy to exchange reviews.

Thanks in advance.

Bye,

Andrea
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Package suggestions

[Andrea Musuruane]

On Sat, Jun 24, 2017 at 11:11 PM, rugk  wrote:

> FYI, the game's name I could not remember was "Which way is up". See
> https://packages.debian.org/stretch/whichwayisup.
>

Nice game. I didn't know it.

I packaged it and it's available for review:
https://bugzilla.redhat.com/show_bug.cgi?id=1464778

Bye,

Andrea
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unretiring Onboard (on screen keyboard)

[Andrea Musuruane]

Hi Nemanja,

On Fri, Mar 10, 2017 at 10:26 PM, Nemanja Milosevic <
nmilo...@fedoraproject.org> wrote:

> Hi everyone,
>
> I would like to request admin access to the package Onboard. Onboard is an
> onscreen keyboard which I am using on my BayTrail tablet and it works
> really well.
>
> The package was orphaned in 2011 (http://pkgs.fedoraproject.
> org/cgit/rpms/onboard.git/tree/dead.package) because it failed to built.
>
> SPEC file (for the latest version): https://pagure.io/onboard-rpm/
> raw/master/f/onboard.spec
> Koji scratch build (x86_64, i686, ARM): https://koji.fedoraproject.
> org/koji/taskinfo?taskID=18308128
> COPR repo (Fedora 24, 25, 26, rawhide): https://copr.fedorainfracloud.
> org/coprs/nmilosev/onboard/
> PkgDB: https://admin.fedoraproject.org/pkgdb/package/rpms/onboard/
>
> Please let me know if I can request ownership. Thank you in advance!
>

Retired Fedora packages require a re-review if they are retired for more
than two weeks:
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers?rd=PackageMaintainers/OrphanedPackages#Claiming_Ownership_of_a_Retired_Package

Bye,

Andrea
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Self Introduction: Ron Olson

[Andrea Musuruane]

On Mon, Nov 14, 2016 at 2:53 AM, Ron Olson  wrote:
> Aloha all-
>
> I’m Ron Olson, with the nickname tachoknight. I have been using Unix since
> 1989 and Linux since about 1992, when we somehow got an early version to run
> on a Gateway2000 machine.

Welcome!

> I have submitted for review an update to the Nethack RPM to update it from
> 3.4.3 (where it had been for many years), to 3.6.0:
> https://bugzilla.redhat.com/show_bug.cgi?id=1394598

I'm sorry but this is not how Fedora works. If the package is
*already* in Fedora, you can't open a new review request. Please open
a bug report against the package.

If the maintainer doesn't respond, please follow:
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers

Bye,

Andrea
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Guidelines change] Changes to the packaging guidelines

[Andrea Musuruane]

On Tue, Aug 23, 2016 at 1:54 PM, Andrea Musuruane <musur...@gmail.com> wrote:
>
>
> On Thu, Aug 18, 2016 at 8:25 PM, Jason L Tibbitts III <ti...@math.uh.edu>
> wrote:
>>
>> Here are the recent changes to the packaging guidelines.
>>
>> -
>>
>> The Filesystem Layout section of the guidelines was simplified and
>> outdated information was removed.
>>
>> * https://fedoraproject.org/wiki/Packaging:Guidelines
>> * https://fedoraproject.org/wiki/Packaging:Guidelines#Filesystem_Layout
>> * https://fedorahosted.org/fpc/ticket/623
>
>
> The links to FHS specs are all outdated. The current one is
> https://wiki.linuxfoundation.org/lsb/fhs
>
> Moreover I still read "The Filesystem Hierarchy Standard does not include
> any provision for libexecdir, " which is not accurate:
> http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html

I still read the same issues. The page is protected and it cannot be
freely edited.

Bye,

Andrea
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Guidelines change] Changes to the packaging guidelines

[Andrea Musuruane]

On Thu, Aug 18, 2016 at 8:25 PM, Jason L Tibbitts III 
wrote:

> Here are the recent changes to the packaging guidelines.
>
> -
>
> The Filesystem Layout section of the guidelines was simplified and
> outdated information was removed.
>
> * https://fedoraproject.org/wiki/Packaging:Guidelines
> * https://fedoraproject.org/wiki/Packaging:Guidelines#Filesystem_Layout
> * https://fedorahosted.org/fpc/ticket/623


The links to FHS specs are all outdated. The current one is
https://wiki.linuxfoundation.org/lsb/fhs

Moreover I still read "The Filesystem Hierarchy Standard does not include
any provision for libexecdir, " which is not accurate:
http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html

Bye,

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

Re: Policy change on emulators

[Andrea Musuruane]

On Thu, May 5, 2016 at 12:07 AM, Tom Callaway <tcall...@redhat.com> wrote:

> On 05/04/2016 05:20 AM, Andrea Musuruane wrote:
> > Does this mean that most console emulators (i.e.
> > NES/SNES/MasterSystem/Genesis emulators) are now acceptable in Fedora?
>
> Subject to the guidelines as written, yes.
>
> A clear example of something that would now be permitted would be MAME
> (because it is now Free Software and meets the new criteria).
>

What about Spectrum ROMs:
http://www.worldofspectrum.org/permits/amstrad-roms.txt

Are they acceptable under the Fedora firmware exception criteria?

BR,

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

Re: Policy change on emulators

[Andrea Musuruane]

On Tue, May 3, 2016 at 8:55 PM, Tom Callaway  wrote:

> Some emulators (applications which emulate another platform) are not
> permitted for inclusion in Fedora. These rules will help you determine
> whether an emulator is acceptable for Fedora.
>
> * Emulators which depend on firmware or ROM files to function may not be
> included in Fedora, unless the copyright holder(s) for the firmware/ROM
> files give clear permission for the firmware/ROM files to be distributed
> (either under a Fedora permissible license or under the Fedora firmware
> exception criteria). Note: This only covers the situation where an
> emulator will not run at all without firmware/ROM files. For example,
> emulators that compile and run, but ship with no game ROMs are not
> covered by this rule.
>

Does this mean that most console emulators (i.e.
NES/SNES/MasterSystem/Genesis emulators) are now acceptable in Fedora?

Bye,

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

Tecnoballz

[Andrea Musuruane]

Hi all,
I am Tecnoballz maintainer.

Currently Tecnoballz is failing to build in rawhide:
https://bugzilla.redhat.com/show_bug.cgi?id=1308179

There is a new upstream version (0.93.1) and it builds without problems. I
also added Debian/upstream patches.

In order to allow a shared scoreboard file, the Games Packaging guidelines
strongly suggest to make the executable setgid 'games' and to drop setgid
privileges as soon as possible:
https://fedoraproject.org/wiki/SIGs/Games/Packaging

I tried to port the patch Hans De Goede did for version 0.92:
https://bugzilla.redhat.com/show_bug.cgi?id=234563#c4
http://pkgs.fedoraproject.org/cgit/tecnoballz.git/tree/tecnoballz
-0.92-dropsgid.patch

But since I don't know C++ I didn't succeed.

I hope someone can help me with this task.

Work in progress spec and src.rpm can be found here:
https://dl.dropboxusercontent.com/u/12575912/reviews/tecnoballz.spec
https://dl.dropboxusercontent.com/u/12575912/reviews/tecnoballz-0.93.1-1.fc23.src.rpm

Thanks,

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

Re: Koji timeout

[Andrea Musuruane]

On Sat, Nov 8, 2014 at 6:23 PM, Kevin Fenzi ke...@scrye.com wrote:

  
   seems it's the mono compiler process that gets stuck, now to find
   out why ...
  
 
  Would it help if I open a bug for this issue?

 Probibly, but not sure where makes the most sense. ;(

 Can you try another build now? I just finished reinstalling/upgrading
 the builders to all the latest f20 packages and 3.17.2-200.fc20 kernels
 If it was a kernel or host space issue it might be cleared up now.

 If not, can you let me know the task and I can try and strace the stuck
 process on the builder and see if I can get you any more info that way.


I could build for F20 (I think a lucky strike) but I couldn't for rawhide.
This is the task:

http://koji.fedoraproject.org/koji/taskinfo?taskID=8080977

Bye,

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

Re: Koji timeout

[Andrea Musuruane]

On Sun, Nov 9, 2014 at 4:59 PM, Kevin Fenzi ke...@scrye.com wrote:

 On Sun, 9 Nov 2014 16:48:03 +0100
 Andrea Musuruane musur...@gmail.com wrote:

  I could build for F20 (I think a lucky strike) but I couldn't for
  rawhide. This is the task:
 
  http://koji.fedoraproject.org/koji/taskinfo?taskID=8080977

 I started to look at it, but then it finished. :)


Better late than never :)

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

Re: Koji timeout

[Andrea Musuruane]

On Tue, Nov 4, 2014 at 2:56 PM, Dan Horák d...@danny.cz wrote:

 On Tue, 4 Nov 2014 14:45:43 +0100
 Andrea Musuruane musur...@gmail.com wrote:

  On Tue, Nov 4, 2014 at 9:03 AM, Christopher Meng cicku...@gmail.com
  wrote:
   On Tue, Nov 4, 2014 at 3:52 PM, Andrea Musuruane
   musur...@gmail.com wrote:
   http://koji.fedoraproject.org/koji/taskinfo?taskID=8009403
  
   Hi,
  
   Please try again with make directly instead of make %{?
   _smp_mflags}.
 
  I tried but it stalled again:
  http://koji.fedoraproject.org/koji/taskinfo?taskID=8024559

 seems it's the mono compiler process that gets stuck, now to find out
 why ...


Would it help if I open a bug for this issue?

BR,

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

Re: Koji timeout

[Andrea Musuruane]

On Tue, Nov 4, 2014 at 9:02 AM, Dan Horák d...@danny.cz wrote:
 hm, it's not the first case where Mono enters a deadlock or endless
 loop ...

 What is your host system and what is the kernel version?

$ cat /etc/redhat-release
Fedora release 20 (Heisenbug)
$ uname -r
3.16.6-200.fc20.x86_64

Bye,

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

Re: Koji timeout

[Andrea Musuruane]

On Tue, Nov 4, 2014 at 9:52 AM, Dan Horák d...@danny.cz wrote:
 the builders have 3.16.3-200.fc20.x86_64, could you retry the local
 mock rebuild with this kernel installed? I know it won't solve the
 problem, but might lead to having a reproducer. Eventually also with
 the same mock config as used for the koji build which you can get
 from koji mock-config --task 8009477

$ cd ~/rpmbuild/SPECS/
[andrea@panoramix SPECS]$ uname -r
3.16.3-200.fc20.x86_64
[andrea@panoramix SPECS]$ rpmbuild -bs pinta.spec
Scritto: /home/andrea/rpmbuild/SRPMS/pinta-1.5-1.fc20.src.rpm
[andrea@panoramix SPECS]$ mock
/home/andrea/rpmbuild/SRPMS/pinta-1.5-1.fc20.src.rpm
[...]
Start: build setup for pinta-1.5-1.fc20.src.rpm
Finish: build setup for pinta-1.5-1.fc20.src.rpm
Start: rpmbuild -bb pinta-1.5-1.fc20.src.rpm
Finish: rpmbuild -bb pinta-1.5-1.fc20.src.rpm
Finish: build phase for pinta-1.5-1.fc20.src.rpm
INFO: Done(/home/andrea/rpmbuild/SRPMS/pinta-1.5-1.fc20.src.rpm)
Config(default) 7 minutes 15 seconds
INFO: Results and/or logs in: /var/lib/mock/fedora-20-x86_64/result
Finish: run
[andrea@panoramix SPECS]$ mock -r fedora-rawhide-x86_64
/home/andrea/rpmbuild/SRPMS/pinta-1.5-1.fc20.src.rpm
[...]
Start: build phase for pinta-1.5-1.fc20.src.rpm
Start: device setup
Finish: device setup
Start: build setup for pinta-1.5-1.fc20.src.rpm
Finish: build setup for pinta-1.5-1.fc20.src.rpm
Start: rpmbuild -bb pinta-1.5-1.fc20.src.rpm
Finish: rpmbuild -bb pinta-1.5-1.fc20.src.rpm
Finish: build phase for pinta-1.5-1.fc20.src.rpm
INFO: Done(/home/andrea/rpmbuild/SRPMS/pinta-1.5-1.fc20.src.rpm)
Config(fedora-rawhide-x86_64) 8 minutes 16 seconds
INFO: Results and/or logs in: /var/lib/mock/fedora-rawhide-x86_64/result
Finish: run
[andrea@panoramix SPECS]$ su
Password:
[root@panoramix SPECS]# koji mock-config --task 8009477 koji-debug.cfg
[root@panoramix SPECS]# mv koji-debug.cfg /etc/mock/
[root@panoramix SPECS]# exit
exit
[andrea@panoramix SPECS]$ mock -r koji-debug
/home/andrea/rpmbuild/SRPMS/pinta-1.5-1.fc20.src.rpm
[...]
Start: build phase for pinta-1.5-1.fc20.src.rpm
Start: device setup
Finish: device setup
Start: build setup for pinta-1.5-1.fc20.src.rpm
Finish: build setup for pinta-1.5-1.fc20.src.rpm
Start: rpmbuild -bb pinta-1.5-1.fc20.src.rpm
Finish: rpmbuild -bb pinta-1.5-1.fc20.src.rpm
Finish: build phase for pinta-1.5-1.fc20.src.rpm
INFO: Done(/home/andrea/rpmbuild/SRPMS/pinta-1.5-1.fc20.src.rpm)
Config(koji-debug) 10 minutes 3 seconds
INFO: Results and/or logs in: /var/lib/mock/f20-build-repo_430101/result
Finish: run
[andrea@panoramix SPECS]$

Everything seems fine.

Bye,

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

Re: Koji timeout

[Andrea Musuruane]

On Tue, Nov 4, 2014 at 9:03 AM, Christopher Meng cicku...@gmail.com wrote:
 On Tue, Nov 4, 2014 at 3:52 PM, Andrea Musuruane musur...@gmail.com wrote:
 http://koji.fedoraproject.org/koji/taskinfo?taskID=8009403

 Hi,

 Please try again with make directly instead of make %{?_smp_mflags}.

I tried but it stalled again:
http://koji.fedoraproject.org/koji/taskinfo?taskID=8024559

BR,

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

Koji timeout

[Andrea Musuruane]

Hi,
I'm trying to build pinta but it fails due to timeout on F20 and F22:

http://koji.fedoraproject.org/koji/taskinfo?taskID=8009403
http://koji.fedoraproject.org/koji/taskinfo?taskID=8009471


It built fine for F19 and F21 though. And it builds fine using mock. I
resubmitted the two failed builds but it seems nothing changed.

I don't know what to do next. Help appreciated.

Thanks.

Bye,

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

Re: The trouble with metadata-extractor

[Andrea Musuruane]

On Tue, Oct 22, 2013 at 6:33 PM, Stanislav Ochotnicky

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

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


I will orphan metadata-extractor and gettext-commons soon. There are just
two bugs, recently opened, about the removal of versioned jars:
https://bugzilla.redhat.com/show_bug.cgi?id=1022142
https://bugzilla.redhat.com/show_bug.cgi?id=1022100

CC'ing JOSM maintainer because he will be severely affected.

Regards,

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

Re: The trouble with metadata-extractor

[Andrea Musuruane]

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

Bye,

Andrea.



On Sun, Oct 20, 2013 at 11:37 PM, Andrea Musuruane musur...@gmail.comwrote:

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

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

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

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

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

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

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

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

 What to do now? What do you think?

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

 Regards,

 Andrea.

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

The trouble with metadata-extractor

[Andrea Musuruane]

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

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

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

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

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

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

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

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

What to do now? What do you think?

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

Regards,

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

Re: Proposal: AppData files in all application packages?

[Andrea Musuruane]

Hi Richard,

On Fri, Sep 6, 2013 at 11:33 AM, Richard Hughes hughsi...@gmail.com wrote:

 Hi all. I'm the developer for PackageKit and gnome-software, the
 latter being the new software center we're hopefully including as a
 technical preview in Fedora 20.

 [...]

 At the moment, we use the information in the .desktop file to populate
 the AppStream data, but this is missing a few core things, for
 instance a long description, the upstream website for the application
 and any screenshots to show. All of the three being quite critical to
 assess an application before installing. To fix this I've created a
 tiny AppData specification [1] which is a subset of the AppStream
 specification. It's designed as a way to describe the application (not
 the package) so that data can be used in the AppStream data.


As a first step to create such a database, can you reuse metadata avalable
on Ohloh?

https://www.ohloh.net/p

It seems they already have much of what you need.

Bye,

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

Re: Customizing Firefox Search.

[Andrea Musuruane]

On Thu, Feb 14, 2013 at 1:03 PM, Daniel J Walsh dwa...@redhat.com wrote:
 Any know of a way to build a customized search into firefox.  Basically I want
 to setup a search pull down which is hard coded to a particular site.

Probably this is what you want:
http://www.opensearch.org/Home

Bye,

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

Re: Oldest package review resolved

[Andrea Musuruane]

On Tue, Dec 18, 2012 at 1:21 PM, Mario Ceresa mrcer...@gmail.com wrote:
 I deeply admire Lee's perseverance! My oldest was 3 years and I felt
 trapped in the Neverending Story :)

 Out of curiosity, could you post a link to the oldest one?

It seems this one is even older:
https://bugzilla.redhat.com/show_bug.cgi?id=187317

Bye,

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

Re: another upgrade, another disaster

[Andrea Musuruane]

On Mon, Jun 4, 2012 at 7:57 AM, Jan Synacek jsyna...@redhat.com wrote:
   yum groupinstall GNOME Desktop Environment

 This alone unfortunately doesn't do the trick. You will probably have to

    yum groupinstall X Window System

 as well as some drivers for your graphic card to get it working.

 I also had to order selinux to relabel my entire /home to be able to get into
 any gnome session.

I also had to install a bunch of other yum groups, edit systemd config
to default do a graphical boot, recreate my old users, chown their
directories, and perform restorecon on /home.

Bye,

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

Re: another upgrade, another disaster

[Andrea Musuruane]

On Mon, Jun 4, 2012 at 8:50 AM, Adam Williamson awill...@redhat.com wrote:
 * 3rd attempt:
 Same as options as the 2nd attempt but this time I chose to enable
 only the F17 remote repositories and I disabled the Install repo so
 I presume all the packages were downloaded from the net. At about 85%
 of installation I got a kernel panic - this time I took care of the
 message unable to handle kernel NULL pointer dereference at
 0088.

 Frankly, I wouldn't trust your hardware.

 The installer uses the same kernel as the installed system, so even if
 you get it to install (which apparently you finally did), if you're
 getting quasi-random kernel panics, I wouldn't be at all surprised if
 you keep getting them on the installed system.

 That (and 'inexplicable' errors like failure to read a package on
 known-good media) points either to bad hardware or a kernel bug specific
 to your system in some way (as we don't have any known general kernel
 breakage AFAIK). You'd definitely need to get better data on one of the
 crashes (i.e. an actual log, or at least screen capture) and give it to
 the kernel team, to look into it.

 It may be worth running memtest on the system, first, though.

Everything can be and I will run memtest as you advised.

But I didn't had any kernel problem in the past - and I've used every
Fedora release on the same PC for about 4 years. After I could bypass
this problem - I could install the system, including I think all the
RPMs anaconda was trying to install without any problem. Note that I
don't run the same kernel used by anaconda because in fedora updates
there is available a newer one.

Anyway, in case I hit this issue again, I would be interested to know
how to get the log of this kind of error.

Regards,

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

Re: another upgrade, another disaster

[Andrea Musuruane]

On Sat, Jun 2, 2012 at 8:17 PM, Andrea Musuruane musur...@gmail.com wrote:
 On Tue, May 29, 2012 at 10:42 PM, Neal Becker ndbeck...@gmail.com wrote:
 Basically the same kind of failure as the last several times I did updates.
 This time f16-f17.  Used preupgrade.

 I'd like to share with you my experience about installing Fedora
 17/x86_64. It is a real PITA. No doubts about it.

6th attempt:
I did a minimal install also enabling remote updates and at last I
can boot Fedora 17. Now the problem is how to install a graphical
desktop environment from minimal install. I googled without finding
nothing really useful. As previously, any help is really appreciated.

Thanks.

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

Re: another upgrade, another disaster

[Andrea Musuruane]

On Tue, May 29, 2012 at 10:42 PM, Neal Becker ndbeck...@gmail.com wrote:
 Basically the same kind of failure as the last several times I did updates.
 This time f16-f17.  Used preupgrade.

I'd like to share with you my experience about installing Fedora
17/x86_64. It is a real PITA. No doubts about it.

* 1st attempt:
Clean upgrade of Fedora 16 from DVD. I left the PC unattended while
anaconda was upgrading RPM packages. I returned a couple of hours
later and found a kernel panic. I was too angry to take note of the
error. The system was no longer able to boot.

* 2nd attempt:
New installation of Fedora 17 from DVD. I chose to enable also the F17
remote repositories including updates - but not updates-testing. I
left my harddisk layout unchanged (obviously I didn't format my
/home). All partition were already ext4. I choose the Software
development option. At about 80% of installation anaconda reported
that there were an error in an RPM package and it couldn't complete
the installation. The image was correctly checked after downloading
and brasero reported that the ISO was mastered fine on DVD.

* 3rd attempt:
Same as options as the 2nd attempt but this time I chose to enable
only the F17 remote repositories and I disabled the Install repo so
I presume all the packages were downloaded from the net. At about 85%
of installation I got a kernel panic - this time I took care of the
message unable to handle kernel NULL pointer dereference at
0088.

* 4th attempt:
I rebooted from DVD and choose to update the current F17 system. It
was a desperate attempt. I know. The system couldn't boot.

* 5th attempt:
No remote repositories and Graphical desktop option. Same kernel
panic as the 3rd attempt.

I'm writing these notes from a Windows Notebook. I don't know what
else to do - apart from swearing. Any help is really appreciated.

Regards,

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

Re: Rpmbuild unable to recognize used libs?

[Andrea Musuruane]

On Sat, Feb 11, 2012 at 5:43 PM, Panu Matilainen
pmati...@laiskiainen.org wrote:
 On 02/11/2012 02:52 PM, Andrea Musuruane wrote:

 Hi all,
     a reporter just submitted this bug against tecnoballz:
 https://bugzilla.redhat.com/show_bug.cgi?id=789544

 After closer inspection, I see that the RPM doesn't require the needed
 libraries:

 $ rpm -q --requires tecnoballz
 /bin/sh
 /bin/sh
 config(tecnoballz) = 0.92-11.fc16
 hicolor-icon-theme
 rpmlib(CompressedFileNames) = 3.0.4-1
 rpmlib(FileDigests) = 4.6.0-1
 rpmlib(PayloadFilesHavePrefix) = 4.0-1
 rpmlib(PayloadIsXz) = 5.2-1

 The spec file is available here:
 http://pkgs.fedoraproject.org/gitweb/?p=tecnoballz.git;a=tree

 But if I print the shared libraries needed by the binary I get:

 $ ldd /usr/bin/tecnoballz
     linux-vdso.so.1 =  (0x7fff7213e000)
     libSDL-1.2.so.0 = /usr/lib64/libSDL-1.2.so.0 (0x003b9be0)
     libpthread.so.0 = /lib64/libpthread.so.0 (0x003b88e0)
     libSDL_image-1.2.so.0 = /usr/lib64/libSDL_image-1.2.so.0
 (0x0033b1a0)
     libSDL_mixer-1.2.so.0 = /usr/lib64/libSDL_mixer-1.2.so.0
 (0x003b8b60)
     libmikmod.so.3 = /usr/lib64/libmikmod.so.3 (0x003b89a0)
     libtinyxml.so.0 = /usr/lib64/libtinyxml.so.0 (0x7f8cda97a000)
     libstdc++.so.6 = /usr/lib64/libstdc++.so.6 (0x003b8de0)
     libm.so.6 = /lib64/libm.so.6 (0x003b8960)
     libgcc_s.so.1 = /lib64/libgcc_s.so.1 (0x003b8a20)
     libc.so.6 = /lib64/libc.so.6 (0x003b88a0)
     libdl.so.2 = /lib64/libdl.so.2 (0x003b8920)
     /lib64/ld-linux-x86-64.so.2 (0x003b8860)
     libpng12.so.0 = /usr/lib64/libpng12.so.0 (0x0033b2a0)
     libjpeg.so.62 = /usr/lib64/libjpeg.so.62 (0x003b94a0)
     libtiff.so.3 = /usr/lib64/libtiff.so.3 (0x0033b4e0)
     libz.so.1 = /lib64/libz.so.1 (0x0033b120)

 I really don't understand what's wrong here. Any help is appreciated.


 It's a bug in rpmbuild's file classification rules, should be fixed in this
 update: https://admin.fedoraproject.org/updates/FEDORA-2012-1504

 While this obviously isn't fault of tecnoballz, a rebuild is needed to
 correct the dependencies.

There still seems to be problems. I rebuilt it locally with an updated
F16 and now I get:
$ rpm -qp --requires /home/andrea/rpmbuild/SRPMS/tecnoballz-0.92-13.fc16.src.rpm
autoconf
SDL_image-devel
SDL_mixer-devel
mikmod-devel
tinyxml-devel
desktop-file-utils
rpmlib(FileDigests) = 4.6.0-1
rpmlib(CompressedFileNames) = 3.0.4-1

As you can see now it misses at least explicit requires
(hicolor-icon-theme) and others too (/bin/sh, config(tecnoballz),
etc).

Regards,

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

Re: Rpmbuild unable to recognize used libs?

[Andrea Musuruane]

On Mon, Feb 13, 2012 at 7:40 PM, Richard Shaw hobbes1...@gmail.com wrote:
 On Mon, Feb 13, 2012 at 12:34 PM, Andrea Musuruane musur...@gmail.com wrote:
 There still seems to be problems. I rebuilt it locally with an updated
 F16 and now I get:
 $ rpm -qp --requires 
 /home/andrea/rpmbuild/SRPMS/tecnoballz-0.92-13.fc16.src.rpm
 autoconf
 SDL_image-devel
 SDL_mixer-devel
 mikmod-devel
 tinyxml-devel
 desktop-file-utils
 rpmlib(FileDigests) = 4.6.0-1
 rpmlib(CompressedFileNames) = 3.0.4-1

 As you can see now it misses at least explicit requires
 (hicolor-icon-theme) and others too (/bin/sh, config(tecnoballz),
 etc).

 Would explicit requires be required by the source RPM? I would think
 they would only be added to the binary RPMS.

Ops! I copypasted the wrong file! It is fine actually:

$ rpm -qp --requires
/home/andrea/rpmbuild/RPMS/x86_64/tecnoballz-0.92-13.fc16.x86_64.rpm
/bin/sh
/bin/sh
config(tecnoballz) = 0.92-13.fc16
hicolor-icon-theme
libSDL-1.2.so.0()(64bit)
libSDL_image-1.2.so.0()(64bit)
libSDL_mixer-1.2.so.0()(64bit)
libc.so.6()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libgcc_s.so.1()(64bit)
libgcc_s.so.1(GCC_3.0)(64bit)
libm.so.6()(64bit)
libm.so.6(GLIBC_2.2.5)(64bit)
libmikmod.so.3()(64bit)
libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
libstdc++.so.6()(64bit)
libstdc++.so.6(CXXABI_1.3)(64bit)
libstdc++.so.6(GLIBCXX_3.4)(64bit)
libstdc++.so.6(GLIBCXX_3.4.11)(64bit)
libstdc++.so.6(GLIBCXX_3.4.9)(64bit)
libtinyxml.so.0()(64bit)
rpmlib(CompressedFileNames) = 3.0.4-1
rpmlib(FileDigests) = 4.6.0-1
rpmlib(PayloadFilesHavePrefix) = 4.0-1
rtld(GNU_HASH)
rpmlib(PayloadIsXz) = 5.2-1

Sorry for the noise :-(((

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

Rpmbuild unable to recognize used libs?

[Andrea Musuruane]

Hi all,
a reporter just submitted this bug against tecnoballz:
https://bugzilla.redhat.com/show_bug.cgi?id=789544

After closer inspection, I see that the RPM doesn't require the needed
libraries:

$ rpm -q --requires tecnoballz
/bin/sh
/bin/sh
config(tecnoballz) = 0.92-11.fc16
hicolor-icon-theme
rpmlib(CompressedFileNames) = 3.0.4-1
rpmlib(FileDigests) = 4.6.0-1
rpmlib(PayloadFilesHavePrefix) = 4.0-1
rpmlib(PayloadIsXz) = 5.2-1

The spec file is available here:
http://pkgs.fedoraproject.org/gitweb/?p=tecnoballz.git;a=tree

But if I print the shared libraries needed by the binary I get:

$ ldd /usr/bin/tecnoballz
linux-vdso.so.1 =  (0x7fff7213e000)
libSDL-1.2.so.0 = /usr/lib64/libSDL-1.2.so.0 (0x003b9be0)
libpthread.so.0 = /lib64/libpthread.so.0 (0x003b88e0)
libSDL_image-1.2.so.0 = /usr/lib64/libSDL_image-1.2.so.0
(0x0033b1a0)
libSDL_mixer-1.2.so.0 = /usr/lib64/libSDL_mixer-1.2.so.0
(0x003b8b60)
libmikmod.so.3 = /usr/lib64/libmikmod.so.3 (0x003b89a0)
libtinyxml.so.0 = /usr/lib64/libtinyxml.so.0 (0x7f8cda97a000)
libstdc++.so.6 = /usr/lib64/libstdc++.so.6 (0x003b8de0)
libm.so.6 = /lib64/libm.so.6 (0x003b8960)
libgcc_s.so.1 = /lib64/libgcc_s.so.1 (0x003b8a20)
libc.so.6 = /lib64/libc.so.6 (0x003b88a0)
libdl.so.2 = /lib64/libdl.so.2 (0x003b8920)
/lib64/ld-linux-x86-64.so.2 (0x003b8860)
libpng12.so.0 = /usr/lib64/libpng12.so.0 (0x0033b2a0)
libjpeg.so.62 = /usr/lib64/libjpeg.so.62 (0x003b94a0)
libtiff.so.3 = /usr/lib64/libtiff.so.3 (0x0033b4e0)
libz.so.1 = /lib64/libz.so.1 (0x0033b120)

I really don't understand what's wrong here. Any help is appreciated.

Regards,

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

BuildError: No srpms found

[Andrea Musuruane]

Hi all,
I continue getting the following error while trying to build
tecnoballz for F16  F15: BuildError: No srpms found in
/var/lib/mock/f16-build-1198748-191373/root/tmp/scmroot/tecnoballz.

Example build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3577090

I really wonder what's going on... I can build locally, I can even
submit the srpm I create with fedpkg to koji with no problem.

Any help appreciated.

Bye,

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

Re: BuildError: No srpms found

[Andrea Musuruane]

On Sat, Dec 10, 2011 at 5:05 PM, Mathieu Bridon
boche...@fedoraproject.org wrote:
 Did you forget to commit/push that patch? :)

It seems so (blush)

Thanks,

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

Re: PDFCrack - empty debuginfo file

[Andrea Musuruane]

On Fri, Oct 21, 2011 at 3:29 PM, P J P pj.pan...@yahoo.co.in wrote:
 I'm trying to package the PDFCrack tool for Fedora,
 Somehow it is creating an empty DebugInfo package.

 Could someone tell why it is creating an empty debuginfo package?

Because it executes strip pdfcrack :)

Bye,

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

Re: package installation statistics

[Andrea Musuruane]

2011/6/3 Björn Persson bj...@xn--rombobjrn-67a.se:
 There's no reason why Debian's Popcon couldn't be ported to Fedora, but Popcon
 is something that users enable voluntarily (and it must be, because if it were
 on by default it would be spyware), so it counts only those users who want to
 be counted which may skew the statistics in some ways.

If someone is interested I found that OpenSUSE modified popcon to use
RPM and called it popcorn:
http://gitorious.org/opensuse/popcorn

Regards,

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

F15 and HP printer

[Andrea Musuruane]

Hi all,
I just installed F15 over my old F14 (I just kept /home). I tried
installing my printer (HP Deskjet 5740) and I failed miserably.

First, accessing the printer panel from the system settings was
useless. No printer could be detected.

Then, I tried to run hp-setup from a root terminal. It wasn't
installed, and yum took care to install and run it. But it returned
the following error:

error: Install the hplip-gui package for graphical support.
warning: Qt/PyQt 4 initialization failed.
error: hp-setup requires GUI support (try running with --qt3). Also,
try using interactive (-i) mode.

It seems like a missing dependency. Anyway, I later manually installed
hplip-gui.

Running again hp-setup from the command line leads to the following error:

**
GLib-GIO:ERROR:gdbusconnection.c:2279:initable_init: assertion failed:
(connection-initialization_error == NULL)
Annullato (core dumped)

Then I run HP Device Manager directly from the GUI. The printer was
detected but the device manager wasn't able to detect a suitable PPD
file for my printer (and I couldn't too as it seems it is no longer
present).

It is a bit difficult for me to understand where it lays the problem
(and if it can be solve it) and against what to report bugs... it
seems that most printing system is utterly broken (at least for me).

I had no problem at all up to Fedora 14.

Regards,

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

Re: F15 and HP printer

[Andrea Musuruane]

On Sun, May 29, 2011 at 4:19 PM, Mike Chambers m...@miketc.net wrote:
 On Sun, 2011-05-29 at 10:26 +0200, Andrea Musuruane wrote:
 Hi all,
     I just installed F15 over my old F14 (I just kept /home). I tried
 installing my printer (HP Deskjet 5740) and I failed miserably.

 First, I would totally delete the printer from your system, unplug it
 from the computer and totally wipe it clean as in the system recognized
 or sees NO printer at all when it's booted.

 Turn off printer, plug in to computer, make sure it's on and then turn
 on the computer.  Your computer should pick it up and install it, esp
 being HP printer and working with linux all the time.  Mine is detected
 all by itself and never have to do anything.

 If your computer isn't detected on it's own by itself (how is it
 connected btw, usb cable?), try like someone else said,
 system-config-printer and see if that works.

I installed system-config-printer at the next boot and I found the
printer already installed inside it without any manual operation. I
could even print a test page.

Then I uninstalled system-config-printer, rebooted again, and I could
still see the printer and print from various applications.

I have no idea what changed between these boots but now I can use my
printer :) Doh!

Thanks for your support guys!

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

Orphaning genesis

[Andrea Musuruane]

Hi all,
 I'm orphaning genesis (a Graphical frontend to SyncEvolution).

Latest upstream release changed focus and now it is on quick access to
basic sync operations, leaving configuration tasks and fine-grained
control to syncevolution-gtk.

Moreover, IMHO it is too strictly linked to Ubuntu development and I
have trouble building (and adapting) it for Fedora.

Regards,

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

[Andrea Musuruane]

On Wed, Nov 24, 2010 at 8:32 AM, Hans de Goede hdego...@redhat.com wrote:
 Hi,

 On 11/24/2010 12:45 AM, Jesse Keating wrote:
 On 10/5/10 3:27 PM, Jesse Keating wrote:

 snip


 Here is a list of the current known potentially bad builds and what
 action could be or has been taken:

 wildmidi - my rebuild can be tagged
 tecnoballz - my build can be tagged

 These 2 are mine and FWIW, I'm ok with directly tagging
 the rebuilds into updates

Actually tecnoballz is mine. But I'm ok with the tagging anyway.

Bye,

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

Retiring genesis

[Andrea Musuruane]

Hi all,
I've read some months late the following announcement regarding genesis:
https://launchpad.net/genesis-sync/+announcement/5958

Genesis is now strictly linked to Ubuntu development deprecating the
system tray altogether and encouraging the use of application
indicators. Moreover the focus is now on quick access to basic sync
operations, leaving configuration tasks and fine-grained control to
syncevolution-gtk.

I do not think it is still valuable to have genesis in Fedora. What
kind of retirement policy do you suggest? I.e. when do you think I
should retire it?

This would be the first package I retire. If I understand correctly I
have to follow this process:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Regards,

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

F12/ Cannot update

[Andrea Musuruane]

Hi all,
If I try to update F12 I get the following error:

# yum update
Plugin abilitati:presto, refresh-packagekit
Impostazione processo di aggiornamento
Risoluzione dipendenze
-- Esecuzione del controllo di transazione
--- Pacchetto firefox.x86_64 0:3.5.12-1.fc12 settato per essere aggiornato
--- Pacchetto xulrunner.x86_64 0:1.9.1.12-1.fc12 settato per essere aggiornato
--- Pacchetto xulrunner-devel.x86_64 0:1.9.1.12-1.fc12 settato per
essere aggiornato
-- Elaborazione dipendenza: pkgconfig(nspr) = 4.8.6 per il
pacchetto: xulrunner-devel-1.9.1.12-1.fc12.x86_64
-- Risoluzione delle dipendenze completata
Errore: Pacchetto: xulrunner-devel-1.9.1.12-1.fc12.x86_64 (updates)
richiede: pkgconfig(nspr) = 4.8.6
Installato: nspr-devel-4.8.4-2.fc12.x86_64 (@updates)
pkgconfig(nspr) = 4.8.4
Disponibile: nspr-devel-4.8.2-1.fc12.i686 (fedora)
pkgconfig(nspr) = 4.8.2
 Si può provare ad usare --skip-broken per aggirare il problema
 Provare ad eseguire: rpm -Va --nofiles --nodigest

What's going on? nspr-4.8.6 is still in testing (with a bad karma).
Why xulrunner has been built against this and pushed to stable? This
brakes the update process in F12.

Regards,

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

Re: The move to git!

[Andrea Musuruane]

On Sat, Jul 31, 2010 at 11:56 AM, Andrea Musuruane musur...@gmail.com wrote:
 OK. I deleted the current repo and started again. I do have
 fedora-packager 0.5.1.

 Now fedora-packager crashes when uploading new sources.

 $ fedpkg clone zaz
 Cloning into zaz...
 [..]
 Resolving deltas: 100% (11/11), done.
 $ cd zaz/
 $ cp -a ~/rpmbuild/SOURCES/zaz-0.8.0.tar.bz2 .
 $ cp -a ~/rpmbuild/SPECS/zaz.spec .
 $ fedpkg new-sources zaz-0.8.0.tar.bz2
 Uploading: 6a63f986a80b4f4e1852ecf9871e9735  zaz-0.8.0.tar.bz2
 Traceback (most recent call last):
  File /usr/bin/fedpkg, line 959, in module
    args.command(args)
  File /usr/bin/fedpkg, line 540, in new_sources
    mymodule.upload(args.files, replace=args.replace)
  File /usr/lib/python2.6/site-packages/pyfedpkg/__init__.py, line
 1278, in upload
    if lookaside.file_exists(self.module, file_basename, file_hash):
  File /usr/lib/python2.6/site-packages/pyfedpkg/__init__.py, line
 580, in file_exists
    curl.perform()
 pycurl.error: (35, 'SSL connect error')
 [and...@panoramix zaz]$

I still have this error. Help is appreciated.

Thanks.

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

Re: The move to git!

[Andrea Musuruane]

On Sun, Aug 1, 2010 at 1:05 PM, Dominic Hopf dma...@googlemail.com wrote:
 I just yesterday had similar problems and then found out my
 ~/.fedora.cert was out of date since five days ago. Maybe it's the same
 for you, did you already had a look there? :)

Yes. It will be valid until Dec  7, 2010.

Bye,

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

Re: The move to git!

[Andrea Musuruane]

On Sun, Aug 1, 2010 at 1:12 PM, Andrea Musuruane musur...@gmail.com wrote:
 On Sun, Aug 1, 2010 at 1:05 PM, Dominic Hopf dma...@googlemail.com wrote:
 I just yesterday had similar problems and then found out my
 ~/.fedora.cert was out of date since five days ago. Maybe it's the same
 for you, did you already had a look there? :)

 Yes. It will be valid until Dec  7, 2010.

It was the client side certificate. Although it was in its validity
period it was no longer valid.

Regards,

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

Re: The move to git!

[Andrea Musuruane]

Hi all,
I do not know anything about GIT and I tried to follow this thread
and the Using_Fedora_GIT in the wiki to make my first commit

The workflow was more or less the following:
$ fedpkg clone zaz
$ cd zaz/
$ cp -a ~/rpmbuild/SOURCES/zaz-0.8.0.tar.bz2 .
$ cp -a ~/rpmbuild/SPECS/zaz.spec .
$ fedpkg new-sources zaz-0.8.0.tar.bz2
$ git diff
$ git config --global --add push.default tracking
$ fedpkg clog
$ fedpkg commit -F clog -p

I tried to use federa-packager available from updates. fedpkg commit
-F clog -p did not succeed.

Then I installed the latest federa-packager from updates-testing and
fedpkg commit -F clog -p now crashes. It even crashes with fedpkg
clog. The error is the same.

$ fedpkg clog
Traceback (most recent call last):
  File /usr/bin/fedpkg, line 959, in module
args.command(args)
  File /usr/bin/fedpkg, line 390, in clog
mymodule = pyfedpkg.PackageModule(args.path)
  File /usr/lib/python2.6/site-packages/pyfedpkg/__init__.py, line
744, in __init__
self.distval = self._findmasterbranch()
  File /usr/lib/python2.6/site-packages/pyfedpkg/__init__.py, line
694, in _findmasterbranch
return(int(fedoras[-1].strip('f')) + 1)
IndexError: list index out of range

Help is really appreciated.

Thanks!

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

Re: The move to git!

[Andrea Musuruane]

On Sat, Jul 31, 2010 at 11:50 AM, Rahul Sundaram methe...@gmail.com wrote:
  On 07/31/2010 03:19 PM, Andrea Musuruane wrote:
 l    return(int(fedoras[-1].strip('f')) + 1)
 IndexError: list index out of range

 Help is really appreciated.

 Thanks!

 make sure you update fedora-packager to 0.5.1, remove and clone the repo
 again and follow the same steps. It will work.

OK. I deleted the current repo and started again. I do have
fedora-packager 0.5.1.

Now fedora-packager crashes when uploading new sources.

$ fedpkg clone zaz
Cloning into zaz...
[..]
Resolving deltas: 100% (11/11), done.
$ cd zaz/
$ cp -a ~/rpmbuild/SOURCES/zaz-0.8.0.tar.bz2 .
$ cp -a ~/rpmbuild/SPECS/zaz.spec .
$ fedpkg new-sources zaz-0.8.0.tar.bz2
Uploading: 6a63f986a80b4f4e1852ecf9871e9735  zaz-0.8.0.tar.bz2
Traceback (most recent call last):
  File /usr/bin/fedpkg, line 959, in module
args.command(args)
  File /usr/bin/fedpkg, line 540, in new_sources
mymodule.upload(args.files, replace=args.replace)
  File /usr/lib/python2.6/site-packages/pyfedpkg/__init__.py, line
1278, in upload
if lookaside.file_exists(self.module, file_basename, file_hash):
  File /usr/lib/python2.6/site-packages/pyfedpkg/__init__.py, line
580, in file_exists
curl.perform()
pycurl.error: (35, 'SSL connect error')
[and...@panoramix zaz]$

Regards,

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

Re: New Hatari version: need help

[Andrea Musuruane]

2010/6/19 Alexander Boström a...@root.snowtree.se:
 lör 2010-06-19 klockan 19:32 +0200 skrev Andrea Musuruane:

 I do not know how should I threat those internal libraries. How should
 I package them? Because upstream uses static libraries the dynamic
 versions cmake creates are not versioned.

 https://fedoraproject.org/wiki/Packaging:Guidelines#Rpath_for_Internal_Libraries

I fail to see how this is relevant. Hatari do not use Rpath.

Regards,

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

Re: New Hatari version: need help

[Andrea Musuruane]

On Sat, Jun 19, 2010 at 7:44 PM, Chen Lei supercyp...@gmail.com wrote:
 You can open a RFE report against this package in bugzilla for review.

Can you point me to an example?

 For internal libs, if those libs are not libs from other project, you
 can simply use %cmake  -DBUILD_SHARED_LIBS:BOOL=OFF to avoid
 generation of those shlibs. Default place for python ui don't need
 change.

Internal libs are made by Hatari developers and therefore they haven't
a different upstream.

Thanks!

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

New Hatari version: need help

[Andrea Musuruane]

Hi all,
 a new version of Hatari has recently been released:
http://hatari.berlios.de/

The new version drops the old build system based on autotools and now
it only support cmake. An (optional) python GUI is now bundled with
the emulator. Moreover some static libraries have been introduced and
%cmake will output them as dynamic libraries because of
-DBUILD_SHARED_LIBS:BOOL=ON is defined in the macro itself.

I wonder if this package needs a new review request because of these changes.

I do not know how should I threat those internal libraries. How should
I package them? Because upstream uses static libraries the dynamic
versions cmake creates are not versioned.

The python UI by default places python files in
/usr/share/hatari/hatariui/. Is this acceptable or should I patch it
to place them in /usr/share/hatariui/ ?

Thanks in advance for you advices.

Regards,

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

Re: Desktop categories

[Andrea Musuruane]

On Fri, Jan 15, 2010 at 8:42 PM, Alain Portal alain.por...@free.fr wrote:
 I'm sorry, I forgot to answer this :-(
 And I see that perhaps, I wasn't very clear in my question.
 I'm talking about the Categories entry.

 I could see in some desktop files provided by applications that some
 distributions (Mandriva, Suse) have their own categories, and KDE too.
 Examples:

 - X-MandrivaLinux-System-Archiving-Backup
 - X-SuSE-Backup
 - X-KDE-Utilities-File

 Of course, I removed the others distributions relative one, but where to find 
 a
 list of KDE specific categories?
 Are there Fedora specific categories?

For most, we use standard Freedesktop categories. A list is here:
http://standards.freedesktop.org/menu-spec/latest/apa.html

I think that the only exception (and it is really an add-on) it is this one:
https://fedoraproject.org/wiki/Features/FedoraStudio

Bye,

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