Re: Unannounced soname bump: libcapstone.so.3 -> libcapstone.so.4

[Richard W.M. Jones]

This was fixed upstream in capstone.  I'm rebuilding capstone &
qemu (again) now.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
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

Re: F30: System-Wide Change proposal: DNF UUID

[Adam Williamson]

On Fri, 2019-01-11 at 18:48 -0500, John Harris wrote:
> On Friday, January 11, 2019 4:36:54 PM EST Roberto Ragusa wrote:
> > That is, apply the logic above only if(hash(machine_id)%1000==0)
> > (this becomes a poll instead of a referendum, results must then be
> > multiplied by 1000)
> 
> If this is done, the likelyhood of invalid data for the given Spin is pretty 
> high. For example, Workstation could show as being more popular than all of 
> the other spins combined, just because it's more popular than any given spin 
> (likely because it's advertised prominently, while other spins are hidden 
> behind a link at the middle of the download page).

Just as a note, Workstation isn't a spin, it's a Fedora Edition:

https://fedoraproject.org/wiki/Editions

framing it as if it's "just another spin" is a bit off. Its prominence
is quite intentional and the whole Fedora.next / editions thing was
precisely about picking some specific 'flavors' of Fedora and giving
them prominence over the others.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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

[389-devel] 389 DS nightly 2019-01-12 - 93% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2019/01/12/report-389-ds-base-1.4.0.20-20190112gitc1f96bd.fc29.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org

[Bug 1664970] Upgrade perl-Type-Tiny to 1.004004

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-Type-Tiny-1.004004-1.fc28 has been pushed to the Fedora 28 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-f94fce8c83

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

[Bug 1664970] Upgrade perl-Type-Tiny to 1.004004

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Type-Tiny-1.004004-1.fc29 has been pushed to the Fedora 29 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-2989c80bc2

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

Re: AMD ROCm

[Allan]

På Wed, 9 Jan 2019 11:50:00 +0100
Germano Massullo  skrev:
> Hello,
> AMD ROCm - Open Source Platform for HPC and Ultrascale GPU
> Computing[1] is packaged by upstream only for RHEL/CentOS and Ubuntu.
> Is anybody working on packaging it for Fedora? If not, is anybody
> interested in setting up a team to work on it? 

They have actually made scripts available for Fedora 28 and 29, so
users can compile and use the driver. I did that yesterday, and OpenCL
did work, although a bit slower, than when I previously merged in the
OpenCL drivers from their AMDGPU PRO packages for Centos.

Experimental ROCm:

https://github.com/RadeonOpenCompute/Experimental_ROC


  Allan.

___
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

[Bug 1662960] Upgrade perl-PkgConfig-LibPkgConf to 0.10

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-PkgConfig-LibPkgConf-0 |perl-PkgConfig-LibPkgConf-0
   |.10-1.fc30  |.10-1.fc30
   ||perl-PkgConfig-LibPkgConf-0
   ||.10-1.fc29
 Resolution|--- |ERRATA
Last Closed||2019-01-12 01:57:30



--- Comment #4 from Fedora Update System  ---
perl-PkgConfig-LibPkgConf-0.10-1.fc29 has been pushed to the Fedora 29 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

[Bug 1662957] Upgrade perl-NetPacket to 1.7.0

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-NetPacket-1.7.0-1.fc30 |perl-NetPacket-1.7.0-1.fc30
   |perl-NetPacket-1.7.0-1.fc28 |perl-NetPacket-1.7.0-1.fc28
   ||perl-NetPacket-1.7.0-1.fc29



--- Comment #7 from Fedora Update System  ---
perl-NetPacket-1.7.0-1.fc29 has been pushed to the Fedora 29 stable repository.
If problems still persist, please make note of it in this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

[Bug 1662968] Upgrade perl-Unicode-Collate to 1.26

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Unicode-Collate-1.27-1 |perl-Unicode-Collate-1.27-1
   |.fc30   |.fc30
   ||perl-Unicode-Collate-1.27-1
   ||.fc29
 Resolution|--- |ERRATA
Last Closed||2019-01-12 01:57:32



--- Comment #4 from Fedora Update System  ---
perl-Unicode-Collate-1.27-1.fc29 has been pushed to the Fedora 29 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

[Bug 1662961] Upgrade perl-RT-Client-REST to 0.56

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-RT-Client-REST-0.56-1. |perl-RT-Client-REST-0.56-1.
   |fc30|fc30
   |perl-RT-Client-REST-0.56-1. |perl-RT-Client-REST-0.56-1.
   |fc28|fc28
   ||perl-RT-Client-REST-0.56-1.
   ||fc29



--- Comment #7 from Fedora Update System  ---
perl-RT-Client-REST-0.56-1.fc29 has been pushed to the Fedora 29 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

[Bug 1662961] Upgrade perl-RT-Client-REST to 0.56

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-RT-Client-REST-0.56-1. |perl-RT-Client-REST-0.56-1.
   |fc30|fc30
   ||perl-RT-Client-REST-0.56-1.
   ||fc28
 Resolution|--- |ERRATA
Last Closed||2019-01-12 01:24:02



--- Comment #6 from Fedora Update System  ---
perl-RT-Client-REST-0.56-1.fc28 has been pushed to the Fedora 28 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

[Bug 1662957] Upgrade perl-NetPacket to 1.7.0

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-NetPacket-1.7.0-1.fc30 |perl-NetPacket-1.7.0-1.fc30
   ||perl-NetPacket-1.7.0-1.fc28
 Resolution|--- |ERRATA
Last Closed||2019-01-12 01:24:01



--- Comment #6 from Fedora Update System  ---
perl-NetPacket-1.7.0-1.fc28 has been pushed to the Fedora 28 stable repository.
If problems still persist, please make note of it in this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

Re: F30: System-Wide Change proposal: DNF UUID

[John Harris]

On Friday, January 11, 2019 4:36:54 PM EST Roberto Ragusa wrote:
> That is, apply the logic above only if(hash(machine_id)%1000==0)
> (this becomes a poll instead of a referendum, results must then be
> multiplied by 1000)

If this is done, the likelyhood of invalid data for the given Spin is pretty 
high. For example, Workstation could show as being more popular than all of 
the other spins combined, just because it's more popular than any given spin 
(likely because it's advertised prominently, while other spins are hidden 
behind a link at the middle of the download page).

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

signature.asc
Description: This is a digitally signed message part.
___
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

Re: F30: System-Wide Change proposal: DNF UUID

[Roberto Ragusa]

On 1/8/19 4:22 PM, Lennart Poettering wrote:

> If all you want to do is count, then it should be entirely sufficient
> to do it like this:
> 
>GET /metalink?repo=fedora-28=x86_64==1 HTTP/1.1
> 
> the first time within each one-week window and a simple
> 
>GET /metalink?repo=fedora-28=x86_64= HTTP/1.1
> 
> all other times.

As an additional improvement, is it really needed to count every machine?
We can subsample a lot, and only let some specific machines to show
up for counting.

That is, apply the logic above only if(hash(machine_id)%1000==0)
(this becomes a poll instead of a referendum, results must then be multiplied 
by 1000)

Or, to avoid having somebody constantly be counted and other constantly ignored,
the rule could be if(hash(machine_id)%1000==hash(weekofthecentury)%1000)

With this setup I know that 99.9% of the weeks I'm not reporting anything at 
all.

Of course 1000 is a constant that may be tuned, but looks a good choice
to me if the expected total number is on the order of 1 million.

Regards.

-- 
   Roberto Ragusamail at robertoragusa.it
___
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

[Bug 694496] rpm requirements - provides/requires (tracker)

[bugzilla]

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

Matthew Miller  changed:

   What|Removed |Added

 CC||mat...@redhat.com
  Alias|requirements, rpm   |



--- Comment #4 from Matthew Miller  ---
these are way too generic aliases to assign to this bug. Probably an accident?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

Re: langpacks (Re: F30 System-Wide Change proposal: Replace Comps Language Group With Langpacks)

[Tomasz Kłoczko]

On Fri, 11 Jan 2019 at 13:37, Jakub Jelinek  wrote:

> > So in 107 current Fedora specs are used %lang() macros.
> > Probably some of them can be removed by proper use %find_lang.
>
> The problem with _install_langs is that there is no easy way to change it
> after installation, say you find out you've initially installed just
> English
> and French support, but later you need German and Italian.  rpm nor dnf
> doesn't offer any easy way to add those missing %lang parts to the
> installed
> packages.
>

First: situation when someone may need to change set of lang dependent
resources is extremely rare.
In other words: Jakub you see the problem where in practice there is no
problem.
Second: just checked part of my own procedures adjusting set of installed
land dependent resources:

echo "reinstall packages with only necessary locale"
echo "%_install_langs en,pl" > /etc/rpm/macros
rpm --rebuilddb; dnf clean all; df -k /; rpm -qal|grep LC_MESSAGES|xargs
rpm -qf 2>&1|sort|uniq|xargs dnf -yq reinstall; rpm --rebuilddb; dnf clean
all; df -k /

Probably this can be improved by other rpm db query extracting list of
files with lang tags but for me it is GoodEnugh(tm).

Third: reduction of installed lang dependent resources can be done by rpm
db query -> extract list of files which needs to be removed -> correct list
of installed files -> remove unwanted files. Add such function to existing
to existing rpm/dnf (you must probably agree) will be trivial. Isn't it?
Extending set of installed languages support in case of rpm is only
possible to do by full download of affected packages and reinstall them or
in simplified scenario extract files which needs to be added to installed
system image.
In other words .. even this is relatively easy.

And yes .. at the moment only Solaris IPS provides handling above scenarios
in simplest possible way because in IPS semantic package exist only as
object in remotely accessible repository which each object like file or
metadata can be downloaded separately. This solves as well many other rpm
issues like existence of rpm noarch package, lack of sharing common files
between arch dependent packages and sharing not changing files between
packages versions/releases on packages repository side.

koczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
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

Re: Organizing a "packager experience" objective and working group

[Michael Cronenworth]

On 1/11/19 9:18 AM, Matthew Miller wrote:

Can we apply the same "flag and remove" approach as currently used in Copr?


I'd rather have a licensing sign-off step. Allow fedora-review to automate the spec 
review and build test, but break out the licensing check. Maybe in the future we can 
automate that, too, but breaking out the mountain that is package review into a 
small rock would still accelerate reviews.

___
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

Re: Why no wdune sponsoring ?

[Sérgio Basto]

On Fri, 2019-01-11 at 18:16 +0100, J. Scheurich wrote:
> Hi,
> > > Are there any tips how to get wdune fedora sponsoring ?
> > 
> > What to do ?
> > Propose a review swap , you review a package for other and other
> > review
> > your package and sponsor / mentor you .
> 
> How to initialise a review swap ?


LMGTFY (fedora review swap ) 


https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/5OPPTTNKQF2S5PUOX4HNAW5B7R4UFREU/

https://fedoraproject.org/wiki/Package_Review_Process

> Is there a mailing list or something to initialise review swaps ?
> 
> Are there any lists with potential review swap ?
> Most people which need a review also need sponsoring by themselves,
> or 
> am i wrong ?
> 
> so long
> MUFTI
> ___
> 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
-- 
Sérgio M. B.
___
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

Re: Why no wdune sponsoring ?

[J. Scheurich]

Hi,

Are there any tips how to get wdune fedora sponsoring ?

What to do ?
Propose a review swap , you review a package for other and other review
your package and sponsor / mentor you .


How to initialise a review swap ?
Is there a mailing list or something to initialise review swaps ?

Are there any lists with potential review swap ?
Most people which need a review also need sponsoring by themselves, or 
am i wrong ?


so long
MUFTI
___
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

Re: Why no wdune sponsoring ?

[Sérgio Basto]

On Fri, 2019-01-11 at 18:00 +0100, J. Scheurich wrote:
> Hi,
> 
> Are there any tips how to get wdune fedora sponsoring ?

Is not wdune that need be sponsored is you that need be sponsored, you
by being sponsored get permissions to write and include wdune in Fedora
. 

I can't sponsor you because I don't have the ACL for sponsoring . 

> We are working years on free software, but the distributors simply 
> ignore it
> (or worse) use a more than 10 years old version (like in
> debian/ubuntu) 8-(
> 
> What is wrong with wdune ?
> 
> It uses old technologies like motif or X3D.
> Motif has the advantage that the 2D-GUI did not change over the years
> (a lot of interesting software under Linux died from changing
> versions of
> QT or gtk for example).
> X3D has been superseded by webgl, but X3D can be displayed via webgl
> (X_ITE or x3dom).
> 
> What need to be done, to bring wdune to fedora ?
> If i get no fedora sponsoring, are there some volunteers to add wdune
> to 
> fedora ?
> 
> It looks like, is not much work, it looks like wdune passed the
> review 
> process:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1658153
> 
> What to do ?

Propose a review swap , you review a package for other and other review
your package and sponsor / mentor you . 



> so long
> MUFTI
> ___
> 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
-- 
Sérgio M. B.
___
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

Why no wdune sponsoring ?

[J. Scheurich]

Hi,

Are there any tips how to get wdune fedora sponsoring ?

We are working years on free software, but the distributors simply 
ignore it

(or worse) use a more than 10 years old version (like in debian/ubuntu) 8-(

What is wrong with wdune ?

It uses old technologies like motif or X3D.
Motif has the advantage that the 2D-GUI did not change over the years
(a lot of interesting software under Linux died from changing versions of
QT or gtk for example).
X3D has been superseded by webgl, but X3D can be displayed via webgl
(X_ITE or x3dom).

What need to be done, to bring wdune to fedora ?
If i get no fedora sponsoring, are there some volunteers to add wdune to 
fedora ?


It looks like, is not much work, it looks like wdune passed the review 
process:


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

What to do ?

so long
MUFTI
___
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

Re: Organizing a "packager experience" objective and working group

[Stephen John Smoogen]

On Fri, 11 Jan 2019 at 11:24, Stephen John Smoogen  wrote:

>
>
> On Fri, 11 Jan 2019 at 10:19, Matthew Miller 
> wrote:
>
>> On Thu, Jan 10, 2019 at 02:42:05PM -0800, Kevin Fenzi wrote:
>> > * non free submissions. What if someone submits non free content and we
>> > build and host it? That would not be great.
>>
>> Can we apply the same "flag and remove" approach as currently used in
>> Copr?
>>
>>
> It can be done but it takes both database changes and rewriting histories
> in certain places. The purpose of the Fedora Build System (FBS*) is to
> compose a distribution in an auditable fashion so that one could see the
> chain of builds, the source code, and other items and link them in a
> fashion to know when someone messes with it. Messing with databases,
> rewriting history, has pile on and unintended effects because it is not
> what FBS was aimed to do.. and various side effects then have to be tracked
> down and done.
>
> One of the problems we are running into is that koji is a hammer and we
> keep using it to do everything from putting in screws to painting the car.
> Sure we can add some layers (bodhi+mbs+pungi+..) and make the hammer more
> screwdriver like or more brush like.. but in the end.. it is going to leave
> dent marks in the wall and car.
>
> The issue here is that a good portion of what we are looking at isn't a
> distribution. It may become a distribution later, but we are mainly talking
> about someone wanting packageA to be usable in some way. [It doesn't mean
> there is any work to make it integrated with anything else.. just that it
> is usable.]
>
> If you want a build system which has different requirements, make or clone
> a different build system for those requirements.
>
>
>
Let me rewrite that last sentence to make it less crappy ( and my apologies
for sending off the crappy version first):

If we want a build system which has different requirements, let us make or
clone a build system for those requirements.

-- 
Stephen J Smoogen.
___
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

Re: Organizing a "packager experience" objective and working group

[Stephen John Smoogen]

On Fri, 11 Jan 2019 at 10:19, Matthew Miller 
wrote:

> On Thu, Jan 10, 2019 at 02:42:05PM -0800, Kevin Fenzi wrote:
> > * non free submissions. What if someone submits non free content and we
> > build and host it? That would not be great.
>
> Can we apply the same "flag and remove" approach as currently used in Copr?
>
>
It can be done but it takes both database changes and rewriting histories
in certain places. The purpose of the Fedora Build System (FBS*) is to
compose a distribution in an auditable fashion so that one could see the
chain of builds, the source code, and other items and link them in a
fashion to know when someone messes with it. Messing with databases,
rewriting history, has pile on and unintended effects because it is not
what FBS was aimed to do.. and various side effects then have to be tracked
down and done.

One of the problems we are running into is that koji is a hammer and we
keep using it to do everything from putting in screws to painting the car.
Sure we can add some layers (bodhi+mbs+pungi+..) and make the hammer more
screwdriver like or more brush like.. but in the end.. it is going to leave
dent marks in the wall and car.

The issue here is that a good portion of what we are looking at isn't a
distribution. It may become a distribution later, but we are mainly talking
about someone wanting packageA to be usable in some way. [It doesn't mean
there is any work to make it integrated with anything else.. just that it
is usable.]

If you want a build system which has different requirements, make or clone
a different build system for those requirements.

* FBS == koji + bodhi + mbs + pungi + osbs + etc etc etc.



> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> 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
>


-- 
Stephen J Smoogen.
___
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

Re: Organizing a "packager experience" objective and working group

[Neal Gompa]

On Fri, Jan 11, 2019 at 10:19 AM Matthew Miller
 wrote:
>
> On Thu, Jan 10, 2019 at 02:42:05PM -0800, Kevin Fenzi wrote:
> > * non free submissions. What if someone submits non free content and we
> > build and host it? That would not be great.
>
> Can we apply the same "flag and remove" approach as currently used in Copr?
>

My understanding is that it's a lot harder to completely remove stuff
from Koji, Dist-Git, etc. than it is from Copr.

And there's the whole "Red Hat really doesn't want it in there to
begin with" thing...


--
真実はいつも一つ！/ 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://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

Re: Proposal: Add a separate “flatpaks/” namespace.

[Owen Taylor]

On Tue, Jan 8, 2019 at 12:28 PM Owen Taylor  wrote:
>  * In fedscm_admin: Map flatpaks namespace to the ‘module’ PDC branch
> type when storing the SLA into the PDC, to avoid PDC changes, and
> because the SLA really is a module SLA.

Digging into this, I don't think this is right - it would break the
1:1 mapping between pagure branches and "component branches" in PDC
that we currently have and the scripts count on. I think the right
thing is:

 * Modify the ReleaseComponentType table in the PDC database to add 'flatpak'

[ Or could be done by adding a migration to the PDC codebase, adding
the redeploying, but considering that we're working on replacing the
PDC, doesn't seem worthwhile.]

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

Re: F30 System-Wide Change Proposal: Fully remove deprecated and unsafe functions from libcrypt

[Björn 'besser82' Esser]

Am Freitag, den 11.01.2019, 15:13 +0100 schrieb Björn 'besser82' Esser:
> Am Donnerstag, den 10.01.2019, 23:34 +0100 schrieb Miro Hrončok:
> > On 02. 01. 19 22:14, Ben Cotton wrote:
> > > https://fedoraproject.org/wiki/Changes/FullyRemoveDeprecatedAndUnsafeFunctionsFromLibcrypt
> > > 
> > > == Summary ==
> > > This change is about removing binary support for deprecated and
> > > unsafe
> > > functions and bumping libcrypt.so to libcrypt.so.2.
> > > 
> > > == Owner ==
> > > * Name: [[User:besser82 | Björn Esser]] <
> > > besse...@fedoraproject.org>
> > > 
> > > == Detailed Description ==
> > > In Fedora 28 we replaced glibc's libcrypt with the fully binary
> > > compatible libcrypt library from the external libxcrypt project.
> > > There are certain interfaces (encrypt, encrypt_r, setkey,
> > > setkey_r)
> > > that are mandatory by POSIX or various other standards.
> > > ...
> > 
> > Any chance you would have this ready in some copr?
> > I'd like to test if Python builds and passes the tests, the
> > replacement in F28 
> > wasn't without problems IIRC.
> > 
> 
> A COPR with builds of bumped libxcrypt so-name and all recently
> supported versions of Python is here [1].
> 
> The problems in F28 were about `crypt(3)` not being prototyped in
> `unistd.h` anymore.  This change doesn't touch any includes or similar
> stuff, so I do not expect any fallout.
> 
> 
> [1]  https://copr.fedorainfracloud.org/coprs/besser82/xcrypt_soname/


FYI, the build failures in the COPR are *NOT* releated to libxcrypt nor
Python's crypt module.


signature.asc
Description: This is a digitally signed message part
___
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

Re: Organizing a "packager experience" objective and working group

[Matthew Miller]

On Thu, Jan 10, 2019 at 02:42:05PM -0800, Kevin Fenzi wrote:
> * non free submissions. What if someone submits non free content and we
> build and host it? That would not be great.

Can we apply the same "flag and remove" approach as currently used in Copr?


-- 
Matthew Miller

Fedora Project Leader
___
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

Re: Ownership of python-tenacity

[Christopher Brown]

On Fri, 11 Jan 2019, 12:05 pm Randy Barlow  On Thu, 2019-01-10 at 14:14 +, Christopher Brown wrote:
> > I did ask for commit access here:
> >
> > https://pagure.io/fesco/issue/2045
> >
> > but it was just orphaned. Not sure why. I've read the meeting logs.
> > It just seems like all the packages were orphaned.
>
> You said you weren't interested in ownership in this comment:
>
> https://pagure.io/fesco/issue/2045#comment-547988
>
> That is why we decided to orphan it rather than transfer ownership to
> you.
>

It doesn't make logical sense to orphan something that I'm actively trying
to update though, does it?

I think there was some confusion and discussion over how to proceed and
things are unblocked now so thanks for acting on it so quickly.

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

Re: F30 System-Wide Change Proposal: Fully remove deprecated and unsafe functions from libcrypt

[Björn 'besser82' Esser]

Am Donnerstag, den 10.01.2019, 23:34 +0100 schrieb Miro Hrončok:
> On 02. 01. 19 22:14, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/FullyRemoveDeprecatedAndUnsafeFunctionsFromLibcrypt
> > 
> > == Summary ==
> > This change is about removing binary support for deprecated and
> > unsafe
> > functions and bumping libcrypt.so to libcrypt.so.2.
> > 
> > == Owner ==
> > * Name: [[User:besser82 | Björn Esser]] 
> > 
> > == Detailed Description ==
> > In Fedora 28 we replaced glibc's libcrypt with the fully binary
> > compatible libcrypt library from the external libxcrypt project.
> > There are certain interfaces (encrypt, encrypt_r, setkey, setkey_r)
> > that are mandatory by POSIX or various other standards.
> > ...
> 
> Any chance you would have this ready in some copr?
> I'd like to test if Python builds and passes the tests, the
> replacement in F28 
> wasn't without problems IIRC.
> 

A COPR with builds of bumped libxcrypt so-name and all recently
supported versions of Python is here [1].

The problems in F28 were about `crypt(3)` not being prototyped in
`unistd.h` anymore.  This change doesn't touch any includes or similar
stuff, so I do not expect any fallout.


[1]  https://copr.fedorainfracloud.org/coprs/besser82/xcrypt_soname/


signature.asc
Description: This is a digitally signed message part
___
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

Re: Organizing a "packager experience" objective and working group

[Neal Gompa]

On Thu, Jan 10, 2019 at 1:59 PM Ben Rosser  wrote:
>
> Hello,
>
> We had a recent discussion on this list last month about (among other
> things) the current state of Pagure as a replacement for pkgdb [1].
>
> I mentioned in that discussion that there are various issues which
> have arisen from the deprecation of pkgdb that have made the packager
> workflow ever so slightly worse. But it's not just pkgdb-- there are
> lots of places where the packager workflow could use improvement.
> There are parts of the process that are tedious and manual which could
> be replaced with (partial) automation, or parts where automation
> exists but is in need of improvement.
>
> For example, there are tools (namely, the "fedora-review" script) to
> automate parts of the package review process. But fedora-review has
> been lagging behind the packaging guidelines for some time, and has to
> be manually ran by packagers over review requests. But, there's no
> reason we couldn't run fedora-review automatically over every package
> submission-- which might save both reviewers and submitters a lot of
> time.
>
> Or, as another example, there's currently a lot of work going on in
> the distribution to support new packaging formats-- like containers
> and modules. New workflows for making containers or modules out of
> existing packages are being created, and I think it's vital we make
> sure these workflows and processes are designed in such a way to make
> things as easy as possible for packagers.
>
> Anyway, as part of that discussion, I was encouraged to propose a new
> Fedora Community Objective focused on improving the packaging
> experience and workflow in Fedora. Community Objectives are approved
> by the Fedora Council and intended to be 12-18 month goals for the
> entire project. The goal of this Objective would be to identify
> problems with the current packager workflow(s), put together a group
> of packagers interested in fixing things, and then fix them!
>
> If this sounds like something you'd be interested in helping out with,
> great! The Objective will need two things, if it's to succeed:
>
> 1. People who are interested in helping! Some people did express
> interest in the other thread, but I thought I would put out a general
> call for interested packagers and volunteers. Anyone who is interested
> and thinks they'll have some available time is more than welcome.
>

Of course, I'm definitely interested!

> 2. A concrete list of goals to accomplish. What glitches are there in
> the current workflow, and how can they be fixed? What do you wish was
> simpler, or better, or easier to do? What, basically, would make your
> life easier a packager?
>

I think when topics like this come up, I think I've complained more or
less about the same things. I hope we'll be empowered to actually make
such improvements...

> I've written an initial draft proposal [2] on the wiki here, though
> the list of tasks to focus on is pretty sparse at present. If you are
> interested in helping out, please feel free to add your own thoughts
> as well.
>

I'll take a look when I've got a few moments and see if I can add
something useful there..



-- 
真実はいつも一つ！/ 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://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

Re: Organizing a "packager experience" objective and working group

[Pierre-Yves Chibon]

On Thu, Jan 10, 2019 at 01:58:17PM -0500, Ben Rosser wrote:
> Hello,
> 
> We had a recent discussion on this list last month about (among other
> things) the current state of Pagure as a replacement for pkgdb [1].
> 
> I mentioned in that discussion that there are various issues which
> have arisen from the deprecation of pkgdb that have made the packager
> workflow ever so slightly worse. But it's not just pkgdb-- there are
> lots of places where the packager workflow could use improvement.
> There are parts of the process that are tedious and manual which could
> be replaced with (partial) automation, or parts where automation
> exists but is in need of improvement.
> 
> For example, there are tools (namely, the "fedora-review" script) to
> automate parts of the package review process. But fedora-review has
> been lagging behind the packaging guidelines for some time, and has to
> be manually ran by packagers over review requests. But, there's no
> reason we couldn't run fedora-review automatically over every package
> submission-- which might save both reviewers and submitters a lot of
> time.
> 
> Or, as another example, there's currently a lot of work going on in
> the distribution to support new packaging formats-- like containers
> and modules. New workflows for making containers or modules out of
> existing packages are being created, and I think it's vital we make
> sure these workflows and processes are designed in such a way to make
> things as easy as possible for packagers.
> 
> Anyway, as part of that discussion, I was encouraged to propose a new
> Fedora Community Objective focused on improving the packaging
> experience and workflow in Fedora. Community Objectives are approved
> by the Fedora Council and intended to be 12-18 month goals for the
> entire project. The goal of this Objective would be to identify
> problems with the current packager workflow(s), put together a group
> of packagers interested in fixing things, and then fix them!
> 
> If this sounds like something you'd be interested in helping out with,
> great! The Objective will need two things, if it's to succeed:
> 
> 1. People who are interested in helping! Some people did express
> interest in the other thread, but I thought I would put out a general
> call for interested packagers and volunteers. Anyone who is interested
> and thinks they'll have some available time is more than welcome.

I'm in :)


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

Re: Organizing a "packager experience" objective and working group

[Björn Persson]

Neal Gompa  wrote:
> GOA has the ability to store kerberos logins and initialize them as
> part of your login session, too.

Every time I log in locally on my workstation? That's not good. I
suppose that's suitable in a centralized corporate or university
network, but as an infrequent Fedora contributor I'll of course log in
only when I actually access Fedora systems.

But that doesn't matter to me as long as it's tied to Gnome 3.

Björn Persson


pgpMR_wlYQRiH.pgp
Description: OpenPGP digital signatur
___
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

Re: Organizing a "packager experience" objective and working group

[Neal Gompa]

On Fri, Jan 11, 2019 at 7:52 AM Björn Persson  wrote:
>
> Vít Ondruch  wrote:
> > Dne 10. 01. 19 v 20:47 Artur Iwicki napsal(a):
> > > - Now that I've mentioned it, maybe we should add something like "fedpkg 
> > > fas-login"? Personally I've put "alias koji-init='kinit 
> > > my-fas-acco...@my-domain.org'" in my .bashrc, because looking up how to 
> > > solve the "koji says I'm unauthenticated" error got boring after the 
> > > third time.
> >
> > If you used Gnome Online Accounts, you would not need commands/scripts
> > like this.
>
> I've seen that mentioned a few times. What exactly is this "Gnome
> Online Accounts", and is there a reasonable way I can use it without
> having to endure the rest of Gnome 3?
>

GOA is an aspect of the GNOME Desktop that supports linking online
accounts to your user. When you log into Google, ownCloud or
Nextcloud, and so on during initial setup, those are stored in GOA.

GOA has the ability to store kerberos logins and initialize them as
part of your login session, too.

You cannot leverage GOA without the GNOME Desktop. KDE has its own
system, but I am unsure if it has Kerberos support like GOA does.

Pantheon Desktop has its own thing too, but that doesn't support Kerberos.

> I want my FAS passkey stored in a keyring, encrypted with a master
> passphrase, and I don't want to have to authenticate in advance with a
> separate command. When I do for example "fedpkg build", I want to be
> prompted for the master passphrase to unlock the keyring, unless the
> keyring is already open. Then the FAS passkey shall be fetched from
> the keyring and used in the Kerberos authentication, while the master
> passphrase never leaves my workstation. But I don't want this at the
> cost of having my productivity hampered by Gnome 3.
>
> I have poked around trying to find some "Online Accounts" program or
> package, but I didn't find anything I could run from another desktop.
>

Sorry, you have to take the good with the bad in this case, sadly. I
live with the constant kinit runs because GNOME is too much for me to
bear. I consider it an acceptable trade-off really. The only reason
GOA has Kerberos support is because of all the enterprise desktop
stuff.


-- 
真実はいつも一つ！/ 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://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

Re: Organizing a "packager experience" objective and working group

[Igor Gnatenko]

I'm definitely interested to help (I have 6+ years experience as a
packager)!

Can we have a topic on discussion.fp.o? I think it is much easier to
discuss such things there.

On Thu, Jan 10, 2019, 20:07 Ben Rosser  Hello,
>
> We had a recent discussion on this list last month about (among other
> things) the current state of Pagure as a replacement for pkgdb [1].
>
> I mentioned in that discussion that there are various issues which
> have arisen from the deprecation of pkgdb that have made the packager
> workflow ever so slightly worse. But it's not just pkgdb-- there are
> lots of places where the packager workflow could use improvement.
> There are parts of the process that are tedious and manual which could
> be replaced with (partial) automation, or parts where automation
> exists but is in need of improvement.
>
> For example, there are tools (namely, the "fedora-review" script) to
> automate parts of the package review process. But fedora-review has
> been lagging behind the packaging guidelines for some time, and has to
> be manually ran by packagers over review requests. But, there's no
> reason we couldn't run fedora-review automatically over every package
> submission-- which might save both reviewers and submitters a lot of
> time.
>
> Or, as another example, there's currently a lot of work going on in
> the distribution to support new packaging formats-- like containers
> and modules. New workflows for making containers or modules out of
> existing packages are being created, and I think it's vital we make
> sure these workflows and processes are designed in such a way to make
> things as easy as possible for packagers.
>
> Anyway, as part of that discussion, I was encouraged to propose a new
> Fedora Community Objective focused on improving the packaging
> experience and workflow in Fedora. Community Objectives are approved
> by the Fedora Council and intended to be 12-18 month goals for the
> entire project. The goal of this Objective would be to identify
> problems with the current packager workflow(s), put together a group
> of packagers interested in fixing things, and then fix them!
>
> If this sounds like something you'd be interested in helping out with,
> great! The Objective will need two things, if it's to succeed:
>
> 1. People who are interested in helping! Some people did express
> interest in the other thread, but I thought I would put out a general
> call for interested packagers and volunteers. Anyone who is interested
> and thinks they'll have some available time is more than welcome.
>
> 2. A concrete list of goals to accomplish. What glitches are there in
> the current workflow, and how can they be fixed? What do you wish was
> simpler, or better, or easier to do? What, basically, would make your
> life easier a packager?
>
> I've written an initial draft proposal [2] on the wiki here, though
> the list of tasks to focus on is pretty sparse at present. If you are
> interested in helping out, please feel free to add your own thoughts
> as well.
>
> Sincerely,
> Ben Rosser
>
> [1]
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/FYNU7W6KQQWA65JWVPUFDHKUP3RX6EKR/
> [2] https://fedoraproject.org/wiki/Objectives/Packager_Experience
> ___
> 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
>
___
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

Re: Organizing a "packager experience" objective and working group

[Björn Persson]

Vít Ondruch  wrote:
> Dne 10. 01. 19 v 20:47 Artur Iwicki napsal(a):
> > - Now that I've mentioned it, maybe we should add something like "fedpkg 
> > fas-login"? Personally I've put "alias koji-init='kinit 
> > my-fas-acco...@my-domain.org'" in my .bashrc, because looking up how to 
> > solve the "koji says I'm unauthenticated" error got boring after the third 
> > time.  
> 
> If you used Gnome Online Accounts, you would not need commands/scripts
> like this.

I've seen that mentioned a few times. What exactly is this "Gnome
Online Accounts", and is there a reasonable way I can use it without
having to endure the rest of Gnome 3?

I want my FAS passkey stored in a keyring, encrypted with a master
passphrase, and I don't want to have to authenticate in advance with a
separate command. When I do for example "fedpkg build", I want to be
prompted for the master passphrase to unlock the keyring, unless the
keyring is already open. Then the FAS passkey shall be fetched from
the keyring and used in the Kerberos authentication, while the master
passphrase never leaves my workstation. But I don't want this at the
cost of having my productivity hampered by Gnome 3.

I have poked around trying to find some "Online Accounts" program or
package, but I didn't find anything I could run from another desktop.

Björn Persson


pgpotUlyRQwlJ.pgp
Description: OpenPGP digital signatur
___
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

Re: langpacks (Re: F30 System-Wide Change proposal: Replace Comps Language Group With Langpacks)

[Jakub Jelinek]

On Fri, Jan 11, 2019 at 01:11:00PM +0100, Tomasz Kłoczko wrote:
> On Fri, 11 Jan 2019 at 05:27, Jens-Ulrik Petersen 
> wrote:
> [..]
> 
> > %find_lang used --with-man option takes care of collecting all language
> >> specific man pages as well, and more than 100 Fedora package are using this
> >> option .. but again nothing during fresh Fedora install is using those 
> >> tags.
> >>
> >
> > Are there any associated bugs/RFEs filed for these points?
> >
> 
> Feel free to open bug/RFE.
> I have no patience to deal with Fedora bureaucracy :P
> 
> I can give you one more vectors to search to make use %find_lang more
> effectively.
> 
> [tkloczko@domek SPECS.fedora]$ grep ^\%lang\( * -l | wc -l
> 107
> 
> So in 107 current Fedora specs are used %lang() macros.
> Probably some of them can be removed by proper use %find_lang.

The problem with _install_langs is that there is no easy way to change it
after installation, say you find out you've initially installed just English
and French support, but later you need German and Italian.  rpm nor dnf
doesn't offer any easy way to add those missing %lang parts to the installed
packages.

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

Re: Is Bodhi's fedmsg integration in the UI useful?

[Neal Gompa]

On Fri, Jan 11, 2019 at 7:23 AM Randy Barlow
 wrote:
>
> On Thu, 2019-01-10 at 08:34 -0800, Adam Williamson wrote:
> > Was
> > there some kind of design rationale for them? Or were they just added
> > because 'hey, fedmsg is cool'?
>
> I don't know because they were added before my tenure, though I suspect
> it was the latter.

At least for me, it's the only way I know when my update submission
succeeds, because UI responsiveness is *really bad*. But beyond that,
it doesn't have much use to me.


-- 
真実はいつも一つ！/ 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://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

Re: Is Bodhi's fedmsg integration in the UI useful?

[Randy Barlow]

On Thu, 2019-01-10 at 08:34 -0800, Adam Williamson wrote:
> Was
> there some kind of design rationale for them? Or were they just added
> because 'hey, fedmsg is cool'?

I don't know because they were added before my tenure, though I suspect
it was the latter.


signature.asc
Description: This is a digitally signed message part
___
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

Re: langpacks (Re: F30 System-Wide Change proposal: Replace Comps Language Group With Langpacks)

[Tomasz Kłoczko]

On Fri, 11 Jan 2019 at 05:27, Jens-Ulrik Petersen 
wrote:
[..]

> %find_lang used --with-man option takes care of collecting all language
>> specific man pages as well, and more than 100 Fedora package are using this
>> option .. but again nothing during fresh Fedora install is using those tags.
>>
>
> Are there any associated bugs/RFEs filed for these points?
>

Feel free to open bug/RFE.
I have no patience to deal with Fedora bureaucracy :P

I can give you one more vectors to search to make use %find_lang more
effectively.

[tkloczko@domek SPECS.fedora]$ grep ^\%lang\( * -l | wc -l
107

So in 107 current Fedora specs are used %lang() macros.
Probably some of them can be removed by proper use %find_lang.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
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

Re: Ownership of python-tenacity

[Randy Barlow]

On Thu, 2019-01-10 at 14:14 +, Christopher Brown wrote:
> I did ask for commit access here:
> 
> https://pagure.io/fesco/issue/2045
> 
> but it was just orphaned. Not sure why. I've read the meeting logs.
> It just seems like all the packages were orphaned.

You said you weren't interested in ownership in this comment:

https://pagure.io/fesco/issue/2045#comment-547988

That is why we decided to orphan it rather than transfer ownership to
you.


signature.asc
Description: This is a digitally signed message part
___
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

Re: langpacks (Re: F30 System-Wide Change proposal: Replace Comps Language Group With Langpacks)

[Tomasz Kłoczko]

On Fri, 11 Jan 2019 at 05:17, Jens-Ulrik Petersen 
wrote:

> On Fri, Jan 11, 2019 at 2:41 AM Tomasz Kłoczko 
> wrote:
>
>> On Wed, 9 Jan 2019 at 21:07, Ben Cotton  wrote:
>>
>>>
>>> https://fedoraproject.org/wiki/Changes/Replace_Comps_Language_Group_With_Langpacks
>>> Language support groups in Comps file will get replaced by langpacks
>>> package. With this Change we want meta-packages like langpacks-ja to
>>> also install required fonts and input-methods for the given language.
>>>
>>
>> It is really shame that instead just setting up
>> /etc/rpm/macros::%_install_langs on distro install time people are
>> discussing how to waste time to create even more langpacks.
>> The same is with separating doc subpackages which can be done by
>> /etc/rpm/macros::%_excludedocs yes or use --excludedocs on single package
>> install/upgrade.
>>
>
> This Change is not about adding new langpacks packages to Fedora or even
> about translation langpacks.
> We are just cleaning up the old language support groups in Fedora comps
> and moving their manifest package to weak deps in the existing langpacks
> meta packages.
>

Issue is that now adding those weak dependencies is consequences of
introducing lagpacks.
This classic taming growing entropy of some side effects by allowing to
increase general entropy in prev steps.

Tomasz
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
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

Re: Organizing a "packager experience" objective and working group

[Fabio Valentini]

On Fri, Jan 11, 2019 at 11:29 AM Artur Iwicki  wrote:
>
> Just checked myself, I don't have the file either, and I use a separate local 
> account for RPM packaging (that uses a different name than my FAS login). No 
> idea what that's about, I can't recall any tool ever complaining about the 
> file missing.

For example, ~/.fedora.upn is used by fedpkg as the "authoritative"
source of the FAS username.
But, if that file isn't present, it just silently falls back to
checking kerberos for the username, and if that doesn't work, it uses
$USER.

(See: the Command.*user* methods in __init__.py of both rpkg and fedpkg)

Fabio

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

Re: Organizing a "packager experience" objective and working group

[Artur Iwicki]

Just checked myself, I don't have the file either, and I use a separate local 
account for RPM packaging (that uses a different name than my FAS login). No 
idea what that's about, I can't recall any tool ever complaining about the file 
missing.
___
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

Re: Organizing a "packager experience" objective and working group

[Vít Ondruch]

Goog small update, thx. I moved the hint into the "Kerberos" admon and
now it is almost perfect IMO ;)


Just noticed the note about ~/.fedora.upn file, what is it about? I
don't have such file on my system, therefore I assume I don't need it,
because my FAS name is the same as my system user name. Is that correct
assumption? Or on different page I see "This is not actually needed for
Kerberos but for other tools", so what are the other tools?

Vít


Dne 11. 01. 19 v 10:42 Christopher Brown napsal(a):
> That's good to know!
>
> I have updated
> https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
> to reflect this.
>
> Thanks Vit.
>
> On Fri, Jan 11, 2019 at 9:09 AM Vít Ondruch  > wrote:
>
>
> Dne 10. 01. 19 v 20:47 Artur Iwicki napsal(a):
> > - Now that I've mentioned it, maybe we should add something like
> "fedpkg fas-login"? Personally I've put "alias koji-init='kinit
> my-fas-acco...@my-domain.org
> '" in my .bashrc, because
> looking up how to solve the "koji says I'm unauthenticated" error
> got boring after the third time.
>
>
> If you used Gnome Online Accounts, you would not need commands/scripts
> like this.
>
>
> Vít
> ___
> 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
>
>
>
> -- 
> Christopher Brown
> Senior Consultant
> Red Hat UK Ltd 
> chris.br...@redhat.com 
>
>
> ___
> 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
___
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

Re: Unannounced soname bump: libcapstone.so.3 -> libcapstone.so.4

[Björn 'besser82' Esser]

Am Freitag, den 11.01.2019, 09:43 + schrieb Daniel P. Berrangé:
> On Fri, Jan 11, 2019 at 09:40:59AM +, Richard W.M. Jones wrote:
> > On Fri, Jan 11, 2019 at 09:30:29AM +, Daniel P. Berrangé wrote:
> > > On Fri, Jan 11, 2019 at 09:24:12AM +, Richard W.M. Jones
> > > wrote:
> > > > On Fri, Jan 11, 2019 at 09:14:29AM +, Richard W.M. Jones
> > > > wrote:
> > > > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1178711
> > > > > 
> > > > > This broke qemu, and indirectly libvirt.
> > > > > 
> > > > > I will submit a new build for qemu to see if that fixes
> > > > > things.  I
> > > > > didn't look closely to see if there are API changes.
> > > > 
> > > > The rebuild failed - it looks like there are some changes to
> > > > capstone,
> > > > at least the location of the  headers file, which
> > > > break
> > > > qemu source.  I'll see if there's anything we can backport from
> > > > upstream.
> > > 
> > > The headers haven't moved. It looks like the  capstone pkgconfig
> > > file is
> > > broken.
> > > 
> > > In 3.0.5 it had
> > > 
> > >   includedir=/usr/include/capstone
> > > 
> > > In 4.0.1 is has
> > > 
> > >   includedir=/usr/include
> > 
> > While I don't disagree that this file looks broken, it does seem as
> > if
> > capstone wants you to use .  See the tests, for
> > example:
> > 
> > https://github.com/aquynh/capstone/blob/master/tests/test_basic.c
> > 
> > The below patch fixes qemu when using the system capstone, but
> > probably breaks when using the git-submodule capstone.  However I'll
> > drop this in as a *temporary* workaround to get Fedora building.
> 
> We should really just fix the pkg-config file in capstone locally.
> 
> I've filed a bug in upstream capstone, as they really do intend
> includedir=/usr/include/capstone to be used.
> 
>   https://github.com/aquynh/capstone/issues/1339
> 
> 
> Regards,
> Daniel

Index: capstone-4.0.1/Makefile
===
--- capstone-4.0.1.orig/Makefile
+++ capstone-4.0.1/Makefile
@@ -517,5 +517,5 @@ define generate-pkgcfg
echo 'includedir=$(INCDIR)' >> $(PKGCFGF)
echo 'archive=$${libdir}/libcapstone.a' >> $(PKGCFGF)
echo 'Libs: -L$${libdir} -lcapstone' >> $(PKGCFGF)
-   echo 'Cflags: -I$${includedir}' >> $(PKGCFGF)
+   echo 'Cflags: -I$${includedir}/$(LIBNAME)' >> $(PKGCFGF)
 endef

--

This patch should fix the pkgconfig file generated by Makefile.

Björn


signature.asc
Description: This is a digitally signed message part
___
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

Re: Unannounced soname bump: libcapstone.so.3 -> libcapstone.so.4

[Daniel P . Berrangé]

On Fri, Jan 11, 2019 at 09:40:59AM +, Richard W.M. Jones wrote:
> On Fri, Jan 11, 2019 at 09:30:29AM +, Daniel P. Berrangé wrote:
> > On Fri, Jan 11, 2019 at 09:24:12AM +, Richard W.M. Jones wrote:
> > > On Fri, Jan 11, 2019 at 09:14:29AM +, Richard W.M. Jones wrote:
> > > > 
> > > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1178711
> > > > 
> > > > This broke qemu, and indirectly libvirt.
> > > > 
> > > > I will submit a new build for qemu to see if that fixes things.  I
> > > > didn't look closely to see if there are API changes.
> > > 
> > > The rebuild failed - it looks like there are some changes to capstone,
> > > at least the location of the  headers file, which break
> > > qemu source.  I'll see if there's anything we can backport from
> > > upstream.
> > 
> > The headers haven't moved. It looks like the  capstone pkgconfig file is
> > broken.
> > 
> > In 3.0.5 it had
> > 
> >   includedir=/usr/include/capstone
> > 
> > In 4.0.1 is has
> > 
> >   includedir=/usr/include
> 
> While I don't disagree that this file looks broken, it does seem as if
> capstone wants you to use .  See the tests, for
> example:
> 
> https://github.com/aquynh/capstone/blob/master/tests/test_basic.c
> 
> The below patch fixes qemu when using the system capstone, but
> probably breaks when using the git-submodule capstone.  However I'll
> drop this in as a *temporary* workaround to get Fedora building.

We should really just fix the pkg-config file in capstone locally.

I've filed a bug in upstream capstone, as they really do intend
includedir=/usr/include/capstone to be used.

  https://github.com/aquynh/capstone/issues/1339


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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

Re: Organizing a "packager experience" objective and working group

[Christopher Brown]

That's good to know!

I have updated
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers to
reflect this.

Thanks Vit.

On Fri, Jan 11, 2019 at 9:09 AM Vít Ondruch  wrote:

>
> Dne 10. 01. 19 v 20:47 Artur Iwicki napsal(a):
> > - Now that I've mentioned it, maybe we should add something like "fedpkg
> fas-login"? Personally I've put "alias koji-init='kinit
> my-fas-acco...@my-domain.org'" in my .bashrc, because looking up how to
> solve the "koji says I'm unauthenticated" error got boring after the third
> time.
>
>
> If you used Gnome Online Accounts, you would not need commands/scripts
> like this.
>
>
> Vít
> ___
> 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
>


-- 
Christopher Brown
Senior Consultant
Red Hat UK Ltd 
chris.br...@redhat.com <+44%207770%2075>
___
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

Re: Unannounced soname bump: libcapstone.so.3 -> libcapstone.so.4

[Richard W.M. Jones]

On Fri, Jan 11, 2019 at 09:30:29AM +, Daniel P. Berrangé wrote:
> On Fri, Jan 11, 2019 at 09:24:12AM +, Richard W.M. Jones wrote:
> > On Fri, Jan 11, 2019 at 09:14:29AM +, Richard W.M. Jones wrote:
> > > 
> > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1178711
> > > 
> > > This broke qemu, and indirectly libvirt.
> > > 
> > > I will submit a new build for qemu to see if that fixes things.  I
> > > didn't look closely to see if there are API changes.
> > 
> > The rebuild failed - it looks like there are some changes to capstone,
> > at least the location of the  headers file, which break
> > qemu source.  I'll see if there's anything we can backport from
> > upstream.
> 
> The headers haven't moved. It looks like the  capstone pkgconfig file is
> broken.
> 
> In 3.0.5 it had
> 
>   includedir=/usr/include/capstone
> 
> In 4.0.1 is has
> 
>   includedir=/usr/include

While I don't disagree that this file looks broken, it does seem as if
capstone wants you to use .  See the tests, for
example:

https://github.com/aquynh/capstone/blob/master/tests/test_basic.c

The below patch fixes qemu when using the system capstone, but
probably breaks when using the git-submodule capstone.  However I'll
drop this in as a *temporary* workaround to get Fedora building.

Rich.

diff --git a/include/disas/capstone.h b/include/disas/capstone.h
index 84e214956d..2eb6be222b 100644
--- a/include/disas/capstone.h
+++ b/include/disas/capstone.h
@@ -3,7 +3,7 @@
 
 #ifdef CONFIG_CAPSTONE
 
-#include 
+#include 
 
 #else
 


-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
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

Re: Unannounced soname bump: libcapstone.so.3 -> libcapstone.so.4

[Daniel P . Berrangé]

On Fri, Jan 11, 2019 at 09:30:29AM +, Daniel P. Berrangé wrote:
> On Fri, Jan 11, 2019 at 09:24:12AM +, Richard W.M. Jones wrote:
> > On Fri, Jan 11, 2019 at 09:14:29AM +, Richard W.M. Jones wrote:
> > > 
> > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1178711
> > > 
> > > This broke qemu, and indirectly libvirt.
> > > 
> > > I will submit a new build for qemu to see if that fixes things.  I
> > > didn't look closely to see if there are API changes.
> > 
> > The rebuild failed - it looks like there are some changes to capstone,
> > at least the location of the  headers file, which break
> > qemu source.  I'll see if there's anything we can backport from
> > upstream.
> 
> The headers haven't moved. It looks like the  capstone pkgconfig file is
> broken.
> 
> In 3.0.5 it had
> 
>   includedir=/usr/include/capstone
> 
> In 4.0.1 is has
> 
>   includedir=/usr/include

It seems they fixed this problem upstream in:

  
https://github.com/aquynh/capstone/pull/1276/commits/851c0ebdcd8f92a2845d03d901776731dfb42b2a

except the capstone.pc.in file is only used when building capstone
with cmake.  Our RPM builds it with plain make, and that calls
a generate-pkgconfig rule which is still broken.


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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

Re: Unannounced soname bump: libcapstone.so.3 -> libcapstone.so.4

[Daniel P . Berrangé]

On Fri, Jan 11, 2019 at 09:24:12AM +, Richard W.M. Jones wrote:
> On Fri, Jan 11, 2019 at 09:14:29AM +, Richard W.M. Jones wrote:
> > 
> > https://koji.fedoraproject.org/koji/buildinfo?buildID=1178711
> > 
> > This broke qemu, and indirectly libvirt.
> > 
> > I will submit a new build for qemu to see if that fixes things.  I
> > didn't look closely to see if there are API changes.
> 
> The rebuild failed - it looks like there are some changes to capstone,
> at least the location of the  headers file, which break
> qemu source.  I'll see if there's anything we can backport from
> upstream.

The headers haven't moved. It looks like the  capstone pkgconfig file is
broken.

In 3.0.5 it had

  includedir=/usr/include/capstone

In 4.0.1 is has

  includedir=/usr/include


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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

Re: Unannounced soname bump: libcapstone.so.3 -> libcapstone.so.4

[Richard W.M. Jones]

On Fri, Jan 11, 2019 at 09:14:29AM +, Richard W.M. Jones wrote:
> 
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1178711
> 
> This broke qemu, and indirectly libvirt.
> 
> I will submit a new build for qemu to see if that fixes things.  I
> didn't look closely to see if there are API changes.

The rebuild failed - it looks like there are some changes to capstone,
at least the location of the  headers file, which break
qemu source.  I'll see if there's anything we can backport from
upstream.

https://koji.fedoraproject.org/koji/taskinfo?taskID=31952591

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
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

Unannounced soname bump: libcapstone.so.3 -> libcapstone.so.4

[Richard W.M. Jones]

https://koji.fedoraproject.org/koji/buildinfo?buildID=1178711

This broke qemu, and indirectly libvirt.

I will submit a new build for qemu to see if that fixes things.  I
didn't look closely to see if there are API changes.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
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

Re: Organizing a "packager experience" objective and working group

[Vít Ondruch]

Dne 10. 01. 19 v 20:47 Artur Iwicki napsal(a):
> - Now that I've mentioned it, maybe we should add something like "fedpkg 
> fas-login"? Personally I've put "alias koji-init='kinit 
> my-fas-acco...@my-domain.org'" in my .bashrc, because looking up how to solve 
> the "koji says I'm unauthenticated" error got boring after the third time.


If you used Gnome Online Accounts, you would not need commands/scripts
like this.


Vít
___
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