[Fedocal] Reminder meeting : Fedora 26 Alpha Go/No-Go Meeting

[jkurik]

Dear all,

You are kindly invited to the meeting:
   Fedora 26 Alpha Go/No-Go Meeting on 2017-03-16 from 17:00:00 to 19:00:00 UTC
   At fedora-meetin...@irc.freenode.net

The meeting will be about:
Before each public release Development, QA and Release Engineering meet to 
determine if the release criteria are met for a particular release. This 
meeting is called the Go/No-Go Meeting. Verifying that the Release criteria are 
met is the responsibility of the QA Team.

Release Candidate (RC) availability and good QA coverage are prerequisites for 
the Go/No-Go meeting. If you have any bug on the list, please help us with 
Alpha release. If we won't be ready by Thursday, we will use this meeting to 
review blockers and decide what to do.


Source: https://apps.fedoraproject.org/calendar/meeting/5305/

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

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

[Nico Kadel-Garcia]

On Wed, Mar 15, 2017 at 9:51 AM, Tomasz Kłoczko
 wrote:
>
> On 15 March 2017 at 00:05, Jonathan Wakely 
> wrote:
>>
>> If glibc-static was removed from Fedora and that change propagated to
>> RHEL I know of companies that might stop being customers of Red Hat.
>>
>> Being unable to statically link their applications would be a
>> showstopper for some, and would cause them to move to a different
>> distro.
>
>
> So you want to say that RH already guarantees Linux ABI compatibility below
> glibc? I would be really surprised if it would be truth .. and I'm 100% sure
> that exactly this part is not in RH support small prints. In other words you
> may have only impression that this part is already covered in support
> conditions.
>
> Again try to answer on question why long time ago other OSes abandoned
> providing static libc?
> Internally this part is and always will be affected by definition by any
> future changes in kernel ABI. glibc it is not only libc library. Glibc
> provides couple of other components which are using internal glibc ABI/API.
> Shared libc wraps all those changes and allows handle (in long term) even
> quite significant changes beneath own glibc public API/ABI and on boundary
> between kernel<->user space without hurting user space binaries.
>
> And one more clarification: remove static libraries from glibc distro
> packages does not blocks static linking.
> It will only removes possibility linking against static glibc libraries.

Yes. This is a blocker for some people, who want *completely* static
binaries to have complete binary control of their active package.
glibc changing from a random update and possibly introducing a
regression problem is anathema to some critical software developers,
and the compilation of completely static binaries has been helpful for
cross-platform compatibility, for building chroot cages, and for
building well managed containers of various sorts.

Been there, done that with sorting out the library dependencies for
rssh chroot cages some time ago.

> You can ignore me but you cannot ignore facts behind why something like libc
> exist and why no one should use static version of the libc libraries.

I think you're mixing orthogonal concerns.

> Especially static linking with glibc is very dangerous as long if linked
> binary is using NSS libc interface. Some people are thinking that "fully"
> statically linked program does not use or will not need any DSOs. In case of
> using by such binary NSS libc interface this not true as depends on NSS map
> type and NSS settings (described in /etc/nsswitch.conf) will be causing
> loading nss_.so DSOs.

Well, yes. nsswitch.conf has been a mess since it was invented, for
reasons beyond the scope of this discussion.

> Number of changes in glibc in internal NSS interface where quite big in
> recent years, and if someone will/is using statically linked binary where
> NSS interface is in use such binary will be loading NSS modules (probably)
> compiled against not correct glibc.Result: execution of such binaries will
> fail or even crash with SIGSEV.
> This scenario is covered literally as well in glibc documentation:
> https://sourceware.org/glibc/wiki/FAQ#Even_statically_linked_programs_need_some_shared_libraries_which_is_not_acceptable_for_me.__What_can_I_do.3F

You seem to pointing out that NSS is a stability problem. You're quite
right. Saying that "NSS is unstable, therefore glibc should be forced
to dynamic libraries only" does not follow. The underlying API for
nsswitch.conf and NSS does not change that quickly, it's the feature
churn for add-ons that are being tied into NSS. For high stability
software, *who cared*? You won't use the most recent NSS changes, and
if you do, they're quite likely to be available the the glibc static
library at the time you compile them. Statically.

> It is already known that within next few years NSS area in glibc it will be
> probably one of the fastest changing area in glibc whole project. Solaris
> already coverers in his own libc many NSS security related extensions. Glibc
> has a lot to catch up here. All those upcoming changes will definitely even
> harder kick back all people linking own executables against glibc static
> libraries. This will be probably even bigger problem than all potential
> kernel<->user space ABI changes.

You've a point about NSS instability. That's actually quite
frightening. I lack your confidence that it justifies enforcing
dynamic libraries, and it seems *very* unlikely that the API's will
change enough to break older, stable software.

> Other static libraries used by distribution are carrying as well real and
> potential security risk.

It's true that it's a trade-off. The potential instability issue of a
glibc regression error is quite noticeable for high reliability
components, and even the "dnf update" process is vulnerable to glibc
update issues under some circumstances, such as running out of 

Schedule for Thursday's FPC Meeting (2017-03-16 16:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2017-03-16 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.

 Local time information (via. rktime):

2017-03-16 09:00 Thu US/Pacific PDT
2017-03-16 12:00 Thu US/Eastern EDT
2017-03-16 16:00 Thu UTC <-
2017-03-16 16:00 Thu Europe/London <-
2017-03-16 17:00 Thu Europe/Paris   CET
2017-03-16 17:00 Thu Europe/Berlin  CET
2017-03-16 21:30 Thu Asia/Calcutta  IST
--new day--
2017-03-17 00:00 Fri Asia/Singapore SGT
2017-03-17 00:00 Fri Asia/Hong_Kong HKT
2017-03-17 01:00 Fri Asia/Tokyo JST
2017-03-17 02:00 Fri Australia/BrisbaneAEST


 Links to all tickets below can be found at: 

https://pagure.io/packaging-committee/issues?status=Open=meeting

[Ed. note, this is intentionally blank
 there is currently an empty schedule]

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://pagure.io/packaging-committee/issues?status=Open=meeting

 If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fpc,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1432280] perl-XML-LibXML-2.0129 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-XML-LibXML-2.0129-1.fc26 has been pushed to the Fedora 26 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-2017-3610addcfd

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

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

[Tomasz Kłoczko]

OK here is full list of spec files which have glibc-static in BuildRequires:

./g/gcc.git/gcc.spec:BuildRequires: glibc-static
./g/gdb.git/gdb.spec:BuildRequires: glibc-static%{bits_local}
./g/gdb.git/gdb.spec:# multilib glibc-static is open Bug 488472:
./g/gdb.git/gdb.spec:#BuildRequires: glibc-static%{bits_other}
./g/glibc.git/glibc.spec:# before glibc is built and therefore we need
a glibc-static for that
./g/glibc.git/glibc.spec:BuildRequires: glibc-static
./g/glibc.git/glibc.spec:The glibc-static package contains the C
library static libraries
./g/glibc.git/glibc.spec:- Require glibc-static for C++ tests.
./g/glibc.git/glibc.spec:- Require gcc-c++, libstdc++-static, and
glibc-static only when needed.
./g/golang.git/golang.spec:BuildRequires:  pcre-devel, glibc-static, perl
./g/grub2.git/grub2.spec:BuildRequires:  /usr/lib64/crt1.o glibc-static
./g/grub2.git/grub2.spec:BuildRequires:  /usr/lib/crt1.o glibc-static
./b/binutils.git/binutils.spec:BuildRequires: dejagnu, zlib-static,
glibc-static, sharutils, bc
./b/binutils.git/binutils.spec:- Add glibc-static to BuildRequires
when running the testsuite.
./b/busybox.git/busybox.spec:BuildRequires: glibc-static
./c/cadvisor.git/cadvisor.spec:BuildRequires: glibc-static
./c/chkrootkit.git/chkrootkit.spec:BuildRequires:  glibc-static
./c/chkrootkit.git/chkrootkit.spec:- Fedora > 10: conditional BR
glibc-static as needed for strings-static
./c/compat-gcc-296.git/compat-gcc-296.spec:BuildRequires: glibc-devel
>= 2.2.90-12, glibc-static
./c/compat-gcc-32.git/compat-gcc-32.spec:BuildRequires: glibc-devel >=
2.2.90-12, glibc-static
./c/cscppc.git/cscppc.spec:BuildRequires: glibc-static
./c/cswrap.git/cswrap.spec:BuildRequires: glibc-static
./d/docker.git/docker.spec:BuildRequires: glibc-static
./d/docker-latest.git/docker-latest.spec:BuildRequires: glibc-static
./d/dyninst.git/dyninst.spec:BuildRequires: gcc-gfortran glibc-static
libstdc++-static nasm
./d/dyninst.git/dyninst.spec:Requires: glibc-static
./e/efivar.git/efivar.spec:BuildRequires:  popt-devel popt-static git
glibc-static libabigail
./k/kexec-tools.git/kexec-tools.spec:- Add BR glibc-static
./l/libguestfs.git/libguestfs.spec:BuildRequires: glibc-static
./l/libguestfs.git/libguestfs.spec:- BRs glibc-static for the new command tests.
./l/libhugetlbfs.git/libhugetlbfs.spec:BuildRequires: glibc-static
./l/libibmad.git/libibmad.spec:BuildRequires: glibc-static
./l/libibumad.git/libibumad.spec:BuildRequires: glibc-static
./l/libibumad.git/libibumad.spec:- Add build requires on glibc-static
./l/libvirt-sandbox.git/libvirt-sandbox.spec:BuildRequires: glibc-static
./m/mash.git/mash.spec:- allow glibc-static as a devel package
./m/mdadm.git/mdadm.spec:- Remove the glibc-static buildreq and don't
build the static mdadm since
./n/nacl-arm-binutils.git/nacl-arm-binutils.spec:BuildRequires:
dejagnu, zlib-static, glibc-static, sharutils
./n/nacl-binutils.git/nacl-binutils.spec:BuildRequires: dejagnu,
zlib-static, glibc-static, sharutils
./o/ocid.git/ocid.spec:BuildRequires:  glibc-static
./o/ORBit.git/ORBit.spec:BuildRequires: glibc-static
./o/ORBit.git/ORBit.spec:- BR: glibc-static for EL-6 onwards
./o/ORBit.git/ORBit.spec:- Buildreq glibc-static for test code in
bundled popt library (F-11 onwards)
./q/qemu-sanity-check.git/qemu-sanity-check.spec:BuildRequires:   glibc-static
./q/qemu.git/qemu.spec:BuildRequires: glibc-static pcre-static
glib2-static zlib-static
./r/redhat-lsb.git/redhat-lsb.spec:BuildRequires: glibc-static
./r/rkt.git/rkt.spec:BuildRequires: glibc-static
./s/scantailor.git/scantailor.spec:BuildRequires:  glibc-static
./s/supermin.git/supermin.spec:# To use glibc-static instead, do
``--without dietlibc''.  This
./s/supermin.git/supermin.spec:BuildRequires: glibc-static
./s/supermin.git/supermin.spec:- Enable dietlibc, remove glibc-static,
xz-static, zlib-static.
./s/supermin.git/supermin.spec:- New BRs on mke2fs, libext2fs, glibc-static.


Looking on this list without looking deeper into the packages it is easy to
figure out that almost half of the glibc-static using cases are related to
test suits.

BTW I found current Fedora guidelines about static linking and static
libraries and they are already forming set of rules which are recommending
what I've wrote here
https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries

In other words such subject has been discussed already and I'm not the only
one who is thinking that cutting to absolute minimum using static linking
and provide static libraries is right direction and/or thinking that Fedora
already provides some env to produce statically linked binaries is more or
less only kind of wrong impression.

And yet another grep output (this time a bit longer) which shows which
packages are using other packages static libraries:

./g/gcc.git/gcc.spec:BuildRequires: glibc*-static*
./g/gcl.git/gcl.spec:BuildRequires:  binutils*-static*
./g/gdal.git/gdal.spec:BuildRequires:   g2clib*-static*
./g/gdal.git/gdal.spec:BuildRequires: 

[Bug 1432700] New: perl-PkgConfig-LibPkgConf-0.07 is available

[bugzilla]

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

Bug ID: 1432700
   Summary: perl-PkgConfig-LibPkgConf-0.07 is available
   Product: Fedora
   Version: rawhide
 Component: perl-PkgConfig-LibPkgConf
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 0.07
Current version/release in rawhide: 0.06-1.fc27
URL: http://search.cpan.org/dist/PkgConfig-LibPkgConf/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/13749/

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

[EPEL-devel] RHEL-5 is 10 years old today

[Stephen John Smoogen]

According to wikipedia, on March 15, 2007 RHEL-5 was released. The
builders seem to have gotten updated to RHEL-5 around March 31st...
though packages were built in testing before then.



-- 
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Fedora Rawhide-20170315.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Server dvd i386
Xfce raw-xz armhfp
Server boot i386

Failed openQA tests: 14/107 (x86_64), 1/2 (i386), 1/2 (arm)

New failures (same test did not fail in Rawhide-20170314.n.0):

ID: 65287   Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/65287
ID: 65290   Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/65290
ID: 65291   Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/65291
ID: 65307   Test: x86_64 Workstation-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/65307
ID: 65310   Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/65310
ID: 65313   Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/65313
ID: 65355   Test: x86_64 universal install_simple_free_space@uefi
URL: https://openqa.fedoraproject.org/tests/65355
ID: 65362   Test: x86_64 universal install_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/65362
ID: 65369   Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/65369

Old failures (same test failed in Rawhide-20170314.n.0):

ID: 65286   Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/65286
ID: 65305   Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/65305
ID: 65308   Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/65308
ID: 65326   Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/65326
ID: 65374   Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/65374
ID: 65378   Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/65378
ID: 65379   Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/65379

Soft failed openQA tests: 53/107 (x86_64)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test did not soft fail in Rawhide-20170314.n.0):

ID: 65347   Test: x86_64 universal install_btrfs
URL: https://openqa.fedoraproject.org/tests/65347
ID: 65380   Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/65380

Old soft failures (same test soft failed in Rawhide-20170314.n.0):

ID: 65275   Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/65275
ID: 65276   Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/65276
ID: 65277   Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/65277
ID: 65278   Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/65278
ID: 65284   Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/65284
ID: 65285   Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/65285
ID: 65294   Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/65294
ID: 65296   Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/65296
ID: 65297   Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/65297
ID: 65328   Test: x86_64 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/65328
ID: 65329   Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/65329
ID: 65331   Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/65331
ID: 65332   Test: x86_64 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/65332
ID: 65333   Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/65333
ID: 65334   Test: x86_64 universal install_delete_pata
URL: https://openqa.fedoraproject.org/tests/65334
ID: 65335   Test: x86_64 universal install_delete_pata@uefi
URL: https://openqa.fedoraproject.org/tests/65335
ID: 65336   Test: x86_64 universal install_sata
URL: https://openqa.fedoraproject.org/tests/65336
ID: 65337   Test: x86_64 universal install_sata@uefi
URL: https://openqa.fedoraproject.org/tests/65337
ID: 65338   Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/65338
ID: 65339   Test: x86_64 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/65339
ID: 65340   Test: x86_64 

[Bug 1432280] perl-XML-LibXML-2.0129 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-XML-LibXML-2.0129-1.fc25 has been pushed to the Fedora 25 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-2017-676d2d0134

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

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

[Michael Cronenworth]

Please turn off HTML in GMail.

On 03/15/2017 02:26 PM, Tomasz Kłoczko wrote:
I can only repeat that such people should consider linking own binaries against 
uClibc as this implementation is not affected by issue with hidden loading NSS 
DSOs which probably make such binaries useless on moving around against latest 
fedora/RH7 and RH5.


Let's cut to the chase: You don't like glibc. OK. Do we need to create a 100+ email 
chain to thousands of Fedora developers who have more important things to do in 
their day? Feel free to discuss this on your blog or another medium.




Even at the end and idea of dropping building and providing glibc-static will be 
not accepted at least current list of packages which are using static linking with 
glibc libraries should be carefully reviewed. Looking on not full list of spec 
files which have listed "BuildRequires: glibc-static" i see for example mdadm 
abandoned static linking and again .. no one is crying about this.
Definitely almost all of the those +190 static packages can be abandoned without 
even single change in other Fedora spec files.


You'll have to do better than "because I don't like it." Just yesterday I had to 
create a binary that was SLES 10 compatible and thank-the-lord I had static 
libraries available in RHEL5 to be able to do it. There will be really strange cases 
that need static libraries around. They are not hurting anyone by having them 
present. Note: The previous sentence was brought to you buy a dynamic library supporter.




So far most of the cases which already found are using static linking with glibc 
is related to some test suits.
For example only binutils provides ld and ld-gold and they are responsible for 
linking with other libraries, and software like golang probably should not be 
doing own static linking tests because for such static linking is responsible 
binutils ld.


Those test suites are only executed during build time in Koji. They're not hurting 
you or any other Fedora user.

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

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

[Przemek Klosowski]

On 03/14/2017 03:46 PM, Tomasz Kłoczko wrote:
This problem is wy bigger than you may be thinking. Above it is 
only tip of the iceberg ..

# dnf list | grep -- -static | grep -c x86_64
196


This includes all available packages, but if you look at the actual 
usage on an average system, i.e. only static packages that are actually 
pulled in by requirements, it is much, much less. It seems that static 
packages are primarily available because some package managers perceive 
a potential need for static linking; for instance I see many scientific 
libraries (HDF, CDF, scalapack, FFTW), and in that case there is a 
residual speed effect and the statically linked applications have a 
(perhaps no longer deserved) reputation for being more easily distributable.


I checked on my F25 where I pretty much install everything I might ever 
need (6400 packages), and there are just 2 static packages:


   llvm-static-3.8.1-2.fc25.x86_64
   rust-std-static-1.14.0-2.fc25.x86_64

I think you'd have to explicitly load most of them to get up to 196.

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

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

[Tomasz Kłoczko]

On 15 March 2017 at 18:53, Jonathan Wakely 
wrote:

> There are people who use the static libraries, for their own reasons,
> and don't expect support when they do so.
>

I can only repeat that such people should consider linking own binaries
against uClibc as this implementation is not affected by issue with hidden
loading NSS DSOs which probably make such binaries useless on moving around
against latest fedora/RH7 and RH5.

Even at the end and idea of dropping building and providing glibc-static
will be not accepted at least current list of packages which are using
static linking with glibc libraries should be carefully reviewed. Looking
on not full list of spec files which have listed "BuildRequires:
glibc-static" i see for example mdadm abandoned static linking and again ..
no one is crying about this.
Definitely almost all of the those +190 static packages can be abandoned
without even single change in other Fedora spec files.

So far most of the cases which already found are using static linking with
glibc is related to some test suits.
For example only binutils provides ld and ld-gold and they are responsible
for linking with other libraries, and software like golang probably should
not be doing own static linking tests because for such static linking is
responsible binutils ld.

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

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

[Jonathan Wakely]

On 15/03/17 18:24 +0100, Florian Weimer wrote:

On 03/15/2017 01:05 AM, Jonathan Wakely wrote:

If glibc-static was removed from Fedora and that change propagated to
RHEL I know of companies that might stop being customers of Red Hat.


This is not the right list for discussing Red Hat Enterprise Linux 
matters, but please be advised that the above statement shall not be 
interpreted in such a way that indicates that static linking of glibc 
is supported on Red Hat Enterprise Linux.


Right, that's definitely not what I meant.

There are people who use the static libraries, for their own reasons,
and don't expect support when they do so.

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

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 737  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 500  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 202  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e8f4ff76b3   
chicken-4.11.0-3.el7
  82  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
  14  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-f1dce07331   
drupal7-views-3.15-1.el7
  14  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-f99defddc3   
munin-2.0.30-5.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-18d82f816f   
breeze-icon-theme-5.31.0-1.el7 extra-cmake-modules-5.31.0-3.el7 
kf5-5.31.0-1.el7 kf5-attica-5.31.0-1.el7 kf5-baloo-5.31.0-1.el7 
kf5-bluez-qt-5.31.0-1.el7 kf5-frameworkintegration-5.31.0-1.el7 
kf5-kactivities-5.31.0-1.el7 kf5-kactivities-stats-5.31.0-1.el7 
kf5-kapidox-5.31.0-1.el7 kf5-karchive-5.31.0-1.el7 kf5-kauth-5.31.0-1.el7 
kf5-kbookmarks-5.31.0-1.el7 kf5-kcmutils-5.31.0-1.el7 kf5-kcodecs-5.31.0-1.el7 
kf5-kcompletion-5.31.0-1.el7 kf5-kconfig-5.31.0-1.el7 
kf5-kconfigwidgets-5.31.0-1.el7 kf5-kcoreaddons-5.31.0-1.el7 
kf5-kcrash-5.31.0-1.el7 kf5-kdbusaddons-5.31.0-1.el7 
kf5-kdeclarative-5.31.0-1.el7 kf5-kded-5.31.0-1.el7 
kf5-kdelibs4support-5.31.0-1.el7 kf5-kdesignerplugin-5.31.0-1.el7 
kf5-kdesu-5.31.0-1.el7 kf5-kdewebkit-5.31.0-1.el7 kf5-kdnssd-5.31.0-1.el7 
kf5-kdoctools-5.31.0-1.el7 kf5-kemoticons-5.31.0-1.el7 
kf5-kfilemetadata-5.31.0-1.el7 kf5-kglobalaccel-5.31.0-1.el7 
kf5-kguiaddons-5.31.0-1.el7 kf5-khtml
 -5.31.0-1.el7 kf5-ki18n-5.31.0-1.el7 kf5-kiconthemes-5.31.0-1.el7 
kf5-kidletime-5.31.0-1.el7 kf5-kimageformats-5.31.0-1.el7 
kf5-kinit-5.31.0-1.el7 kf5-kio-5.31.0-2.el7 kf5-kitemmodels-5.31.0-1.el7 
kf5-kitemviews-5.31.0-1.el7 kf5-kjobwidgets-5.31.0-1.el7 kf5-kjs-5.31.0-1.el7 
kf5-kjsembed-5.31.0-1.el7 kf5-kmediaplayer-5.31.0-1.el7 
kf5-knewstuff-5.31.0-1.el7 kf5-knotifications-5.31.0-1.el7 
kf5-knotifyconfig-5.31.0-1.el7 kf5-kpackage-5.31.0-1.el7 
kf5-kparts-5.31.0-1.el7 kf5-kpeople-5.31.0-1.el7 kf5-kplotting-5.31.0-1.el7 
kf5-kpty-5.31.0-1.el7 kf5-kross-5.31.0-1.el7 kf5-krunner-5.31.0-1.el7 
kf5-kservice-5.31.0-1.el7 kf5-ktexteditor-5.31.0-2.el7 
kf5-ktextwidgets-5.31.0-1.el7 kf5-kunitconversion-5.31.0-1.el7 
kf5-kwallet-5.31.0-1.el7 kf5-kwidgetsaddons-5.31.0-1.el7 
kf5-kwindowsystem-5.31.0-1.el7 kf5-kxmlgui-5.31.0-1.el7 
kf5-kxmlrpcclient-5.31.0-1.el7 kf5-modemmanager-qt-5.31.0-1.el7 
kf5-networkmanager-qt-5.31.0-1.el7 kf5-plasma-5.31.0-1.el7 
kf5-solid-5.31.0-1.el7 kf5-sonnet-5.31.0-1.el7 kf5
 -syntax-highlighting-5.31.0-1.el7 kf5-threadweaver-5.31.0-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4c01d41d83   
php-pear-PHP-CodeSniffer-2.8.1-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-9701d0e0dd   
GraphicsMagick-1.3.25-6.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d2049ca0d4   
tor-0.2.9.10-1.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-19578898e6   
w3m-0.5.3-30.git20170102.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-c73452ca27   
tcpreplay-4.1.2-3.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-769c60931f   
wordpress-4.7.3-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6950a0884d   
R-3.3.3-1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-956d05f9c4   
mbedtls-2.4.2-1.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

golang-github-beorn7-perks-0-0.10.git4c0e845.el7
golang-github-coreos-pkg-0-0.12.git3ac0863.el7
golang-github-golang-sys-0-0.11.git478fcf5.el7
golang-github-jonboulle-clockwork-0-0.10.git2eee05e.el7
golang-github-mattn-go-runewidth-0-0.5.git737072b.el7
golang-github-russross-blackfriday-1.2-17.el7
golang-github-shurcooL-sanitized_anchor_name-0-0.13.git1dba4b3.el7
golang-github-xiang90-probing-0-0.6.git07dd2e8.el7
httping-2.5-1.el7
mbedtls-2.4.2-1.el7
moarvm-0.2017.02-1.el7
module-build-service-1.3.6-1.el7
nqp-0.0.2017.02-1.el7
prelude-correlator-3.1.0-3.el7
rakudo-0.2017.02-1.el7
tinc-1.0.31-1.el7
znc-1.6.5-1.el7

Details about builds:



 golang-github-beorn7-perks-0-0.10.git4c0e845.el7 (FEDORA-EPEL-2017-ef9ec9b242)
 Effective Computation of Things

Update Information:

Bump to upstream 4c0e84591b9aa9e6dcfdf3e020114cd81f89d5f9    Polish the spec
file

References:

  [ 1 ] Bug #1248633 - Tracker for golang-github-beorn7-perks
https://bugzilla.redhat.com/show_bug.cgi?id=1248633

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

[Jonathan Wakely]

On 15/03/17 13:51 +, Tomasz Kłoczko wrote:

On 15 March 2017 at 00:05, Jonathan Wakely 
wrote:


If glibc-static was removed from Fedora and that change propagated to
RHEL I know of companies that might stop being customers of Red Hat.

Being unable to statically link their applications would be a
showstopper for some, and would cause them to move to a different
distro.



So you want to say that RH already guarantees Linux ABI compatibility below
glibc?


I don't think that's what I want to say. If I wanted to say that I'd
have said it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Fedora EPEL 6 updates-testing report

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 616  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7031   
python-virtualenv-12.0.7-1.el6
 610  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 500  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 471  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 202  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-8594ed3a53   
chicken-4.11.0-3.el6
  82  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
  66  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-8c6c7bf06e   
dbus-sharp-0.7.0-16.el6 dbus-sharp-glib-0.5.0-14.el6 mono-4.2.4-9.el6
  32  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-acd2c2af0d   
nagios-4.2.4-4.el6
  24  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-c3b112eb9e   
tomcat-7.0.75-1.el6
  14  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e4e18670f5   
drupal7-views-3.15-1.el6
  14  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-23896f34bd   
munin-2.0.30-5.el6
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6f8067610a   
GraphicsMagick-1.3.25-6.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-1e1f31ce42   
tor-0.2.9.10-1.el6
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-27a44b4bbf   
tcpreplay-4.1.2-3.el6
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-50cbc23498   
wordpress-4.7.3-1.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-23481d5e1a   
icoutils-0.31.2-1.el6
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-1ad70123a8   
R-3.3.3-1.el6
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-75190374ce   
moodle-2.7.19-1.el6
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-eb18b4839a   
mbedtls-2.4.2-1.el6
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-b1bba0f99d   
roundcubemail-1.0.9-2.el6


The following builds have been pushed to Fedora EPEL 6 updates-testing

golang-github-beorn7-perks-0-0.10.git4c0e845.el6
golang-github-coreos-pkg-0-0.12.git3ac0863.el6
golang-github-golang-sys-0-0.11.git478fcf5.el6
golang-github-jonboulle-clockwork-0-0.10.git2eee05e.el6
golang-github-mattn-go-runewidth-0-0.5.git737072b.el6
golang-github-russross-blackfriday-1.2-17.el6
golang-github-shurcooL-sanitized_anchor_name-0-0.13.git1dba4b3.el6
golang-github-xiang90-probing-0-0.6.git07dd2e8.el6
mbedtls-2.4.2-1.el6
moodle-2.7.19-1.el6
nedit-5.7-1.el6
roundcubemail-1.0.9-2.el6

Details about builds:



 golang-github-beorn7-perks-0-0.10.git4c0e845.el6 (FEDORA-EPEL-2017-a73c1dbde8)
 Effective Computation of Things

Update Information:

Bump to upstream 4c0e84591b9aa9e6dcfdf3e020114cd81f89d5f9

References:

  [ 1 ] Bug #1248633 - Tracker for golang-github-beorn7-perks
https://bugzilla.redhat.com/show_bug.cgi?id=1248633




 golang-github-coreos-pkg-0-0.12.git3ac0863.el6 (FEDORA-EPEL-2017-72814742dd)
 A collection of go utility packages

Update Information:

Bump to upstream 3ac0863d7acf3bc44daf49afef8919af12f704ef

References:

  [ 1 ] Bug #1245958 - Review Request: golang-github-coreos-pkg - A collection 
of go utility packages
https://bugzilla.redhat.com/show_bug.cgi?id=1245958




 golang-github-golang-sys-0-0.11.git478fcf5.el6 (FEDORA-EPEL-2017-24f2f921e7)
 Go packages for low-level interaction with the operating system

Update Information:

Bump to upstream 478fcf54317e52ab69f40bb4c7a1520288d7f7ea

References:

  [ 1 ] Bug #1360748 - update for s390x support
https://bugzilla.redhat.com/show_bug.cgi?id=1360748




 golang-github-jonboulle-clockwork-0-0.10.git2eee05e.el6 
(FEDORA-EPEL-2017-879cc10773)
 A fake clock for golang

[EPEL-devel] Fedora EPEL 5 updates-testing report

[updates]

The following Fedora EPEL 5 Security updates need testing:
 Age  URL
 857  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2014-3849   
sblim-sfcb-1.3.8-2.el5
 500  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-edbea40516   
mcollective-2.8.4-1.el5
 471  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-582c8075e6   
thttpd-2.25b-24.el5
  82  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-ce45574ab6   
libbsd-0.8.3-2.el5
  14  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e531f99c94   
drupal7-metatag-1.21-1.el5
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-33a8a8497b   
drupal7-views-3.15-1.el5
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-1871d47e50   
tcpreplay-4.1.2-3.el5
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-cfa4c77c94   
wordpress-4.7.3-1.el5
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-0e124edd46   
R-3.3.3-1.el5
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-84be6f00e6   
mbedtls-2.4.2-1.el5


The following builds have been pushed to Fedora EPEL 5 updates-testing

mbedtls-2.4.2-1.el5

Details about builds:



 mbedtls-2.4.2-1.el5 (FEDORA-EPEL-2017-84be6f00e6)
 Light-weight cryptographic and SSL/TLS library

Update Information:

- Update to 2.4.2 - CVE-2017-2784  Release notes: https://tls.mbed.org/tech-
updates/releases/mbedtls-2.4.2-2.1.7-and-1.3.19-released Security notes:
https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-
advisory-2017-01

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

Re: Static libraries in Fedora distribution

[Tomasz Kłoczko]

On 15 March 2017 at 17:22, Florian Weimer  wrote:

> Please read again what I wrote.
>
> In a container (and multi-toolchain) world, static linking of glibc does
> not add a significant support burden because we cannot use glibc as an
> abstraction layer for the kernel, unlike what other operating systems do.
> (This is independently of what is actually supported.)
>

Please try to have look first on "dnf list | grep -- - static" list maybe
after this you will realise that current list of packages with static
libraries is not enough to have such static linking dev environment because *in
last years many packages already dropped building and packaging static
libraries,* and no one been crying by this.
For cases which will mainly require for some reasons static linking with
libc.a probably it would be good consider switch to uClibc because in such
cases size of the binaries probably is quite important.

I have no idea from where it comes but glibc never was and never will be
abstraction layer for the kernel on any existing operating systems because
kernel provides abstraction layer on which sits (g)libc.

I'm still greping across all packages repos but so far I found only two
fedora packages which requires during build glibc-static. One is binutils
and second one is golang. Both packages uses static linking in own test
suits.
To test binutils ld that it able to link elf binary or DSO using some test
static libraries you don't need to link such test binary with libc.a.

Will have shortly full assessment of what really is using in Fedora
glibc-static.

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

Fwd: Broken dependencies: boost

[Jonathan Wakely]

Does anybody know why I'd have got this today?

The only recent change to Boost is to enabled the MPI packages on
ppc64le, but that shouldn't have affected all arches:


--- a/boost.spec
+++ b/boost.spec
@@ -7,11 +7,8 @@
%global boost_docdir __tmp_docdir
%global boost_examplesdir __tmp_examplesdir

-%ifarch ppc64le
-  %bcond_with mpich
-%else
-  %bcond_without mpich
-%endif
+# All arches have mpich
+%bcond_without mpich

%ifarch s390
  # No OpenMPI support on these arches


The packages are complaining about a missing dependency *that is
provided by that package itself*!

Maybe relevant is that the "missing" libs are not installed to the
usual %{_libdir} location but to %{_libdir}/mpich/lib/ (for the mpich
variants) or %{_libdir}/openmpi/lib/ (for the openmpi variants).



- Forwarded message from build...@fedoraproject.org -

Date: Wed, 15 Mar 2017 17:17:47 + (UTC)
From: build...@fedoraproject.org
To: boost-ow...@fedoraproject.org
Cc: 
Subject: Broken dependencies: boost




boost has broken dependencies in the rawhide tree:
On x86_64:
boost-graph-openmpi-1.63.0-5.fc27.x86_64 requires 
libboost_graph_parallel.so.1.63.0()(64bit)
On armhfp:
boost-graph-openmpi-1.63.0-5.fc27.armv7hl requires 
libboost_graph_parallel.so.1.63.0
On ppc64le:
boost-graph-openmpi-1.63.0-5.fc27.ppc64le requires 
libboost_graph_parallel.so.1.63.0()(64bit)
On aarch64:
boost-graph-openmpi-1.63.0-5.fc27.aarch64 requires 
libboost_graph_parallel.so.1.63.0()(64bit)
On ppc64:
boost-graph-openmpi-1.63.0-5.fc27.ppc64 requires 
libboost_graph_parallel.so.1.63.0()(64bit)
On i386:
boost-graph-openmpi-1.63.0-5.fc27.i686 requires 
libboost_graph_parallel.so.1.63.0
On x86_64:
boost-openmpi-1.63.0-5.fc27.x86_64 requires 
libboost_mpi.so.1.63.0()(64bit)
On armhfp:
boost-openmpi-1.63.0-5.fc27.armv7hl requires libboost_mpi.so.1.63.0
On ppc64le:
boost-openmpi-1.63.0-5.fc27.ppc64le requires 
libboost_mpi.so.1.63.0()(64bit)
On aarch64:
boost-openmpi-1.63.0-5.fc27.aarch64 requires 
libboost_mpi.so.1.63.0()(64bit)
On ppc64:
boost-openmpi-1.63.0-5.fc27.ppc64 requires 
libboost_mpi.so.1.63.0()(64bit)
On i386:
boost-openmpi-1.63.0-5.fc27.i686 requires libboost_mpi.so.1.63.0
On x86_64:
boost-openmpi-python-1.63.0-5.fc27.x86_64 requires 
libboost_mpi_python.so.1.63.0()(64bit)
On armhfp:
boost-openmpi-python-1.63.0-5.fc27.armv7hl requires 
libboost_mpi_python.so.1.63.0
On ppc64le:
boost-openmpi-python-1.63.0-5.fc27.ppc64le requires 
libboost_mpi_python.so.1.63.0()(64bit)
On aarch64:
boost-openmpi-python-1.63.0-5.fc27.aarch64 requires 
libboost_mpi_python.so.1.63.0()(64bit)
On ppc64:
boost-openmpi-python-1.63.0-5.fc27.ppc64 requires 
libboost_mpi_python.so.1.63.0()(64bit)
On i386:
boost-openmpi-python-1.63.0-5.fc27.i686 requires 
libboost_mpi_python.so.1.63.0
On x86_64:
boost-mpich-1.63.0-5.fc27.x86_64 requires 
libboost_mpi.so.1.63.0()(64bit)
On armhfp:
boost-mpich-1.63.0-5.fc27.armv7hl requires libboost_mpi.so.1.63.0
On ppc64le:
boost-mpich-1.63.0-5.fc27.ppc64le requires 
libboost_mpi.so.1.63.0()(64bit)
On aarch64:
boost-mpich-1.63.0-5.fc27.aarch64 requires 
libboost_mpi.so.1.63.0()(64bit)
On ppc64:
boost-mpich-1.63.0-5.fc27.ppc64 requires libboost_mpi.so.1.63.0()(64bit)
On i386:
boost-mpich-1.63.0-5.fc27.i686 requires libboost_mpi.so.1.63.0
On x86_64:
boost-mpich-python-1.63.0-5.fc27.x86_64 requires 
libboost_mpi_python.so.1.63.0()(64bit)
On armhfp:
boost-mpich-python-1.63.0-5.fc27.armv7hl requires 
libboost_mpi_python.so.1.63.0
On ppc64le:
boost-mpich-python-1.63.0-5.fc27.ppc64le requires 
libboost_mpi_python.so.1.63.0()(64bit)
On aarch64:
boost-mpich-python-1.63.0-5.fc27.aarch64 requires 
libboost_mpi_python.so.1.63.0()(64bit)
On ppc64:
boost-mpich-python-1.63.0-5.fc27.ppc64 requires 
libboost_mpi_python.so.1.63.0()(64bit)
On i386:
boost-mpich-python-1.63.0-5.fc27.i686 requires 
libboost_mpi_python.so.1.63.0
On x86_64:
boost-graph-mpich-1.63.0-5.fc27.x86_64 requires 
libboost_graph_parallel.so.1.63.0()(64bit)
On armhfp:
boost-graph-mpich-1.63.0-5.fc27.armv7hl requires 
libboost_graph_parallel.so.1.63.0
On ppc64le:
boost-graph-mpich-1.63.0-5.fc27.ppc64le requires 
libboost_graph_parallel.so.1.63.0()(64bit)
On aarch64:
boost-graph-mpich-1.63.0-5.fc27.aarch64 requires 
libboost_graph_parallel.so.1.63.0()(64bit)
On ppc64:
boost-graph-mpich-1.63.0-5.fc27.ppc64 requires 
libboost_graph_parallel.so.1.63.0()(64bit)
On i386:
boost-graph-mpich-1.63.0-5.fc27.i686 requires 
libboost_graph_parallel.so.1.63.0
Please resolve this as soon as possible.



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

[Bug 1429446] perl-DateTime-Format-Flexible-0.27 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-DateTime-Format-Flexib |perl-DateTime-Format-Flexib
   |le-0.27-1.fc27  |le-0.27-1.fc27
   |perl-DateTime-Format-Flexib |perl-DateTime-Format-Flexib
   |le-0.27-1.fc25  |le-0.27-1.fc25
   ||perl-DateTime-Format-Flexib
   ||le-0.27-1.fc24



--- Comment #9 from Fedora Update System  ---
perl-DateTime-Format-Flexible-0.27-1.fc24 has been pushed to the Fedora 24
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

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

[Josh Stone]

On 03/15/2017 10:08 AM, Daniel P. Berrange wrote:
> On Wed, Mar 15, 2017 at 09:56:50AM -0700, Josh Stone wrote:
>> On 03/14/2017 05:05 PM, Jonathan Wakely wrote:
>>> If glibc-static was removed from Fedora and that change propagated to
>>> RHEL I know of companies that might stop being customers of Red Hat.
>>
>> Even if Fedora removed it, we could still make the business decision to
>> add it back to RHEL.

To be clear, I'm not advocating removal, just trying to say that
worrying about RHEL is the wrong approach.

>>> Being unable to statically link their applications would be a
>>> showstopper for some, and would cause them to move to a different
>>> distro.
>>
>> This may still be a useful consideration for Fedora itself.  Would we
>> alienate anyone if Fedora removed glibc-static?
> 
> Yes, you would prevent us from being able to build static binaries for
> the QEMU system emulators in Fedora QEMU packages. This in turn prevents
> them from being used to provide seemless execution from non-native
> architecture chroots / containers. This is used for example, by flatpack
> to allow non-native architecture compilation, or as well as by myself
> for various personal projects needing non-native compilation environments.
> 
> I agree there are many reasons why static libraries are a bad idea in
> general, particularly the security implications, but they are none the
> less useful at times and not every usage scenario has the same security
> requirements.
> 
> NB, throwing out all the -static RPMs doesn't magically remove static
> compilation from Fedora. There are entire non-C language toolchains in
> Fedora that are based on static compilation - eg OCaml and Go 

Yep, I maintain Rust which is one of these.  But it does still default
to shared linking for libc and any other FFI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

[Florian Weimer]

On 03/15/2017 01:05 AM, Jonathan Wakely wrote:

If glibc-static was removed from Fedora and that change propagated to
RHEL I know of companies that might stop being customers of Red Hat.


This is not the right list for discussing Red Hat Enterprise Linux 
matters, but please be advised that the above statement shall not be 
interpreted in such a way that indicates that static linking of glibc is 
supported on Red Hat Enterprise Linux.


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

Re: Static libraries in Fedora distribution

[Florian Weimer]

On 03/15/2017 05:45 PM, Tomasz Kłoczko wrote:

You are not even trying to answer on above question .. a bit sad because
you are simple ignoring some very good technical arguments.


Please read again what I wrote.

In a container (and multi-toolchain) world, static linking of glibc does 
not add a significant support burden because we cannot use glibc as an 
abstraction layer for the kernel, unlike what other operating systems 
do.  (This is independently of what is actually supported.)


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

Broken dependencies: perl-ZMQ-LibZMQ2

[buildsys]

perl-ZMQ-LibZMQ2 has broken dependencies in the rawhide tree:
On x86_64:
perl-ZMQ-LibZMQ2-1.09-9.fc25.x86_64 requires libzmq.so.1()(64bit)
On armhfp:
perl-ZMQ-LibZMQ2-1.09-9.fc25.armv7hl requires libzmq.so.1
On ppc64le:
perl-ZMQ-LibZMQ2-1.09-9.fc25.ppc64le requires libzmq.so.1()(64bit)
On aarch64:
perl-ZMQ-LibZMQ2-1.09-9.fc25.aarch64 requires libzmq.so.1()(64bit)
On ppc64:
perl-ZMQ-LibZMQ2-1.09-9.fc25.ppc64 requires libzmq.so.1()(64bit)
On i386:
perl-ZMQ-LibZMQ2-1.09-9.fc25.i686 requires libzmq.so.1
Please resolve this as soon as possible.

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

Broken dependencies: perl-ZMQ-LibZMQ3

[buildsys]

perl-ZMQ-LibZMQ3 has broken dependencies in the rawhide tree:
On x86_64:
perl-ZMQ-LibZMQ3-1.19-5.fc25.x86_64 requires libzmq.so.3()(64bit)
On armhfp:
perl-ZMQ-LibZMQ3-1.19-5.fc25.armv7hl requires libzmq.so.3
On ppc64le:
perl-ZMQ-LibZMQ3-1.19-5.fc25.ppc64le requires libzmq.so.3()(64bit)
On aarch64:
perl-ZMQ-LibZMQ3-1.19-5.fc25.aarch64 requires libzmq.so.3()(64bit)
On ppc64:
perl-ZMQ-LibZMQ3-1.19-5.fc25.ppc64 requires libzmq.so.3()(64bit)
On i386:
perl-ZMQ-LibZMQ3-1.19-5.fc25.i686 requires libzmq.so.3
Please resolve this as soon as possible.

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

Broken dependencies: perl-ZeroMQ

[buildsys]

perl-ZeroMQ has broken dependencies in the rawhide tree:
On x86_64:
perl-ZeroMQ-0.23-13.fc25.x86_64 requires libzmq.so.1()(64bit)
On armhfp:
perl-ZeroMQ-0.23-13.fc25.armv7hl requires libzmq.so.1
On ppc64le:
perl-ZeroMQ-0.23-13.fc25.ppc64le requires libzmq.so.1()(64bit)
On aarch64:
perl-ZeroMQ-0.23-13.fc25.aarch64 requires libzmq.so.1()(64bit)
On ppc64:
perl-ZeroMQ-0.23-13.fc25.ppc64 requires libzmq.so.1()(64bit)
On i386:
perl-ZeroMQ-0.23-13.fc25.i686 requires libzmq.so.1
Please resolve this as soon as possible.

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

Broken dependencies: perl-Alien-ROOT

[buildsys]

perl-Alien-ROOT has broken dependencies in the rawhide tree:
On aarch64:
perl-Alien-ROOT-5.34.36.1-4.fc26.noarch requires root-core
On ppc64:
perl-Alien-ROOT-5.34.36.1-4.fc26.noarch requires root-core
On ppc64le:
perl-Alien-ROOT-5.34.36.1-4.fc26.noarch requires root-core
Please resolve this as soon as possible.

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

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

[Daniel P. Berrange]

On Wed, Mar 15, 2017 at 09:56:50AM -0700, Josh Stone wrote:
> On 03/14/2017 05:05 PM, Jonathan Wakely wrote:
> > If glibc-static was removed from Fedora and that change propagated to
> > RHEL I know of companies that might stop being customers of Red Hat.
> 
> Even if Fedora removed it, we could still make the business decision to
> add it back to RHEL.
> 
> > Being unable to statically link their applications would be a
> > showstopper for some, and would cause them to move to a different
> > distro.
> 
> This may still be a useful consideration for Fedora itself.  Would we
> alienate anyone if Fedora removed glibc-static?

Yes, you would prevent us from being able to build static binaries for
the QEMU system emulators in Fedora QEMU packages. This in turn prevents
them from being used to provide seemless execution from non-native
architecture chroots / containers. This is used for example, by flatpack
to allow non-native architecture compilation, or as well as by myself
for various personal projects needing non-native compilation environments.

I agree there are many reasons why static libraries are a bad idea in
general, particularly the security implications, but they are none the
less useful at times and not every usage scenario has the same security
requirements.

NB, throwing out all the -static RPMs doesn't magically remove static
compilation from Fedora. There are entire non-C language toolchains in
Fedora that are based on static compilation - eg OCaml and Go 

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

[Zygmunt Krynicki]

> Wiadomość napisana przez Josh Stone  w dniu 15.03.2017, o 
> godz. 17:56:
> 
> This may still be a useful consideration for Fedora itself.  Would we
> alienate anyone if Fedora removed glibc-static?

I think that this particular case should not be removed. Some tools do need 
static linking (e.g. initrd bits) and while those are obscure they are not 
really gone or on their way out. I would prefer not to remove static libraries 
even if they cause the well known issues as people that use them typically know 
why they are doing it.

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

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

[Josh Stone]

On 03/14/2017 05:05 PM, Jonathan Wakely wrote:
> If glibc-static was removed from Fedora and that change propagated to
> RHEL I know of companies that might stop being customers of Red Hat.

Even if Fedora removed it, we could still make the business decision to
add it back to RHEL.

> Being unable to statically link their applications would be a
> showstopper for some, and would cause them to move to a different
> distro.

This may still be a useful consideration for Fedora itself.  Would we
alienate anyone if Fedora removed glibc-static?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Static libraries in Fedora distribution

[Tomasz Kłoczko]

On 15 March 2017 at 14:16, Florian Weimer  wrote:
[..]

> The main problem with static linking in Fedora is that we do not rebuild
> all static libraries once we update glibc-static.  glibc only provides ABI
> compatibility for dynamic linking.  The only saving grace is that we
> gradually cut back on the use of compatibility symbols to make header file
> changes, so incompatible changes have been quite rare for a while.
>
> This isn't really glibc-specific, though, it probably applies to other
> static libraries, too.  The impact of changes to glibc-static are just more
> visible.
>
> Again try to answer on question why long time ago other OSes abandoned
>> providing static libc?
>>
>
> I think those other operating systems simply do not expose internal
> development tools externally.  They still use static linking in some places.
>

You are not even trying to answer on above question .. a bit sad because
you are simple ignoring some very good technical arguments.
Trying to crush what you are thinking about subject using stronger phrases
would illogical and I'm not going to follow this path. Really pleas try to
stick to technical arguments.
Discussion it is like fencing but using arguments. It is really hard try to
convince someone using what "I think". Look again on what I've already
wrote and you will find that none of my argumentation relies on what "I'm
thinking".

Again: there was already enough bad cases in Unix history to form
conclusion that none of the regular distribution consumers should rely on
things below libc public ABI/API because unconsciously using such parts
they been doing for themselves more harm than real financial/reputation or
other damages to anyone who is trying to provide commercial or
non-commercial support of any OS distribution.

I'll try to rephrase above. In the past I've been working on whole rpm
based distribution and more than decade ago I made decision about separate
all static libraries into -static subpackages. After what we (me and few my
colleagues) done other distros started mimicking this pattern. It was done
consequently on scale +6k source packages (used by ~few thousands end
users) and after this I found that it was none real case scenario where
those static packages are really needed.
Look on what is now in Fedora and you will find that binutils has some
quite strange or easy to handle other way modifications in spec file only
to fully follow what is in source code binutils test suit.

What I've personally tested long time ago still stands firmly against you
honest impression (that such resources still may be good to have around in
form of packages).
In other words: what you see now in distribution like Fedora like some
-static subpackages it is because what I've personally started more than
decade ago.
IMO now is enough good sample of using such approach (separating static
libraries) to form conclusion that this was kind of mistake and all those
static libraries can be dropped without any noticeable consequences ..  on
even some hard/nasty developers oriented install profiles.

With all what you are trying (honestly) to tell is like with some aspects
of quantum physics which says that probability that bucket of water
standing on top of open fire may freeze is non-zero.
Problem is that in real word maintained by real engineers it is really hard
to observe something like this :)
Many years ago I've been thinking just like you because same like you I've
been using intuition.
Trust me. If you are still *thinking* that you are right, it may be really
truth .. that you are *only thinking* that you are right  :)

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

Re: Default permissions on /dev/kvm

[Daniel J Walsh]

On 03/15/2017 11:49 AM, Daniel P. Berrange wrote:
> On Wed, Mar 15, 2017 at 11:32:35AM -0400, Dusty Mabe wrote:
>>
>> On 03/15/2017 05:17 AM, Daniel P. Berrange wrote:
>>> Sure, if udev maintainers are willing to ship the kvm rule by default,
>>> that's fine with me for reason you suggest. I simply don't think it'll
>>> have any effect on usage of /dev/kvm inside containers
>>>
>> Does that mean you assume my scenario I outlined is incorrect? The
>> only reason we are having this discussion is because i found that
>> changing the permissions of /dev/kvm on the host from 600 to 666 made
>> it so that I could run libvirt inside a container, which would mean
>> that if does have an effect on usage of /dev/kvm inside a container.
> Oh, wait I think I see - you don't have qemu installed in the host
> at all - you only installed it inside a docker image, but docker
> is just copying the host permissions, and thus see the default
> permissions from the kernel.
>
>> I could be "using it wrong", but would like for you to tell me why
>> what I'm doing is invalid.
> While Docker copies the permissions from host devices, I don't think
> that is something it is nice to rely on. Different operating systems
> have different views on what default permissions are. So if you build
> a Docker image that relies on the host OS having given /dev/kvm
> particular permissions, your Docker image is going to be non-portable.
>
> IOW while moving the udev rule out of the QEMU rpm into the udev RPM
> would fix it for future Fedora, your docker image is going to be
> unable to reliably run on other OS distros (whether older Fedora or
> Debian which has restrictive /dev/kvm by default).
>
> I don't see any way to force docker to give the device different
> permissions when using the --device flag to launch a container.
> In absence of that the only other option is to use an entrypoint
> script to chmod the file when your container starts, but that
> requires the container to run privileged which is bad. I think
> ideally Docker would provide some way to give explicit permissions
> so your container is isolated from decisions OS distros make about
> default permissions in the host. 
>
> Regards,
> Daniel
Lets open a bugzilla on this for docker, although I am not sure upstream
would be amenable to a decent solution.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

dist.upgradepath FAILED for FEDORA-2017-83ab2706c3

[notifications]

dist.upgradepath FAILED for FEDORA-2017-83ab2706c3

https://taskotron.fedoraproject.org/artifacts/all/c768c4bd-099b-11e7-9a30-bf512dda9403/task_output/FEDORA-2017-83ab2706c3.log
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

dist.upgradepath FAILED for perl-Text-Glob-0.11-1.fc25

[notifications]

dist.upgradepath FAILED for perl-Text-Glob-0.11-1.fc25

https://taskotron.fedoraproject.org/artifacts/all/c768c4bd-099b-11e7-9a30-bf512dda9403/task_output/perl-Text-Glob-0.11-1.fc25.log
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1432270] perl-libwww-perl-6.24 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-libwww-perl-6.24-1.fc2
   ||7
 Resolution|--- |RAWHIDE
Last Closed||2017-03-15 12:01:46



--- Comment #1 from Petr Pisar  ---
This release changes code about setting proxy. It looks small but it could have
large impact. I will keep it for rawhide only. At least now.

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

ppisar pushed to perl-libwww-perl (master). "6.24 bump"

[notifications]

From cb5f54d50c0cf789de762a3af0772e0a2193fb70 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Wed, 15 Mar 2017 16:52:17 +0100
Subject: 6.24 bump

---
 .gitignore|  1 +
 perl-libwww-perl.spec | 11 ++-
 sources   |  2 +-
 3 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/.gitignore b/.gitignore
index a91ef53..add8250 100644
--- a/.gitignore
+++ b/.gitignore
@@ -17,3 +17,4 @@ libwww-perl-5.834.tar.gz
 /libwww-perl-6.21.tar.gz
 /libwww-perl-6.22.tar.gz
 /libwww-perl-6.23.tar.gz
+/libwww-perl-6.24.tar.gz
diff --git a/perl-libwww-perl.spec b/perl-libwww-perl.spec
index 72f6dfb..727262b 100644
--- a/perl-libwww-perl.spec
+++ b/perl-libwww-perl.spec
@@ -1,5 +1,5 @@
 Name:   perl-libwww-perl
-Version:6.23
+Version:6.24
 Release:1%{?dist}
 Summary:A Perl interface to the World-Wide Web
 License:GPL+ or Artistic
@@ -9,7 +9,6 @@ Source0:
http://www.cpan.org/authors/id/O/OA/OALDERS/libwww-perl-%{versio
 Patch0: libwww-perl-6.19-Accept-proxy-URLs-with-IPv6-host-names.patch
 BuildArch:  noarch
 BuildRequires:  coreutils
-BuildRequires:  findutils
 BuildRequires:  make
 BuildRequires:  perl
 BuildRequires:  perl-generators
@@ -125,13 +124,12 @@ use and even classes that help you implement simple HTTP 
servers.
 
 %build
 # Install the aliases by default
-perl Makefile.PL INSTALLDIRS=vendor --aliases < /dev/null
+perl Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1 --aliases < /dev/null
 make %{?_smp_mflags}
 
 %install
 make pure_install DESTDIR=$RPM_BUILD_ROOT
-find $RPM_BUILD_ROOT -type f -name .packlist -delete
-chmod -R u+w $RPM_BUILD_ROOT/*
+%{_fixperms} $RPM_BUILD_ROOT/*
 
 %check
 # Some optional tests require resolvable hostname
@@ -148,6 +146,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Wed Mar 15 2017 Petr Pisar  - 6.24-1
+- 6.24 bump
+
 * Tue Mar 07 2017 Petr Pisar  - 6.23-1
 - 6.23 bump
 
diff --git a/sources b/sources
index be251c6..621b4a2 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (libwww-perl-6.23.tar.gz) = 
c6ab7177078c586272f59377225fdefbecc4ce5edf469c9274990c76f44101adfa5420b762ed115dc5fd44cbd95590e61ba6bdd8c18ebd41f6ca282008bd0287
+SHA512 (libwww-perl-6.24.tar.gz) = 
433e62b802f770b1d7c46bbe3a3b16c0e4423ded77b04f394a49340da98a97c74f8332ffc29c1bc0765cdc8277a2fe110a371b6b0be0f9e94ed104273ee0a1d1
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-libwww-perl.git/commit/?h=master=cb5f54d50c0cf789de762a3af0772e0a2193fb70
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Default permissions on /dev/kvm

[Daniel P. Berrange]

On Wed, Mar 15, 2017 at 11:32:35AM -0400, Dusty Mabe wrote:
> 
> 
> On 03/15/2017 05:17 AM, Daniel P. Berrange wrote:
> > 
> > Sure, if udev maintainers are willing to ship the kvm rule by default,
> > that's fine with me for reason you suggest. I simply don't think it'll
> > have any effect on usage of /dev/kvm inside containers
> > 
> 
> Does that mean you assume my scenario I outlined is incorrect? The
> only reason we are having this discussion is because i found that
> changing the permissions of /dev/kvm on the host from 600 to 666 made
> it so that I could run libvirt inside a container, which would mean
> that if does have an effect on usage of /dev/kvm inside a container.

Oh, wait I think I see - you don't have qemu installed in the host
at all - you only installed it inside a docker image, but docker
is just copying the host permissions, and thus see the default
permissions from the kernel.

> I could be "using it wrong", but would like for you to tell me why
> what I'm doing is invalid.

While Docker copies the permissions from host devices, I don't think
that is something it is nice to rely on. Different operating systems
have different views on what default permissions are. So if you build
a Docker image that relies on the host OS having given /dev/kvm
particular permissions, your Docker image is going to be non-portable.

IOW while moving the udev rule out of the QEMU rpm into the udev RPM
would fix it for future Fedora, your docker image is going to be
unable to reliably run on other OS distros (whether older Fedora or
Debian which has restrictive /dev/kvm by default).

I don't see any way to force docker to give the device different
permissions when using the --device flag to launch a container.
In absence of that the only other option is to use an entrypoint
script to chmod the file when your container starts, but that
requires the container to run privileged which is bad. I think
ideally Docker would provide some way to give explicit permissions
so your container is isolated from decisions OS distros make about
default permissions in the host. 

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

ppisar uploaded libwww-perl-6.24.tar.gz for perl-libwww-perl

[notifications]

433e62b802f770b1d7c46bbe3a3b16c0e4423ded77b04f394a49340da98a97c74f8332ffc29c1bc0765cdc8277a2fe110a371b6b0be0f9e94ed104273ee0a1d1
  libwww-perl-6.24.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-libwww-perl/libwww-perl-6.24.tar.gz/sha512/433e62b802f770b1d7c46bbe3a3b16c0e4423ded77b04f394a49340da98a97c74f8332ffc29c1bc0765cdc8277a2fe110a371b6b0be0f9e94ed104273ee0a1d1/libwww-perl-6.24.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Default permissions on /dev/kvm

[Dusty Mabe]

On 03/15/2017 05:17 AM, Daniel P. Berrange wrote:
> 
> Sure, if udev maintainers are willing to ship the kvm rule by default,
> that's fine with me for reason you suggest. I simply don't think it'll
> have any effect on usage of /dev/kvm inside containers
> 

Does that mean you assume my scenario I outlined is incorrect? The
only reason we are having this discussion is because i found that
changing the permissions of /dev/kvm on the host from 600 to 666 made
it so that I could run libvirt inside a container, which would mean
that if does have an effect on usage of /dev/kvm inside a container.

I could be "using it wrong", but would like for you to tell me why
what I'm doing is invalid.

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

ppisar changed jplesnik's 'commit' permission on perl-IO-Pager (master) to 'Approved'

[notifications]

ppisar changed jplesnik's 'commit' permission on perl-IO-Pager (master) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-IO-Pager/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed perl-sig's 'watchcommits' permission on perl-IO-Pager (master) to 'Approved'

[notifications]

ppisar changed perl-sig's 'watchcommits' permission on perl-IO-Pager (master) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-IO-Pager/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed jplesnik's 'approveacls' permission on perl-IO-Pager (master) to 'Approved'

[notifications]

ppisar changed jplesnik's 'approveacls' permission on perl-IO-Pager (master) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-IO-Pager/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed perl-sig's 'watchbugzilla' permission on perl-IO-Pager (master) to 'Approved'

[notifications]

ppisar changed perl-sig's 'watchbugzilla' permission on perl-IO-Pager (master) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-IO-Pager/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed perl-sig's 'watchcommits' permission on perl-Config-INI-Reader-Ordered (master) to 'Approved'

[notifications]

ppisar changed perl-sig's 'watchcommits' permission on 
perl-Config-INI-Reader-Ordered (master) to 'Approved'

https://admin.fedoraproject.org/pkgdb/package/perl-Config-INI-Reader-Ordered/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed perl-sig's 'watchbugzilla' permission on perl-Config-INI-Reader-Ordered (master) to 'Approved'

[notifications]

ppisar changed perl-sig's 'watchbugzilla' permission on 
perl-Config-INI-Reader-Ordered (master) to 'Approved'

https://admin.fedoraproject.org/pkgdb/package/perl-Config-INI-Reader-Ordered/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed jplesnik's 'commit' permission on perl-Config-INI-Reader-Ordered (master) to 'Approved'

[notifications]

ppisar changed jplesnik's 'commit' permission on perl-Config-INI-Reader-Ordered 
(master) to 'Approved'

https://admin.fedoraproject.org/pkgdb/package/perl-Config-INI-Reader-Ordered/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed jplesnik's 'approveacls' permission on perl-Config-INI-Reader-Ordered (master) to 'Approved'

[notifications]

ppisar changed jplesnik's 'approveacls' permission on 
perl-Config-INI-Reader-Ordered (master) to 'Approved'

https://admin.fedoraproject.org/pkgdb/package/perl-Config-INI-Reader-Ordered/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed jplesnik's 'approveacls' permission on perl-Devel-OverrideGlobalRequire (master) to 'Approved'

[notifications]

ppisar changed jplesnik's 'approveacls' permission on 
perl-Devel-OverrideGlobalRequire (master) to 'Approved'

https://admin.fedoraproject.org/pkgdb/package/perl-Devel-OverrideGlobalRequire/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed perl-sig's 'watchbugzilla' permission on perl-Devel-OverrideGlobalRequire (master) to 'Approved'

[notifications]

ppisar changed perl-sig's 'watchbugzilla' permission on 
perl-Devel-OverrideGlobalRequire (master) to 'Approved'

https://admin.fedoraproject.org/pkgdb/package/perl-Devel-OverrideGlobalRequire/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed jplesnik's 'commit' permission on perl-Devel-OverrideGlobalRequire (master) to 'Approved'

[notifications]

ppisar changed jplesnik's 'commit' permission on 
perl-Devel-OverrideGlobalRequire (master) to 'Approved'

https://admin.fedoraproject.org/pkgdb/package/perl-Devel-OverrideGlobalRequire/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed perl-sig's 'watchcommits' permission on perl-Devel-OverrideGlobalRequire (master) to 'Approved'

[notifications]

ppisar changed perl-sig's 'watchcommits' permission on 
perl-Devel-OverrideGlobalRequire (master) to 'Approved'

https://admin.fedoraproject.org/pkgdb/package/perl-Devel-OverrideGlobalRequire/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[EPEL-devel] npm man pages in nodejs package

[Nicholas Humfrey]

Hi,

I was not sure if this is deliberate or not, so I thought I would send 
it in

here first.

In EPEL 7, npm has been split out of nodejs into its own RPM.


$ rpm -qf /usr/bin/node
nodejs-6.9.4-2.el7.x86_64
$ rpm -qf /usr/bin/npm
npm-3.10.10-1.6.9.4.2.el7.x86_64


But it looks like all the man pages are still in the nodejs RPM:

$ rpm -ql nodejs
/usr/bin/node
...
/usr/share/man/man1/npm-README.1.gz
/usr/share/man/man1/npm-access.1.gz
/usr/share/man/man1/npm-adduser.1.gz
/usr/share/man/man1/npm-bin.1.gz
/usr/share/man/man1/npm-bugs.1.gz
/usr/share/man/man1/npm-build.1.gz
...

Is this intensional, or should I raise a bug?


Thanks,

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

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

[Tomasz Kłoczko]

On 14 March 2017 at 20:15, Richard W.M. Jones  wrote:

> These are very useful for building embedded systems, initramfses,
> static linked binaries of large proprietary programs, and any case
> where you don't want to depend on the system libraries.
>

There are still none of the real embedded systems distributions which are
using statically linked binaries lined with glibc libraries.
Fedora is not for embedded systems and using it on even small systems lie
tv box (with +.5GB RAM) binaries with statically linked glibc will be waste
of memory as already some other running processes will be using shared
glibc libraries.
In such use cases it will be better to link such binaries against uClibc or
link some custom binary in busybox tree (both are part of the Fedora).
Those packages does not provides shared libc ABI .. only static libc.a

Glibc libc code as general libs simple is so bloated that using it on
embedded systems as regular libc is pointless (and still is very hard even
with constantly growing system memory of such systems). This is why
projects like OpenWRT/Lede and other are not using glibc.
Reality is that glibc provides some functions which are really hard to find
even single binary which are using them.

You can easily chop probably half of the glibc libc binary and 99.99% of
whole Fedora distribution binaries will be working. Good that each library
is not loaded as whole object into memory (paging) and only by this it does
not hurts to much (hever whole library public symbols jump table must be
fully initialized and loaded into memory so it is some noticeable cost of
it ..).

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

Re: Static libraries in Fedora distribution

[Florian Weimer]

On 03/15/2017 02:51 PM, Tomasz Kłoczko wrote:

So you want to say that RH already guarantees Linux ABI compatibility below
glibc? I would be really surprised if it would be truth .. and I'm 100%
sure that exactly this part is not in RH support small prints. In other
words you may have only impression that this part is already covered in
support conditions.


A statically linked libc isn't much different from a dynamically linked 
libc in a container.  Both rely on stable kernel interfaces.  Same for 
alternative toolchains not based on GNU.


The main problem with static linking in Fedora is that we do not rebuild 
all static libraries once we update glibc-static.  glibc only provides 
ABI compatibility for dynamic linking.  The only saving grace is that we 
gradually cut back on the use of compatibility symbols to make header 
file changes, so incompatible changes have been quite rare for a while.


This isn't really glibc-specific, though, it probably applies to other 
static libraries, too.  The impact of changes to glibc-static are just 
more visible.



Again try to answer on question why long time ago other OSes abandoned
providing static libc?


I think those other operating systems simply do not expose internal 
development tools externally.  They still use static linking in some places.


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

Re: systemd-coredump-python

[Zbigniew Jędrzejewski-Szmek]

On Wed, Mar 15, 2017 at 01:39:48PM +0100, Miroslav Suchý wrote:
> Dne 15.3.2017 v 04:14 Zbigniew Jędrzejewski-Szmek napsal(a):
> > This conflict should be temporary, the patch to make the abrt
> > handler non-exclusive should be trivial.)
> 
> Patches are welcome.

It's on my todo list ;)

> > 4. run a python script that throws an exception
> >e.g. python3 
> > /usr/lib/python3.5/site-packages/systemd_coredump_exception_handler.py,
> >this should print a traceback to stdout
> 
> Commands:
> will_python_raise
> will_python3_raise
> will_python_sigsegv

Ah, cool, a very nice set of commands ;)

$ coredumpctl --since today
TIMEPID   UID   GID SIG COREFILE  EXE
Wed 2017-03-15 10:09:35 EDT3270  1000  1000   - - /usr/bin/python3.5
Wed 2017-03-15 10:10:37 EDT3362  1000  1000   - - /usr/bin/python2.7
Wed 2017-03-15 10:12:25 EDT3514  1000  1000  11 present   /usr/bin/python2.7

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

Re: Wrongly handled LLVM update [Fwd: [Fedora Update] [CRITPATH] [comment] llvm-3.9.1-1.fc25]

[Zbigniew Jędrzejewski-Szmek]

On Wed, Mar 15, 2017 at 01:47:18PM +0100, Kevin Kofler wrote:
> Igor Gnatenko wrote:
> > Why it got pushed to stable?
> 
> Because the maintainer enabled autokarma, which is always a mistake.
> 
> Updates should only ever be pushed after carefully considering the feedback 
> inside and outside Bodhi, including the actual text of the comments, which 
> the Bodhi software cannot fathom. Allowing a push to happen based only on 
> the numeric score is always a mistake.
> 
> The decision when to push an update to stable should be made by a human. And 
> the maintainer can only make that decision after the feedback actually 
> arrived, it cannot be done in advance by setting some karma thresholds.

I don't think this can be the case. It says "Autopush Disabled",
and IIRC recent bodhi updates disable autopush after a single negative karma.

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

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

[Tomasz Kłoczko]

On 15 March 2017 at 00:05, Jonathan Wakely 
wrote:

> If glibc-static was removed from Fedora and that change propagated to
> RHEL I know of companies that might stop being customers of Red Hat.
>
> Being unable to statically link their applications would be a
> showstopper for some, and would cause them to move to a different
> distro.
>

So you want to say that RH already guarantees Linux ABI compatibility below
glibc? I would be really surprised if it would be truth .. and I'm 100%
sure that exactly this part is not in RH support small prints. In other
words you may have only impression that this part is already covered in
support conditions.

Again try to answer on question why long time ago other OSes abandoned
providing static libc?
Internally this part is and always will be affected by definition by any
future changes in kernel ABI. glibc it is not only libc library. Glibc
provides couple of other components which are using internal glibc ABI/API.
Shared libc wraps all those changes and allows handle (in long term) even
quite significant changes beneath own glibc public API/ABI and on boundary
between kernel<->user space without hurting user space binaries.

And one more clarification: remove static libraries from glibc distro
packages does not blocks static linking.
It will only removes possibility linking against static glibc libraries.

Remove static libc it is not new idea. It is +20 years around and none of
the Solaris users moved away from this OS by this reason.
No .. it is completely opposite situation. Because OS like Solaris does not
provides libc.a still even on latest Solaris is possible execute and use
more than decade old binaries.

Linux kernel ABI is changing constantly and flexibility on boundary between
kernel and userspace is covered in Linux kernel documentation *literally*.
>From Documentation/ABI/README:

stable/
This directory documents the interfaces that the developer has
defined to be stable.  Userspace programs are free to use these
interfaces with no restrictions, and backward compatibility for
them will be *guaranteed for at least 2 years*.  Most interfaces
(like syscalls) are expected to never change and always be
available.


Possibility of future changes between kernel and user space was even one of
the fundamental reasons why libc was developed looog time ago before Linus
started thinking about porting Minix to i386.

You can ignore me but you cannot ignore facts behind why something like
libc exist and why no one should use static version of the libc libraries.

Especially static linking with glibc is very dangerous as long if linked
binary is using NSS libc interface. Some people are thinking that "fully"
statically linked program does not use or will not need any DSOs. In case
of using by such binary NSS libc interface this not true as depends on NSS
map type and NSS settings (described in /etc/nsswitch.conf) will be causing
loading nss_.so DSOs.
Number of changes in glibc in internal NSS interface where quite big in
recent years, and if someone will/is using statically linked binary where
NSS interface is in use such binary will be loading NSS modules (probably)
compiled against not correct glibc.Result: execution of such binaries will
fail or even crash with SIGSEV.
This scenario is covered literally as well in glibc documentation:
https://sourceware.org/glibc/wiki/FAQ#Even_statically_linked_programs_need_some_shared_libraries_which_is_not_acceptable_for_me.__What_can_I_do.3F

It is already known that within next few years NSS area in glibc it will be
probably one of the fastest changing area in glibc whole project. Solaris
already coverers in his own libc many NSS security related extensions.
Glibc has a lot to catch up here. All those upcoming changes will
definitely even harder kick back all people linking own executables against
glibc static libraries. This will be probably even bigger problem than all
potential kernel<->user space ABI changes.

Other static libraries used by distribution are carrying as well real and
potential security risk.
Example: RH/Fedora is using bash which is linked against own copy of
readline (provided within bash original source tree). It was few CVEs in
readline in recent years and some people been exploiting fact that bash
was/is linked against readline with well known security issue.
So here is surprise: in case finding new 0-day bug(s) in readline it will
be necessary to provide not one readline fixed package but two .. readline
and bash.

Yes. RH/Fedora bash has some *very well known security flaw* which hanging
above whole distro reputation like a Damocles sword!!!
In last 20 years I've been trying to convince few people to remove exactly
this bash risk but last time when I've been trying this my English was not
good enough to express this enough clear and strong. Maybe this time ..

Reality is that remove building and providing all of those +190 

[Bug 1427462] Please package perl-GD-SecurityImage for CentOS 7

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-GD-SecurityImage-1.72-
   ||1.el7
 Resolution|--- |ERRATA
Last Closed||2017-03-15 09:48:28



--- Comment #4 from Fedora Update System  ---
perl-GD-SecurityImage-1.72-1.el7 has been pushed to the Fedora EPEL 7 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

Re: systemd-coredump-python

[Bastien Nocera]

- Original Message -
> There's a new tiny package which provides a python traceback logging in
> the journal for python processes. It's very similar to the existing
> handler provided by abrt, it also installs itself as sys.excepthook
> using a .pth file, but instead of communicating with abrt, it talks to
> systemd-coredump directly.

If it's an upstream feature, could you please update:
https://bugs.freedesktop.org/show_bug.cgi?id=82507
?

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

Re: Wrongly handled LLVM update [Fwd: [Fedora Update] [CRITPATH] [comment] llvm-3.9.1-1.fc25]

[Kevin Kofler]

Igor Gnatenko wrote:
> Why it got pushed to stable?

Because the maintainer enabled autokarma, which is always a mistake.

Updates should only ever be pushed after carefully considering the feedback 
inside and outside Bodhi, including the actual text of the comments, which 
the Bodhi software cannot fathom. Allowing a push to happen based only on 
the numeric score is always a mistake.

The decision when to push an update to stable should be made by a human. And 
the maintainer can only make that decision after the feedback actually 
arrived, it cannot be done in advance by setting some karma thresholds.

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

limb changed perl-sig's 'commit' permission on perl-Mail-Transport (f25) to 'Approved'

[notifications]

limb changed perl-sig's 'commit' permission on perl-Mail-Transport (f25) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-Transport/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed spot's 'approveacls' permission on perl-Mail-Transport (f25) to 'Approved'

[notifications]

limb changed spot's 'approveacls' permission on perl-Mail-Transport (f25) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-Transport/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: systemd-coredump-python

[Miroslav Suchý]

Dne 15.3.2017 v 04:14 Zbigniew Jędrzejewski-Szmek napsal(a):
> This conflict should be temporary, the patch to make the abrt
> handler non-exclusive should be trivial.)

Patches are welcome.

> 4. run a python script that throws an exception
>e.g. python3 
> /usr/lib/python3.5/site-packages/systemd_coredump_exception_handler.py,
>this should print a traceback to stdout

Commands:
will_python_raise
will_python3_raise
will_python_sigsegv

from package will-crash are probably more comfortable

-- 
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

limb changed perl-sig's 'watchcommits' permission on perl-Mail-Transport (f24) to 'Approved'

[notifications]

limb changed perl-sig's 'watchcommits' permission on perl-Mail-Transport (f24) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-Transport/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed spot's 'watchbugzilla' permission on perl-Mail-Transport (f24) to 'Approved'

[notifications]

limb changed spot's 'watchbugzilla' permission on perl-Mail-Transport (f24) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-Transport/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed spot's package request for perl-Mail-Transport in f24 from Awaiting Review to Approved

[notifications]

limb changed spot's package request for perl-Mail-Transport in f24 from 
Awaiting Review to Approved
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-Transport/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed perl-sig's 'watchbugzilla' permission on perl-Mail-Transport (f24) to 'Approved'

[notifications]

limb changed perl-sig's 'watchbugzilla' permission on perl-Mail-Transport (f24) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-Transport/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed spot's 'approveacls' permission on perl-Mail-Transport (f24) to 'Approved'

[notifications]

limb changed spot's 'approveacls' permission on perl-Mail-Transport (f24) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-Transport/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed perl-sig's 'commit' permission on perl-Mail-Transport (f24) to 'Approved'

[notifications]

limb changed perl-sig's 'commit' permission on perl-Mail-Transport (f24) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-Transport/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed spot's 'watchcommits' permission on perl-Mail-Transport (f24) to 'Approved'

[notifications]

limb changed spot's 'watchcommits' permission on perl-Mail-Transport (f24) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-Transport/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed spot's 'commit' permission on perl-Mail-Transport (f26) to 'Approved'

[notifications]

limb changed spot's 'commit' permission on perl-Mail-Transport (f26) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-Transport/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed perl-sig's 'watchbugzilla' permission on perl-Mail-Transport (f25) to 'Approved'

[notifications]

limb changed perl-sig's 'watchbugzilla' permission on perl-Mail-Transport (f25) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-Transport/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed perl-sig's 'watchcommits' permission on perl-Mail-Transport (f26) to 'Approved'

[notifications]

limb changed perl-sig's 'watchcommits' permission on perl-Mail-Transport (f26) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-Transport/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed spot's 'watchcommits' permission on perl-Mail-Transport (f25) to 'Approved'

[notifications]

limb changed spot's 'watchcommits' permission on perl-Mail-Transport (f25) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-Transport/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed spot's 'commit' permission on perl-Mail-Transport (f24) to 'Approved'

[notifications]

limb changed spot's 'commit' permission on perl-Mail-Transport (f24) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-Transport/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb created the branch 'f25' for the package 'perl-Mail-Transport'

[notifications]

limb created the branch 'f25' for the package 'perl-Mail-Transport'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-Transport/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb created the branch 'f24' for the package 'perl-Mail-Transport'

[notifications]

limb created the branch 'f24' for the package 'perl-Mail-Transport'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-Transport/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed perl-sig's 'watchcommits' permission on perl-Mail-Transport (f25) to 'Approved'

[notifications]

limb changed perl-sig's 'watchcommits' permission on perl-Mail-Transport (f25) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-Transport/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed spot's package request for perl-Mail-Transport in f26 from Awaiting Review to Approved

[notifications]

limb changed spot's package request for perl-Mail-Transport in f26 from 
Awaiting Review to Approved
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-Transport/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed spot's 'commit' permission on perl-Mail-Transport (f25) to 'Approved'

[notifications]

limb changed spot's 'commit' permission on perl-Mail-Transport (f25) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-Transport/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed perl-sig's 'watchbugzilla' permission on perl-Mail-Transport (f26) to 'Approved'

[notifications]

limb changed perl-sig's 'watchbugzilla' permission on perl-Mail-Transport (f26) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-Transport/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed spot's package request for perl-Mail-Transport in f25 from Awaiting Review to Approved

[notifications]

limb changed spot's package request for perl-Mail-Transport in f25 from 
Awaiting Review to Approved
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-Transport/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed spot's 'approveacls' permission on perl-Mail-Transport (f26) to 'Approved'

[notifications]

limb changed spot's 'approveacls' permission on perl-Mail-Transport (f26) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-Transport/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed perl-sig's 'commit' permission on perl-Mail-Transport (f26) to 'Approved'

[notifications]

limb changed perl-sig's 'commit' permission on perl-Mail-Transport (f26) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-Transport/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb created the branch 'f26' for the package 'perl-Mail-Transport'

[notifications]

limb created the branch 'f26' for the package 'perl-Mail-Transport'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-Transport/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed spot's 'watchbugzilla' permission on perl-Mail-Transport (f26) to 'Approved'

[notifications]

limb changed spot's 'watchbugzilla' permission on perl-Mail-Transport (f26) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-Transport/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed spot's 'watchbugzilla' permission on perl-Mail-Transport (f25) to 'Approved'

[notifications]

limb changed spot's 'watchbugzilla' permission on perl-Mail-Transport (f25) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-Transport/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed perl-sig's 'watchcommits' permission on perl-Mail-Transport (master) to 'Approved'

[notifications]

limb changed perl-sig's 'watchcommits' permission on perl-Mail-Transport 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-Transport/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed spot's 'watchcommits' permission on perl-Mail-Transport (f26) to 'Approved'

[notifications]

limb changed spot's 'watchcommits' permission on perl-Mail-Transport (f26) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-Transport/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed spot's package request for perl-Mail-Transport in master from Awaiting Review to Approved

[notifications]

limb changed spot's package request for perl-Mail-Transport in master from 
Awaiting Review to Approved
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-Transport/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed spot's 'approveacls' permission on perl-Mail-Transport (master) to 'Approved'

[notifications]

limb changed spot's 'approveacls' permission on perl-Mail-Transport (master) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-Transport/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed perl-sig's 'watchbugzilla' permission on perl-Mail-Transport (master) to 'Approved'

[notifications]

limb changed perl-sig's 'watchbugzilla' permission on perl-Mail-Transport 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-Transport/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed perl-sig's 'commit' permission on perl-Mail-Transport (master) to 'Approved'

[notifications]

limb changed perl-sig's 'commit' permission on perl-Mail-Transport (master) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-Transport/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed spot's 'watchcommits' permission on perl-Mail-Transport (master) to 'Approved'

[notifications]

limb changed spot's 'watchcommits' permission on perl-Mail-Transport (master) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-Transport/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1432446] New: perl-Mojolicious-7.29 is available

[bugzilla]

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

Bug ID: 1432446
   Summary: perl-Mojolicious-7.29 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Mojolicious
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr,
perl-devel@lists.fedoraproject.org,
robinlee.s...@gmail.com



Latest upstream release: 7.29
Current version/release in rawhide: 7.28-1.fc27
URL: http://mojolicio.us/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/5966/

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

Upgrade of lv2 audio plugin system related packages in rawhide

[Guido Aulisi]

Hi,
I'm upgrading some LV2 audio plugin system related packages in rawhide.
The packages are:

lv2
serd
sord
sratom
lilv
suil

I'm not using a build tag, so the entire work will last some days.
Any packages that depend on these should rebuild after this update
ends.

There are no soname bumps, so old packages should work fine, but you
could get enhancements if dependent packages use #ifdef in the source
(like Ardour).

A list of possible affected packages:

lv2-abGate
lv2-amsynth-plugin
lv2-artyfx-plugins
lv2-avw-plugins
lv2-calf-plugins
lv2-devel
lv2-drumkv1
lv2-EQ10Q-plugins
lv2-fabla
lv2-fomp-plugins
lv2-guitarix-plugins
lv2-invada-plugins
lv2-ir-plugins
lv2-kn0ck0ut
lv2-ll-plugins
lv2-mdaEPiano
lv2-mdala-plugins
lv2-newtonator
lv2-samplv1
lv2-setBfree-plugins
lv2-sorcer
lv2-swh-plugins
lv2-synthv1
lv2-triceratops
lv2-vocoder-plugins
lv2-x42-plugins
lv2-zynadd-plugins

ardour2
ardour4
ardour4-audiobackend-alsa
ardour4-audiobackend-dummy
ardour4-audiobackend-jack
ardour5
ardour5-audiobackend-alsa
ardour5-audiobackend-dummy
ardour5-audiobackend-jack
guitarix
jalv
jalv-gtk
jalv-gtkmm
jalv-qt
ladspa-guitarix-plugins
lcd4linux
muse
qtractor
serdisplib-devel
serdisplib-tools
sonic-visualiser

Thanks
Guido Aulisi (fas account name: tartina)

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

Re: Default permissions on /dev/kvm

[Daniel J Walsh]

On 03/15/2017 05:27 AM, Daniel P. Berrange wrote:
> On Tue, Mar 14, 2017 at 05:35:54PM -0400, Daniel J Walsh wrote:
>>
>> On 03/14/2017 05:18 PM, Dusty Mabe wrote:
>>> On 03/14/2017 05:15 PM, Daniel J Walsh wrote:
 On 03/14/2017 05:02 PM, Dusty Mabe wrote:
> On 03/14/2017 04:56 PM, Daniel J Walsh wrote:
>> On 03/14/2017 04:29 PM, Daniel P. Berrange wrote:
>> I guess if you volume/bind mount the device into the container you could
>> see an issue,
>> but most containers that deal with /dev/kvm are going to be run as root,
>> anyways.
> I was running with --privileged, still got permission denied until I
> changed permissions of /dev/kvm to 666.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
 # docker run -ti --device /dev/kvm fedora ls -lZ /dev/kvm
 crw-rw-rw-. 1 root 36 system_u:object_r:container_file_t:s0:c303,c737 10, 
 232 Mar 14 21:12 /dev/kvm
 # chmod 600 /dev/kvm 
 # docker run -ti --device /dev/kvm fedora ls -lZ /dev/kvm 
 crw---. 1 root 36 system_u:object_r:container_file_t:s0:c281,c442 10, 
 232 Mar 14 21:13 /dev/kvm

 So using --device to add the device to the container just maintains the 
 permission of the host
 for the device you added.  Whether it is volume mounted in or specified 
 via --device, at least
 from dockers point of view. 
>>> I'm not sure of your point. I was just trying to say that whether i
>>> was root or not did not seem to matter. I still got permission denied
>>> if perms were 600 and not 666. I'm working off of memory here, so it's
>>> possible somebody will prove me wrong.
>> Most likely libvirt or whoever is launching the containers is not running
>> as root, so it is being blocked access.
> It is simpler than that. When you ask libvirt to assign a device to a
> container it will simply mknod() in the container's private /dev, with
> permissions 0700. If the container needs to make that available to
> mon-privileged users inside the container, its "init" has to arrange
> to set permissions further.
>
> For Docker, I'm unclear whether it is also just doing a mknod in the
> container's /dev, or whether it is bind mounting the host device node.
> Either way, udev isn't involved inside the container.
>
> Regards,
> Daniel
My point was that docker is just matching the permissions from the host.

In the case of using docker run --device /dev/kvm
It is creating a different device


#ls -i /dev/kvm

18835 /dev/kvm

# docker run -ti --device /dev/kvm fedora sh

# ls -lZ /dev/kvm 
crw---. 1 root 36 system_u:object_r:container_file_t:s0:c516,c728 10, 232 
Mar 15 11:44 /dev/kvm
# ls -i /dev/kvm 
669570 /dev/kvm

If I chmod 666 outside of the container the mode of the container is still 600, 
so they are different devices.


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

Re: Voice recognition packages need a new maintainer

[Peter Robinson]

On Wed, Mar 15, 2017 at 4:59 AM, Jerry James  wrote:
> On Tue, Mar 14, 2017 at 5:27 AM, Peter Robinson  wrote:
>> You can assign pocketsphinx and it's dep sphinxbase to me as I need
>> them for a project I'm investigating ATM.
>
> Packagedb is claiming that you are not in the packager group, from

Oh I'm there alright:
https://admin.fedoraproject.org/pkgdb/packager/pbrobinson/

> which I conclude that one of the following is true:
> - the FAS account name given here is not correct:
> https://fedoraproject.org/wiki/User:Pbrobinson
> - packagedb is currently experiencing issues retrieving information from FAS
> - I am really, really tired from the stupid time change and have done
> something idiotic while trying to give these packages to you
>
> I'll be really interested to find out which of those is the case.
> --
> Jerry James
> http://www.jamezone.org/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1432280] perl-XML-LibXML-2.0129 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-XML-LibXML-2.0129-1.fc25 has been submitted as an update to Fedora 25.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-676d2d0134

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

jplesnik pushed to perl-XML-LibXML (f25). "2.0129 bump"

[notifications]

From c7b6e3659cd8ad22923613167163acc2400307c6 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Wed, 15 Mar 2017 10:28:49 +0100
Subject: 2.0129 bump

---
 .gitignore   | 1 +
 perl-XML-LibXML.spec | 5 -
 sources  | 2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index b3ef767..ff308ad 100644
--- a/.gitignore
+++ b/.gitignore
@@ -45,3 +45,4 @@ XML-LibXML-1.70.tar.gz
 /XML-LibXML-2.0125.tar.gz
 /XML-LibXML-2.0126.tar.gz
 /XML-LibXML-2.0128.tar.gz
+/XML-LibXML-2.0129.tar.gz
diff --git a/perl-XML-LibXML.spec b/perl-XML-LibXML.spec
index ba7e69f..127baf4 100644
--- a/perl-XML-LibXML.spec
+++ b/perl-XML-LibXML.spec
@@ -7,7 +7,7 @@ Name:   perl-XML-LibXML
 # https://bugzilla.redhat.com/show_bug.cgi?id=469480
 # it might not be needed anymore
 # this module is maintained, the other is not
-Version:2.0128
+Version:2.0129
 Release:1%{?dist}
 Epoch:  1
 Summary:Perl interface to the libxml2 library
@@ -136,6 +136,9 @@ fi
 %{_mandir}/man3/*.3*
 
 %changelog
+* Wed Mar 15 2017 Jitka Plesnikova  - 1:2.0129-1
+- 2.0129 bump
+
 * Mon Jul 25 2016 Jitka Plesnikova  - 1:2.0128-1
 - 2.0128 bump
 
diff --git a/sources b/sources
index 9aaf60f..2a24323 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-9904690371679e082ff2c23677b6c90e  XML-LibXML-2.0128.tar.gz
+SHA512 (XML-LibXML-2.0129.tar.gz) = 
f17c61052975ecc188c285ee93dbb07926c880a28e49afdd5af0c7c997e8b12be72412d0964391f1232f853935ee0ff2838cd5d62f8f3b4f52c341904069ccea
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-XML-LibXML.git/commit/?h=f25=c7b6e3659cd8ad22923613167163acc2400307c6
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org