Re: F26 System Wide Change: DNF 2.0
On Fri, Sep 9, 2016 at 10:00 PM, Igor Gnatenko wrote: > If it requires actions from releng, then it's system-wide change. But > it's not about changing existing process of building distro, it's just > bugfixing releng tools. No, the need of rel-eng's involvement does not define whether something is a system wide change. This is a change to a core piece of Fedora that is potentially impacting (IE the ability to upgrade the system) so this _IS_ a system wide change. > So I'm not sure. > > On Fri, Sep 9, 2016 at 10:38 PM, Mathieu Bridon wrote: >> Hi, >> >> On Fri, 2016-09-09 at 16:49 +0200, Jan Kurik wrote: >>> = Proposed System Wide Change: DNF 2.0 = >> >> This email says it is a system-wide change. >> >>> https://fedoraproject.org/wiki/Changes/DNF-2.0 >> >> But this page keeps saying « not a System Wide Change ». >> >> Which is? :) >> >> >> -- >> Mathieu >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > > > > -- > -Igor Gnatenko > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Please clean up unneeded files from fedorapeople.org groups and repos
On Fri, Sep 9, 2016 at 9:40 PM, Kevin Fenzi wrote: > On Fri, 9 Sep 2016 08:37:19 +0200 > Igor Gnatenko wrote: > >> Kevin, help me please with cleanup: >> >> [ignatenkobrain@people02 ~][PROD]$ rm -rf >> /home/fedora/ignatenkobrain/public_git/* >> rm: cannot remove >> ‘/home/fedora/ignatenkobrain/public_git/shiny.git/objects/20/3a73563e678017862cc45354588d40a967a57d’: >> Permission denied >> rm: cannot remove >> ‘/home/fedora/ignatenkobrain/public_git/shiny.git/objects/8b/cff8eb33b25bef2d995ce4bc420153f2c1aade’: >> Permission denied >> rm: cannot remove >> ‘/home/fedora/ignatenkobrain/public_git/shiny.git/objects/a8/3159425e2105565b79d0daeef7e16073d0d32a’: >> Permission denied >> rm: cannot remove >> ‘/home/fedora/ignatenkobrain/public_git/shiny.git/objects/e5/2ea1c393718f48e74abf0c2062b753cb542f4c’: >> Permission denied >> rm: cannot remove >> ‘/home/fedora/ignatenkobrain/public_git/shiny.git/objects/ef/56842f0422bf92e453ec47c8f1556bdeb04b77’: >> Permission denied >> rm: cannot remove >> ‘/home/fedora/ignatenkobrain/public_git/shiny.git/objects/f0/5c6e5deddbcc835948588534b0c2f34248d6f6’: >> Permission denied > > Removed. Thanks! > > Those were files pushed by someone else into your repo. I would have > thought acls would allow you to remove them, but the acls seem to have > gotten lost somewhere. I used recipe from our wiki with setfacl to give someone else access to repo. > > Anyhow, they are removed and thanks for cleaning up your space. > > kevin > > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- -Igor Gnatenko -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
comiing to koji aarch64
Hi All, We are in the process of importing aarch64 to the primary koji instance as part of https://fedoraproject.org/wiki/Architectures/ RedefiningSecondaryArchitectures The import and enablement of aarch64 is for rawhide only, we expect to add power big and little endiian sometime before the mass rebuild. We will be making changes to the compose process early next week to enable aarch64 in the rawhide compose, at the same time i386 we be moving from /pub/ fedora/ to /pub/fedora-secondary/ A further announcement will come when building of aarch64 is enabled Thanks Peter and Dennis ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel-annou...@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: comiing to koji aarch64
On Sat, Sep 10, 2016 at 4:19 PM, Dennis Gilmore wrote: > Hi All, > > We are in the process of importing aarch64 to the primary koji instance as > part of https://fedoraproject.org/wiki/Architectures/ > RedefiningSecondaryArchitectures The import and enablement of aarch64 is for > rawhide only, we expect to add power big and little endiian sometime before > the mass rebuild. > > We will be making changes to the compose process early next week to enable > aarch64 in the rawhide compose, at the same time i386 we be moving from /pub/ > fedora/ to /pub/fedora-secondary/ > > A further announcement will come when building of aarch64 is enabled Nice! /me enabled aarch64 arch for LuaJIT few weeks ago. > > > Thanks > > Peter and Dennis > ___ > devel-announce mailing list > devel-annou...@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel-annou...@lists.fedoraproject.org > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- -Igor Gnatenko -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: comiing to koji aarch64
On Sat, Sep 10, 2016 at 10:19 AM, Dennis Gilmore wrote: > at the same time i386 we be moving from /pub/ > fedora/ to /pub/fedora-secondary/ When was this agreed upon? I don't recall this being discussed. With ~20% of our downloads for Workstation and related desktop spins still being x86_32, and the requirement that we need the i686 RPMs to merge into the x86_64 repositories, why are we doing this? -- 真実はいつも一つ！/ Always, there's only one truth! -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
[Fwd: build perl problem on mythtv]
this is a 3rd part repo but you may have better acknowledgment of what
happen
Forwarded Message
From: Sérgio Basto
Reply-to: RPM Fusion developers discussion list
To: rpmfusion devel
Cc: Richard Shaw
Subject: build perl problem on mythtv
Date: Sat, 10 Sep 2016 16:38:34 +0100
Hi,
in F25 I can't install mythtv-status because Requires: perl(MythTV)
and perl-MythTV-0.28-5.fc25.noarch.rpm no longer provides perl(MythTV)
the rebuild of mythtv-0.28-5.fc25
http://koji.rpmfusion.org/koji/buildinfo?buildID=1999
all build logs have 6 times :
sh: /usr/bin/perl: No such file or directory
and other 6 times
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
I try understand what is happened but failed ,
maybe glibc in Fedora rawhide now split by langpacks
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject
.org/message/J6DQABIQJ66YVATAETWWIBY7WZGVV5T4/
or Build Root Without Perl
https://fedoraproject.org/wiki/Changes/Build_Root_Without_Perl#Upgrade.
2Fcompatibility_impact
any tip ?
Thanks,
--
Sérgio M. B.
--
Sérgio M. B.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [Fwd: build perl problem on mythtv]
On Sat, Sep 10, 2016 at 6:03 PM, Sérgio Basto wrote:
> this is a 3rd part repo but you may have better acknowledgment of what
> happen
>
>
> Forwarded Message
> From: Sérgio Basto
> Reply-to: RPM Fusion developers discussion list develop...@lists.rpmfusion.org>
> To: rpmfusion devel
> Cc: Richard Shaw
> Subject: build perl problem on mythtv
> Date: Sat, 10 Sep 2016 16:38:34 +0100
>
> Hi,
> in F25 I can't install mythtv-status because Requires: perl(MythTV)
> and perl-MythTV-0.28-5.fc25.noarch.rpm no longer provides perl(MythTV)
>
> the rebuild of mythtv-0.28-5.fc25
> http://koji.rpmfusion.org/koji/buildinfo?buildID=1999
>
> all build logs have 6 times :
> sh: /usr/bin/perl: No such file or directory
>
> and other 6 times
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
> LANGUAGE = (unset),
> LC_ALL = (unset),
> LANG = "en_US.UTF-8"
> are supported and installed on your system.
> perl: warning: Falling back to the standard locale ("C").
>
>
> I try understand what is happened but failed ,
> maybe glibc in Fedora rawhide now split by langpacks
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject
> .org/message/J6DQABIQJ66YVATAETWWIBY7WZGVV5T4/
>
> or Build Root Without Perl
> https://fedoraproject.org/wiki/Changes/Build_Root_Without_Perl#Upgrade.
> 2Fcompatibility_impact
>
> any tip ?
I guess missing BuildRequires: perl-generators
>
> Thanks,
> --
> Sérgio M. B.
> --
> Sérgio M. B.
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [Fwd: build perl problem on mythtv]
On Sáb, 2016-09-10 at 18:05 +0200, Igor Gnatenko wrote:
> On Sat, Sep 10, 2016 at 6:03 PM, Sérgio Basto
> wrote:
> >
> > this is a 3rd part repo but you may have better acknowledgment of
> > what
> > happen
> >
> >
> > Forwarded Message
> > From: Sérgio Basto
> > Reply-to: RPM Fusion developers discussion list > develop...@lists.rpmfusion.org>
> > To: rpmfusion devel
> > Cc: Richard Shaw
> > Subject: build perl problem on mythtv
> > Date: Sat, 10 Sep 2016 16:38:34 +0100
> >
> > Hi,
> > in F25 I can't install mythtv-status because Requires: perl(MythTV)
> > and perl-MythTV-0.28-5.fc25.noarch.rpm no longer provides
> > perl(MythTV)
> >
> > the rebuild of mythtv-0.28-5.fc25
> > http://koji.rpmfusion.org/koji/buildinfo?buildID=1999
> >
> > all build logs have 6 times :
> > sh: /usr/bin/perl: No such file or directory
> >
> > and other 6 times
> > perl: warning: Setting locale failed.
> > perl: warning: Please check that your locale settings:
> > LANGUAGE = (unset),
> > LC_ALL = (unset),
> > LANG = "en_US.UTF-8"
> > are supported and installed on your system.
> > perl: warning: Falling back to the standard locale ("C").
> >
> >
> > I try understand what is happened but failed ,
> > maybe glibc in Fedora rawhide now split by langpacks
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedorapro
> > ject
> > .org/message/J6DQABIQJ66YVATAETWWIBY7WZGVV5T4/
> >
> > or Build Root Without Perl
> > https://fedoraproject.org/wiki/Changes/Build_Root_Without_Perl#Upgr
> > ade.
> > 2Fcompatibility_impact
> >
> > any tip ?
> I guess missing BuildRequires: perl-generators
I already had add BuildRequires: perl-generators , not fix it.
--
Sérgio M. B.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedorahosted.org sunset: 2017-02-28
On Fri, 09 Sep 2016 17:54:07 -0700 Adam Williamson wrote: > On Wed, 2016-09-07 at 10:44 -0600, Kevin Fenzi wrote: > > Greetings. > > > > Fedora Infrastructure currently maintains two sites for general open > > source code hosting: fedorahosted.org and pagure.io. > > > > Fedorahosted.org was established in late 2007 using Trac for issues > > and wiki pages, Fedora Account System groups for access control and > > source uploads, and offering a variety of Source Control Management > > tools (git, svn, hg, bzr). With the rise of new workflows and source > > repositories fedorahosted.org has ceased to grow, adding just one > > new project this year and a handful the year before. > > I'm replying here as I'm not subscribed to users@. > > Pagure is fine for code projects, but we (still) use the fedora-qa > trac instance for tracking non-code-related activity, like arranging > Test Days. Is Pagure the recommended replacement for this kind of > purpose also? It doesn't feel right. If not, what is? Thanks! Yes it is. At least I am planning on moving the trac's that I control that do this sort of thing to pagure. There's been a lot of improvement to pagure's issues of late and lots of discussion of more. I think it meets the simple needs right now. More complex workflows are under discussion still, so if you need them, you might want to wait and/or join the discussion. I'm likely to move infrastructure over very soon and perhaps a bunch more of the smaller ones. kevin pgpPvi_ZWrybT.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: comiing to koji aarch64
On Sat, 10 Sep 2016 11:35:15 -0400 Neal Gompa wrote: > On Sat, Sep 10, 2016 at 10:19 AM, Dennis Gilmore > wrote: > > at the same time i386 we be moving from /pub/ > > fedora/ to /pub/fedora-secondary/ > > When was this agreed upon? I don't recall this being discussed. With > ~20% of our downloads for Workstation and related desktop spins still > being x86_32, and the requirement that we need the i686 RPMs to merge > into the x86_64 repositories, why are we doing this? Fesco ticket: https://fedorahosted.org/fesco/ticket/1592 Comment thread on this very list with 23 posts: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/3BO5E2XZ2D7BHK7GQXZB5S37AQIUN6YP/ wiki page outlining the change: https://fedoraproject.org/wiki/Architectures/RedefiningSecondaryArchitectures Multiple fesco meetings since the ticket was filed. kevin pgpXFWNNiojEN.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: comiing to koji aarch64
On Saturday, September 10, 2016 11:35:15 AM CDT Neal Gompa wrote: > On Sat, Sep 10, 2016 at 10:19 AM, Dennis Gilmore wrote: > > at the same time i386 we be moving from /pub/ > > fedora/ to /pub/fedora-secondary/ > > When was this agreed upon? I don't recall this being discussed. With > ~20% of our downloads for Workstation and related desktop spins still > being x86_32, and the requirement that we need the i686 RPMs to merge > into the x86_64 repositories, why are we doing this? it does not break either of them. there will be one compose for all of teh arches, multilib will still exist as will i386 it will be in a slightly different location. when FESCo decided none of 32 bit x86 was release blocking they made it alternative Dennis -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: comiing to koji aarch64
On Saturday, September 10, 2016 9:19:27 AM CDT Dennis Gilmore wrote: > Hi All, > > We are in the process of importing aarch64 to the primary koji instance as > part of https://fedoraproject.org/wiki/Architectures/ > RedefiningSecondaryArchitectures The import and enablement of aarch64 is > for rawhide only, we expect to add power big and little endiian sometime > before the mass rebuild. > > We will be making changes to the compose process early next week to enable > aarch64 in the rawhide compose, at the same time i386 we be moving from > /pub/ fedora/ to /pub/fedora-secondary/ > > A further announcement will come when building of aarch64 is enabled > > > Thanks > > Peter and Dennis aarch64 builds are enabled in rawhide now, there is one issue that needs eclipse to be rebootstrapped, A bug has been filed[1] If you notice anyissues please file an issue in pagure[2] Thanks Dennis [1] https://bugzilla.redhat.com/show_bug.cgi?id=1374938 [2] https://pagure.io/releng/issues ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel-annou...@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
GDB: Recommends vs. Suggests and abrt->gdb->gcc dependency
Hi,
there have been submitted these Bugs:
Drop the gcc dependency
https://bugzilla.redhat.com/show_bug.cgi?id=1195005
gdb pulls in devel packages (gcc, kernel-headers, etc.) [former Summary]
https://bugzilla.redhat.com/show_bug.cgi?id=1306591
due to recent GDBs having new:
Recommends: gcc-gdb-plugin%{?_isa}
which brings in the whole GCC compiler. Reasons for this new Recommends are
at the bottom of this mail labeled: Why to use gcc-gdb-plugin
Given that ABRT is installed by default and ABRT
Requires: gdb
this dependency installs GCC now even on servers and end-user machines (AFAIK,
I haven't tried that but it does make sense).
I believe that from the error message:
(gdb) compile print EXPRESSION
Could not load libcc1.so: libcc1.so: cannot open shared object file: No
such file or directory
a Fedora user does not realize s/he should run:
# dnf install gcc-gdb-plugin
Which is why I made it Recommends and not Suggests. Also in the close future
GDB will provide more functional
(gdb) print EXPRESSION
feature only with gcc-gdb-plugin installed. Just ABRT does not need
'print EXPRESSION' to use gcc-gdb-plugin but I guess any user running GDB
interatively does use 'print EXPRESSION'.
Unrelated to gcc-gdb-plugin there is already this 'dnf'-suggesting GDB message:
$ gdb -q true
Missing separate debuginfos, use: dnf debuginfo-install
coreutils-8.25-14.fc25.x86_64
(gdb) _
Therefore I could patch Fedora GDB to also print instead:
(gdb) compile print EXPRESSION
Missing compiler, use: dnf install gcc-gdb-plugin
But that debuginfo-install command is already wrong on its own, despite Fedora
GDB prints that for 8 years now (sure with yum before). One inconvenience is
that one has to copy-paste it, instead of just some YES confirmation to run
that command. But GUI users probably do not want to run 'dnf' from a shell
- they want to run some GUI package manager instead (I do not know which one).
One can also see that such message does not work for GUI frontends of GDB:
$ cdtdebug -e true
If you do not have coreutils-debuginfo.rpm installed then Eclipse will print
just:
No source available for "main() at 0x7480"
without any hint one could run debuginfo-install to fix that.
Another possibility is to change ABRT so that it only Suggests GDB and ABRT
provides some user interface to install gdb.rpm upon demand:
https://bugzilla.redhat.com/show_bug.cgi?id=1195005#c18
This just moves this problem from GDB to ABRT.
As a summary: Is there a 'sudo dnf install' (and 'sudo dnf debuginfo-install')
like command which does use GUI package manager if $DISPLAY is available?
GDB could also run some different command if $DISPLAY is available.
Is this the recommended solution? Or should I submit a FESCo ticket?
Thanks,
Jan
--
Why to use gcc-gdb-plugin:
The primary goal is to support complex expressions needed for C++ debugging.
Unfortunately current GDB does not yet support gcc-gdb-plugin for C++,
currently only C is supported. Therefore providing a usecase for C below.
More thorough background about C++ can be found at:
https://sourceware.org/gdb/wiki/GCCCompileAndExecute#History_and_Genesis
gcc-gdb-plugin is now required for
(gdb) compile print ...
such as:
echo -e '#include \nint main(){return (int)HUGE_VAL;}' >1.c|gcc
-Wall -g3 1.c;gdb -q ./a.out -ex start
Reading symbols from ./a.out...done.
Temporary breakpoint 1 at 0x4004aa: file 1.c, line 2.
Starting program: /tmp/a.out
Temporary breakpoint 1, main () at 1.c:2
2 int main(){return (int)HUGE_VAL;}
(gdb) info macro HUGE_VAL
Defined at /usr/include/bits/huge_val.h:27
included at /usr/include/math.h:36
included at /tmp/1.c:1
#define HUGE_VAL (__builtin_huge_val())
->
(gdb) print HUGE_VAL
No symbol "__builtin_huge_val" in current context.
vs.
(gdb) compile print HUGE_VAL
$1 = inf
Without gcc-gdb-plugin GDB would print only:
(gdb) compile print HUGE_VAL
Could not load libcc1.so: libcc1.so: cannot open shared object file: No
such file or directory
Additionally it is expected that future GDB will use
(gdb) compile print EXPRESSION
for any use of:
(gdb) compile EXPRESSION
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Video performance degradation in F24
On 09/08/2016 01:27 AM, Benson Muite wrote: > Blog post here may be relevant: > > https://streamcomputing.eu/blog/2016-09-06/transition-period-for-fglrx-to-amdgpurocm-no-kernel-4-4-or-xorg-1-18-support/ > > > Not sure exact hardware you are using, so may not be directly relevant. > If it is, there is a recent Fedora magazine article on applying kernel > patches. > > > > On 09/08/2016 03:44 AM, Basil Mohamed Gohar wrote: >> Even since I installed F24 on both my desktop as well as my laptop I've >> noticed a severe performance degradation in terms of video playback. >> One point of note is that I did an upgrade from F22->F23->F24, only >> using F23 for the upgrade process. >> >> I've noticed this performance issue in both MATE (my preferred DE) as >> well as Gnome. I have AMD CPUs with AMD GPUs (the laptop is an APU but >> also has a discrete card as well). >> >> I don't want to use devel just to report a problem, but I'd also like >> some help in diagnosing the issue so that a fix can be found – but >> unfortunately I don't really know where to start. Benson, Thank you for that information. However, I don't use fglrx, I've always used the radeon drivers that come standard in Fedora. > [basilgohar@alpha ~]$ lsmod | grep radeon > radeon 1507328 9 > i2c_algo_bit 16384 1 radeon > drm_kms_helper143360 1 radeon > ttm90112 1 radeon > drm 339968 12 ttm,drm_kms_helper,radeon So, unless that issue also means standard open-source kernel drivers are lacking support for the kernel used in F24 (which would seem really very odd), then that particular issue is probably not the reason for my slow video. -- Libre Video http://librevideo.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: GDB: Recommends vs. Suggests and abrt->gdb->gcc dependency
Unfortunately if you will put Suggests - DNF will use it for
"priority", not as recommending some package to install. It will stay
as this for quite some time..
From GUI you can use PackageKit (via DBus), same you can do from
terminal to ask for installing package.
On Sat, Sep 10, 2016 at 10:49 PM, Jan Kratochvil
wrote:
> Hi,
>
> there have been submitted these Bugs:
> Drop the gcc dependency
> https://bugzilla.redhat.com/show_bug.cgi?id=1195005
> gdb pulls in devel packages (gcc, kernel-headers, etc.) [former
> Summary]
> https://bugzilla.redhat.com/show_bug.cgi?id=1306591
>
> due to recent GDBs having new:
> Recommends: gcc-gdb-plugin%{?_isa}
> which brings in the whole GCC compiler. Reasons for this new Recommends are
> at the bottom of this mail labeled: Why to use gcc-gdb-plugin
>
> Given that ABRT is installed by default and ABRT
> Requires: gdb
> this dependency installs GCC now even on servers and end-user machines (AFAIK,
> I haven't tried that but it does make sense).
>
> I believe that from the error message:
> (gdb) compile print EXPRESSION
> Could not load libcc1.so: libcc1.so: cannot open shared object file:
> No such file or directory
> a Fedora user does not realize s/he should run:
> # dnf install gcc-gdb-plugin
> Which is why I made it Recommends and not Suggests. Also in the close future
> GDB will provide more functional
> (gdb) print EXPRESSION
> feature only with gcc-gdb-plugin installed. Just ABRT does not need
> 'print EXPRESSION' to use gcc-gdb-plugin but I guess any user running GDB
> interatively does use 'print EXPRESSION'.
>
> Unrelated to gcc-gdb-plugin there is already this 'dnf'-suggesting GDB
> message:
> $ gdb -q true
> Missing separate debuginfos, use: dnf debuginfo-install
> coreutils-8.25-14.fc25.x86_64
> (gdb) _
>
> Therefore I could patch Fedora GDB to also print instead:
> (gdb) compile print EXPRESSION
> Missing compiler, use: dnf install gcc-gdb-plugin
>
> But that debuginfo-install command is already wrong on its own, despite Fedora
> GDB prints that for 8 years now (sure with yum before). One inconvenience is
> that one has to copy-paste it, instead of just some YES confirmation to run
> that command. But GUI users probably do not want to run 'dnf' from a shell
> - they want to run some GUI package manager instead (I do not know which one).
>
> One can also see that such message does not work for GUI frontends of GDB:
> $ cdtdebug -e true
> If you do not have coreutils-debuginfo.rpm installed then Eclipse will print
> just:
> No source available for "main() at 0x7480"
> without any hint one could run debuginfo-install to fix that.
>
> Another possibility is to change ABRT so that it only Suggests GDB and ABRT
> provides some user interface to install gdb.rpm upon demand:
> https://bugzilla.redhat.com/show_bug.cgi?id=1195005#c18
> This just moves this problem from GDB to ABRT.
>
> As a summary: Is there a 'sudo dnf install' (and 'sudo dnf debuginfo-install')
> like command which does use GUI package manager if $DISPLAY is available?
> GDB could also run some different command if $DISPLAY is available.
> Is this the recommended solution? Or should I submit a FESCo ticket?
>
>
> Thanks,
> Jan
>
> --
> Why to use gcc-gdb-plugin:
>
> The primary goal is to support complex expressions needed for C++ debugging.
> Unfortunately current GDB does not yet support gcc-gdb-plugin for C++,
> currently only C is supported. Therefore providing a usecase for C below.
> More thorough background about C++ can be found at:
>
> https://sourceware.org/gdb/wiki/GCCCompileAndExecute#History_and_Genesis
>
> gcc-gdb-plugin is now required for
> (gdb) compile print ...
> such as:
> echo -e '#include \nint main(){return (int)HUGE_VAL;}'
> >1.c|gcc -Wall -g3 1.c;gdb -q ./a.out -ex start
> Reading symbols from ./a.out...done.
> Temporary breakpoint 1 at 0x4004aa: file 1.c, line 2.
> Starting program: /tmp/a.out
> Temporary breakpoint 1, main () at 1.c:2
> 2 int main(){return (int)HUGE_VAL;}
> (gdb) info macro HUGE_VAL
> Defined at /usr/include/bits/huge_val.h:27
> included at /usr/include/math.h:36
> included at /tmp/1.c:1
> #define HUGE_VAL (__builtin_huge_val())
> ->
> (gdb) print HUGE_VAL
> No symbol "__builtin_huge_val" in current context.
> vs.
> (gdb) compile print HUGE_VAL
> $1 = inf
>
> Without gcc-gdb-plugin GDB would print only:
> (gdb) compile print HUGE_VAL
> Could not load libcc1.so: libcc1.so: cannot open shared object file:
> No such file or directory
>
> Additionally it is expected that future GDB will use
> (gdb) compile print EXPRESSION
> for any use of:
> (gd
Re: [Fwd: build perl problem on mythtv]
On Sáb, 2016-09-10 at 18:14 +0100, Sérgio Basto wrote:
> On Sáb, 2016-09-10 at 18:05 +0200, Igor Gnatenko wrote:
> >
> > On Sat, Sep 10, 2016 at 6:03 PM, Sérgio Basto
> > wrote:
> > >
> > >
> > > this is a 3rd part repo but you may have better acknowledgment of
> > > what
> > > happen
> > >
> > >
> > > Forwarded Message
> > > From: Sérgio Basto
> > > Reply-to: RPM Fusion developers discussion list > > develop...@lists.rpmfusion.org>
> > > To: rpmfusion devel
> > > Cc: Richard Shaw
> > > Subject: build perl problem on mythtv
> > > Date: Sat, 10 Sep 2016 16:38:34 +0100
> > >
> > > Hi,
> > > in F25 I can't install mythtv-status because Requires:
> > > perl(MythTV)
> > > and perl-MythTV-0.28-5.fc25.noarch.rpm no longer provides
> > > perl(MythTV)
> > >
> > > the rebuild of mythtv-0.28-5.fc25
> > > http://koji.rpmfusion.org/koji/buildinfo?buildID=1999
> > >
> > > all build logs have 6 times :
> > > sh: /usr/bin/perl: No such file or directory
> > >
> > > and other 6 times
> > > perl: warning: Setting locale failed.
> > > perl: warning: Please check that your locale settings:
> > > LANGUAGE = (unset),
> > > LC_ALL = (unset),
> > > LANG = "en_US.UTF-8"
> > > are supported and installed on your system.
> > > perl: warning: Falling back to the standard locale ("C").
> > >
> > >
> > > I try understand what is happened but failed ,
> > > maybe glibc in Fedora rawhide now split by langpacks
> > > https://lists.fedoraproject.org/archives/list/devel@lists.fedorap
> > > ro
> > > ject
> > > .org/message/J6DQABIQJ66YVATAETWWIBY7WZGVV5T4/
> > >
> > > or Build Root Without Perl
> > > https://fedoraproject.org/wiki/Changes/Build_Root_Without_Perl#Up
> > > gr
> > > ade.
> > > 2Fcompatibility_impact
> > >
> > > any tip ?
> >
> > I guess missing BuildRequires: perl-generators
> I already had add BuildRequires: perl-generators , not fix it.
Found the problem , when we use mock with
config_opts['package_manager'] = 'yum'
locale -a fails [1]
rpm -qa | grep glibc
glibc-common-2.24-3.fc25.x86_64
glibc-headers-2.24-3.fc25.x86_64
glibc-langpack-zu-2.24-3.fc25.x86_64
glibc-devel-2.24-3.fc25.x86_64
glibc-2.24-3.fc25.x86_64
install glibc-all-langpacks fix the problem
but config_opts['package_manager'] = 'dnf' we don't have this problem
...
yum processing
Dependency: glibc-langpack = 2.24-3.fc25 for package: glibc-2.24-
3.fc25.x86_64
Package glibc-langpack-zu.x86_64 0:2.24-3.fc25 will be installed !!!
Should I open a bug against glibc ? (or yum)
[1]
mock -r fedora-25-x86_64 --shell
locale -a
locale: Cannot set LC_CTYPE to default locale: No such file or
directory
locale: Cannot set LC_MESSAGES to default locale: No such file or
directory
locale: Cannot set LC_COLLATE to default locale: No such file or
directory
Cheers,
--
Sérgio M. B.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora 25-20160910.n.0 compose check report
Missing expected images: Cloud_base raw-xz i386 Atomic raw-xz x86_64 Failed openQA tests: 12/92 (x86_64), 1/17 (i386), 1/2 (arm) New failures (same test did not fail in 25-20160909.n.0): ID: 33554 Test: x86_64 Server-dvd-iso server_cockpit_basic URL: https://openqa.fedoraproject.org/tests/33554 ID: 33555 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/33555 ID: 33593 Test: x86_64 universal install_ext3@uefi URL: https://openqa.fedoraproject.org/tests/33593 ID: 33652 Test: x86_64 universal install_delete_partial@uefi URL: https://openqa.fedoraproject.org/tests/33652 Old failures (same test failed in 25-20160909.n.0): ID: 33530 Test: x86_64 Atomic-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/33530 ID: 33539 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/33539 ID: 33564 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/tests/33564 ID: 33585 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/33585 ID: 33603 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/33603 ID: 33604 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/33604 ID: 33605 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/33605 ID: 33606 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/33606 ID: 33607 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/33607 ID: 33623 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/33623 Passed openQA tests: 80/92 (x86_64), 16/17 (i386) New passes (same test did not pass in 25-20160909.n.0): ID: 33543 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/33543 ID: 33545 Test: x86_64 Server-dvd-iso base_selinux URL: https://openqa.fedoraproject.org/tests/33545 ID: 33546 Test: x86_64 Server-dvd-iso base_services_start URL: https://openqa.fedoraproject.org/tests/33546 ID: 33547 Test: x86_64 Server-dvd-iso base_service_manipulation URL: https://openqa.fedoraproject.org/tests/33547 ID: 33551 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller URL: https://openqa.fedoraproject.org/tests/33551 ID: 33552 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/33552 ID: 33553 Test: x86_64 Server-dvd-iso server_cockpit_default URL: https://openqa.fedoraproject.org/tests/33553 ID: 33556 Test: x86_64 Server-dvd-iso realmd_join_sssd URL: https://openqa.fedoraproject.org/tests/33556 ID: 33557 Test: x86_64 Server-dvd-iso server_role_deploy_database_server URL: https://openqa.fedoraproject.org/tests/33557 ID: 33558 Test: x86_64 Server-dvd-iso server_database_client URL: https://openqa.fedoraproject.org/tests/33558 ID: 33560 Test: x86_64 Server-dvd-iso server_firewall_default URL: https://openqa.fedoraproject.org/tests/33560 ID: 33566 Test: x86_64 universal install_repository_http_variation URL: https://openqa.fedoraproject.org/tests/33566 ID: 33577 Test: x86_64 universal install_multi_empty URL: https://openqa.fedoraproject.org/tests/33577 ID: 33592 Test: x86_64 universal install_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/33592 ID: 33621 Test: i386 universal install_lvmthin URL: https://openqa.fedoraproject.org/tests/33621 Skipped openQA tests: 1 of 111 -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora Rawhide-20160910.n.1 compose check report
Missing expected images: Cloud_base raw-xz i386 Atomic raw-xz x86_64 Failed openQA tests: 5/92 (x86_64), 2/17 (i386), 1/2 (arm) New failures (same test did not fail in Rawhide-20160909.n.0): ID: 33418 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/33418 ID: 33443 Test: x86_64 Server-dvd-iso server_cockpit_basic URL: https://openqa.fedoraproject.org/tests/33443 Old failures (same test failed in Rawhide-20160909.n.0): ID: 33419 Test: x86_64 Atomic-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/33419 ID: 33428 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/33428 ID: 33444 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/33444 ID: 33453 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/tests/33453 ID: 33512 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/33512 ID: 33628 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/33628 Passed openQA tests: 87/92 (x86_64), 15/17 (i386) New passes (same test did not pass in Rawhide-20160909.n.0): ID: 33420 Test: x86_64 KDE-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/33420 ID: 33421 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/33421 ID: 33422 Test: x86_64 KDE-live-iso base_selinux URL: https://openqa.fedoraproject.org/tests/33422 ID: 33423 Test: x86_64 KDE-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/33423 ID: 33424 Test: x86_64 KDE-live-iso base_service_manipulation URL: https://openqa.fedoraproject.org/tests/33424 ID: 33425 Test: x86_64 KDE-live-iso desktop_terminal URL: https://openqa.fedoraproject.org/tests/33425 ID: 33426 Test: x86_64 KDE-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/33426 ID: 33427 Test: i386 KDE-live-iso install_default URL: https://openqa.fedoraproject.org/tests/33427 ID: 33475 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/33475 ID: 33507 Test: i386 universal install_software_raid URL: https://openqa.fedoraproject.org/tests/33507 ID: 33513 Test: i386 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/33513 Skipped openQA tests: 1 of 111 -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
