Re: bodhi: no email notifications for packages in pending state

[Kevin Fenzi]

On Tue, 6 Oct 2015 01:06:43 +0300
Alexander Ploumistos  wrote:

> Is RHBZ linked to FMN? I've been trying to set up a filter for all the
> bugs that concern me, but I can't get any example messages, even when
> I just select the "All RHBZ activity" rule.

It's not... yet. ;) 

Hopefully it will be someday soon. The bugzilla folks have (rightly,
IMHO) been concentrating on making things faster and more robust before
working on things like message bus integration. 

kevin


pgp0jouQc_9Oc.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: scriplet issues installing deps in f23 mock

[Cole Robinson]

On 10/05/2015 04:46 AM, Miroslav Suchý wrote:
> Dne 30.9.2015 v 00:17 Cole Robinson napsal(a):
>> I'm hitting scriplet errors when trying to build f23 qemu in mock on an up to
>> date f23 host. Example:
>>
>> $ mock --root fedora-23-x86_64 --init
>> ...
>> $ mock --root fedora-23-x86_64 --rebuild qemu-2.4.0-4.fc23.src.rpm
>> ...
>>
>> Transaction Summary
>> 
>> Install  48 Packages (+596 Dependent packages)
>>
>> Total size: 396 M
>> Installed size: 1.1 G
>> Downloading packages:
>> Running transaction check
>> Running transaction test
>> Transaction test succeeded
>> Running transaction (shutdown inhibited)
>> error: %prein(texlive-base-4:2014-13.20140525_r34255.fc23.noarch) scriptlet
>> failed, exit status 126
>> Error in PREIN scriptlet in rpm package
>> 4:texlive-base-2014-13.20140525_r34255.fc23.noarch
>>   Installing : 2:libpng-1.6.17-2.fc23.x86_64  
>> 2/644
>> error: texlive-base-4:2014-13.20140525_r34255.fc23.noarch: install failed
>> warning: %post(libpng-2:1.6.17-2.fc23.x86_64) scriptlet failed, exit status 
>> 126
>> Non-fatal POSTIN scriptlet failure in rpm package 
>> 2:libpng-1.6.17-2.fc23.x86_64
>>   Installing : freetype-2.6.0-3.fc23.x86_64   
>> 3/644
>> warning: %post(freetype-2.6.0-3.fc23.x86_64) scriptlet failed, exit status 
>> 126
>> Non-fatal POSTIN scriptlet failure in rpm package 
>> freetype-2.6.0-3.fc23.x86_64
>>   Installing : xorg-x11-proto-devel-7.7-16.fc23.noarch
> 
> 
> libpng just call ldconfig
> texlive-base just remove one directory and return true
> There is hardly something to fail.
> 
> I strongly suspect SELinux. It does not happen on my workstation (with 
> SELinux disabled) and it does not happen on
> freshly installed F22 machine with SELinux on.
> 
> Do you have something in audit.log?
> 
> 

My machine has had selinux=permissive the entire time. No AVCs in audit.log
anyways.

Also another data point: qemu 'fedpkg mockbuild' reproduces this issue in a
fresh f23 VM install as well.

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

Re: bodhi: no email notifications for packages in pending state

[Alexander Ploumistos]

Is RHBZ linked to FMN? I've been trying to set up a filter for all the
bugs that concern me, but I can't get any example messages, even when
I just select the "All RHBZ activity" rule.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Upgrade path question

[Sandro Mani]

Hi

Quick upgrade path question: I intend to retire the tesseract-langpack 
package, which provides many tesseract-langpack-$lang subpackages, and 
instead have the main tesseract package to provide these, with the same 
name. The version of the tesseract-langpack-$lang subpackages increases 
in the process.


Is my understanding right that it is not necessary for the new 
tesseract-lanpack-$lang packages to obsolete the old ones?


Thanks
Sandro

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

Re: Removing packages that have broken dependencies in F23 tree, v2

[Till Maas]

Hi,

On Mon, Oct 05, 2015 at 04:16:57PM -0400, Omair Majid wrote:
> * Kalev Lember  [2015-10-05 09:02]:
> > Here's another look at F23 broken dependencies.
> >
> > Based on today's Branched report [1], the following packages have
> > remaining broken dependencies (package maintainers BCC'd to this email):
> > 
> >Package(co)maintainers
> > 
> > netbeans-platform moceap, dbhole, omajid
> 
> The list of maintainers doesn't look right. I have no commit access to
> this package for F23 (or Rawhide) [1]. I am being BCC'ed when I can't do
> anything :(

you can do enough: you can write a patch and send it here or ask for
maintainership/commit access.

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

Re: Removing packages that have broken dependencies in F23 tree, v2

[Omair Majid]

* Kalev Lember  [2015-10-05 09:02]:
> Here's another look at F23 broken dependencies.
>
> Based on today's Branched report [1], the following packages have
> remaining broken dependencies (package maintainers BCC'd to this email):
> 
>Package(co)maintainers
> 
> netbeans-platform moceap, dbhole, omajid

The list of maintainers doesn't look right. I have no commit access to
this package for F23 (or Rawhide) [1]. I am being BCC'ed when I can't do
anything :(

Thanks,
Omair

[1] https://admin.fedoraproject.org/pkgdb/package/netbeans-platform/

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Removing packages that have broken dependencies in F23 tree, v2

[Kalev Lember]

On 10/05/2015 05:46 PM, Vít Ondruch wrote:
> Dne 5.10.2015 v 17:35 Kalev Lember napsal(a):
>> On 10/05/2015 04:52 PM, Martin Gansser wrote:
>>> Hi Kalev,
>>>
>>>  
>>>
>>> i am the packager of the package vdr-live  (martinkg).
>>>
>>>  
>>>
>>> vdr-live has broken dependencies in the F-23 tree:
>>> On x86_64:
>>> vdr-live-0.3.0-21.20150213git6ea279a.fc23.x86_64 requires
>>> libtntnet.so.12()(64bit)
>>> vdr-live-0.3.0-21.20150213git6ea279a.fc23.x86_64 requires
>>> libcxxtools.so.9()(64bit)
>>> On i386:
>>> vdr-live-0.3.0-21.20150213git6ea279a.fc23.i686 requires libtntnet.so.12
>>> vdr-live-0.3.0-21.20150213git6ea279a.fc23.i686 requires libcxxtools.so.9
>>> On armhfp:
>>> vdr-live-0.3.0-21.20150213git6ea279a.fc23.armv7hl requires libtntnet.so.12
>>> vdr-live-0.3.0-21.20150213git6ea279a.fc23.armv7hl requires libcxxtools.so.9
>>> Please resolve this as soon as possible.
>>>
>>>  
>>>
>>> vdr-live depends on the 2 packages
>>>
>>> tntnet-2.3rc1-1.fc23
>>> 
>>>
>>> cxxtools-2.3rc1-1.fc23
>>> 
>>>
>>>  
>>>
>>> can you please delete this 2 packages, because there is no vdr-live
>>> package available that compiles against the new tntnet/cxxtools-2.3 version,
>>>
>>> but vdr-live compiles fine against tntnet/cxxtools-2.2.
>> Hi Martin,
>>
>> It's actually self-service if you want to do it yourself before the cut
>> off date:
>>
>> fedpkg retire "Reasons for retirement here"
>>
>> ... and repeat it on both f23 and master branches.
>>
> 
> I don't think he want's to retire the packages, but revert from 2.3rc1
> back to 2.2  this is possible but it will need epoch bump ... but I
> might be wrong in interpretation :)

Ahh yes, right you are. I totally misunderstood the question.

Martin (added you back to CC as you don't seem to be subscribed to the
devel list) -- if you want to avoid retiring vdr-live, epoch bumping
tntnet and cxxtools back to 2.2 sounds about right to me too, especially
given that they only appear to be used by vdr-live.

Bumping the Epoch tag to 1 in a spec file would make rpm consider 2.2
newer than 2.3rc1, so that you can submit the "newer" 1:2.2 as a F23
update that correctly replaces the "older" 0:2.3rc1 build.


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

Re: Proposal to reduce anti-bundling requirements

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/30/2015 08:35 AM, Stephen Gallagher wrote:
> Just to circle around here (in case people don't read my reply to
> the FESCo meeting agenda), I'm making the following revised
> proposal[1] to FESCo which may or may not be discussed at today's
> meeting (given that it was submitted late):
> 

I'm putting up another pass at the proposal, as there were some
critical typographical errors in the last one that caused confusion
(there were a couple places where I wrote "bundled" and meant
"unbundled" and the reverse). This revised version should be clearer.



=== Mandatory ===
* The Fedora Base Working Group has been tasked with defining the base
platform of Fedora since its inception. As part of this proposal, we
set a deadline for them to provide (and maintain) a specific list of
critical path packages. The critical path set is not required to be
self-hosting.
* Working Groups for the separate Editions may voluntarily add
packages into the critical path atop the Base WG requirements.
* All packages in the critical path must obey the current strict
bundling rules. Packages in the critical path that require bundling
must continue to seek exceptions from the Fedora Packaging Committee.
* All packages not in the critical path whose upstreams allow them to
be build against system libraries must be built against system libraries
.
* All packages not in the critical path whose upstreams have no
mechanism to build against system libraries must be contacted publicly
about a path to supporting system libraries. If upstream refuses, this
must be recorded in the spec file using a persistent mechanism to be
clarified in the packaging guidelines.
* All packages not in the critical path whose upstreams have no
mechanism to build against system libraries may opt to carry bundled
libraries, but if they do, they must include Provides:
bundled() =  in their RPM spec file.

=== Strongly Recommended ===
* Packages in the critical path should be re-reviewed every two years
(possibly as a Flock workshop) to avoid unintentional divergence from
the policies.


Note: the term "critical path" is reused from a retired Fedora
packaging concept, but it is *not* representing the same set of
packages. We may need to come up with a more distinct term, but I
can't think of a better choice at this moment. Please avoid repainting
this shed.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlYSuxwACgkQeiVVYja6o6OYKwCdGv3+nISsTPak3N+vavV+Ttvk
BCYAnjNjInimvGRHpZzNJt5ytKhimE8t
=vlK0
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: bodhi: no email notifications for packages in pending state

[Alexander Ploumistos]

On Mon, Oct 5, 2015 at 2:26 PM, Michael Schwendt  wrote:
> You may want to read the last messages from me in this short thread:
>
>   
> https://lists.fedoraproject.org/pipermail/devel/2015-August/thread.html#213311

I had already starred your messages in that thread :)

Figuring out the descriptions has been the hardest part so far.

Oh, and with the two default rules I was notified about a
comment/karma on one of my packages. I'll keep an eye on everything
for now and tweak things along the way.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora 23 Branched 20151005 compose check report

[Fedora compose checker]

No missing expected images.

No images in this compose but not 23 Branched 20151004

No images in 23 Branched 20151004 but not this.

Failed openQA tests: 9 of 52

ID: 4796Test: x86_64 universal server_scsi_updates_img
ID: 4793Test: i386 kde_live default_install
ID: 4792Test: x86_64 workstation_live default_install@uefi
ID: 4790Test: x86_64 kde_live default_install
ID: 4789Test: i386 workstation_live default_install
ID: 4785Test: i386 universal upgrade_desktop_32bit
ID: 4770Test: x86_64 universal server_simple_free_space@uefi
ID: 4768Test: x86_64 universal server_delete_partial@uefi
ID: 4761Test: x86_64 universal upgrade_desktop_64bit

Passed openQA tests: 43 of 52
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Removing packages that have broken dependencies in F23 tree, v2

[Mattias Ellert]

mån 2015-10-05 klockan 14:59 +0200 skrev Kalev Lember:
> Hi all,
> 
> Here's another look at F23 broken dependencies. A number of packages
> have been fixed last week, but there's also a new broken dependency,
> CableSwig, due to gccxml retirement.

There is a replacement for gccxml available called castxml, which does
mostly the same thing. It is however not a drop-in replacement, since
the name of the binary is different and it has different command line
options, so the castxml package (available in Fedora 23 and rawhide)
does not Provide: gccxml.

The castxml binary has a --castxml-gccxml option which creates output
compatible with the old gccxml, so adapting to use castxml should not
be terribly complicated.

Mattias




smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: SPF records @fedoraproject.org versus @lists.fedoraproject.org

[Paul Wouters]

On Mon, 5 Oct 2015, Kevin Fenzi wrote:


On Mon, 5 Oct 2015 11:04:40 -0400
Paul Wouters  wrote:


And openpgpkey-milter :)

And put in a TLSA record for their MX :)


I don't think it makes much sense for Fedora Infrastructure to get into
the business of being a SMTP server provider. Is this something that
would help forward the goals of the Fedora Project? If so, how?


I wasn't refering to Fedora Infrastructure, but to people running fedora
for their mail servers.

That said, if we run MX for fedoraproject.org, we should also do that of
course :)

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

Re: Testing chrony seccomp support

[Andrew Lutomirski]

On Mon, Oct 5, 2015 at 8:25 AM, Michael Catanzaro  wrote:
> On Mon, 2015-10-05 at 07:02 -0700, Andrew Lutomirski wrote:
>> Why is the filter causing SIGSYS instead of forcing an ENOSYS return?
>>
>> I'll look into the abrt thing.  It might be an easy fix.
>>
>> --Andy
>
> Simply because it's an experimental project, and it's much easier to
> crash with a core dump so it can be debugged, than to have obscure
> failures all over the place.

For deployment, though, I think the other approach is better.  If,
say, memfd_create returns ENOSYS, most libraries will fall back to
older mechanisms.

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

Re: SPF records @fedoraproject.org versus @lists.fedoraproject.org

[Reindl Harald]

Am 05.10.2015 um 17:43 schrieb Marcin Juszkiewicz:

W dniu 05.10.2015 o 16:58, Reindl Harald pisze:

Am 05.10.2015 um 16:47 schrieb Marcin Juszkiewicz:



Many of those people send their mail from properly configured MTA
allowing random envelope senders for authenticated users


well, and that's why spamfighting is that complicated
a MTA allowing random sender is *not* properly configured


My MTA has to send my emails. I connect, authenticate and provide emails
to send. I may fetch them from many different servers but send them
through one SMTP server.


RTFM your SMTP servers manual

for such cases our MTA has the SMTP credentials of the sender and uses a 
sender-based relay to *not* blow out forged mail, while that's off-topic 
here: A records without SPF lead to forged mails and more important 
makes it impossible on the RCPT side to distinct between forged and 
legit mail for whitelisting and in general


however, off-topic, for the moment i only care about mass mails from the 
fedora infrastructure which hits BAYES_50 alerts and i don't want to 
train as ham for good reasons




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

Re: Removing packages that have broken dependencies in F23 tree, v2

[Vít Ondruch]

Dne 5.10.2015 v 17:35 Kalev Lember napsal(a):
> On 10/05/2015 04:52 PM, Martin Gansser wrote:
>> Hi Kalev,
>>
>>  
>>
>> i am the packager of the package vdr-live  (martinkg).
>>
>>  
>>
>> vdr-live has broken dependencies in the F-23 tree:
>> On x86_64:
>> vdr-live-0.3.0-21.20150213git6ea279a.fc23.x86_64 requires
>> libtntnet.so.12()(64bit)
>> vdr-live-0.3.0-21.20150213git6ea279a.fc23.x86_64 requires
>> libcxxtools.so.9()(64bit)
>> On i386:
>> vdr-live-0.3.0-21.20150213git6ea279a.fc23.i686 requires libtntnet.so.12
>> vdr-live-0.3.0-21.20150213git6ea279a.fc23.i686 requires libcxxtools.so.9
>> On armhfp:
>> vdr-live-0.3.0-21.20150213git6ea279a.fc23.armv7hl requires libtntnet.so.12
>> vdr-live-0.3.0-21.20150213git6ea279a.fc23.armv7hl requires libcxxtools.so.9
>> Please resolve this as soon as possible.
>>
>>  
>>
>> vdr-live depends on the 2 packages
>>
>> tntnet-2.3rc1-1.fc23
>> 
>>
>> cxxtools-2.3rc1-1.fc23
>> 
>>
>>  
>>
>> can you please delete this 2 packages, because there is no vdr-live
>> package available that compiles against the new tntnet/cxxtools-2.3 version,
>>
>> but vdr-live compiles fine against tntnet/cxxtools-2.2.
> Hi Martin,
>
> It's actually self-service if you want to do it yourself before the cut
> off date:
>
> fedpkg retire "Reasons for retirement here"
>
> ... and repeat it on both f23 and master branches.
>

I don't think he want's to retire the packages, but revert from 2.3rc1
back to 2.2  this is possible but it will need epoch bump ... but I
might be wrong in interpretation :)


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

Re: SPF records @fedoraproject.org versus @lists.fedoraproject.org

[Marcin Juszkiewicz]

W dniu 05.10.2015 o 16:58, Reindl Harald pisze:

Am 05.10.2015 um 16:47 schrieb Marcin Juszkiewicz:



Many of those people send their mail from properly configured MTA
allowing random envelope senders for authenticated users


well, and that's why spamfighting is that complicated
a MTA allowing random sender is *not* properly configured


My MTA has to send my emails. I connect, authenticate and provide emails 
to send. I may fetch them from many different servers but send them 
through one SMTP server.



i guess you don't use random sevrers fro your @redhat.com


My emails from company address go through company MTA because that's 
policy and they can contain confidential information.


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

Re: SPF records @fedoraproject.org versus @lists.fedoraproject.org

[Reindl Harald]

Am 05.10.2015 um 17:12 schrieb Kevin Fenzi:

On Mon, 5 Oct 2015 11:04:40 -0400
Paul Wouters  wrote:


And openpgpkey-milter :)

And put in a TLSA record for their MX :)


I don't think it makes much sense for Fedora Infrastructure to get into
the business of being a SMTP server provider. Is this something that
would help forward the goals of the Fedora Project? If so, how?

Additionally I suspect the admin overhead would be large just answering
"Your smtp server sent me spam" type of noise...


my whole point was that automatic generated mails of infrastructure 
should live in a subdomain with a SPF record to handle them different 
than ordinary mail - a whitelist_auth / shortcircuit message eats no 
ressources ona incoming filter and you don't need bayes-training while 
SPF prevents forging the sender




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

Re: Removing packages that have broken dependencies in F23 tree, v2

[Kalev Lember]

On 10/05/2015 04:52 PM, Martin Gansser wrote:
> Hi Kalev,
> 
>  
> 
> i am the packager of the package vdr-live  (martinkg).
> 
>  
> 
> vdr-live has broken dependencies in the F-23 tree:
> On x86_64:
> vdr-live-0.3.0-21.20150213git6ea279a.fc23.x86_64 requires
> libtntnet.so.12()(64bit)
> vdr-live-0.3.0-21.20150213git6ea279a.fc23.x86_64 requires
> libcxxtools.so.9()(64bit)
> On i386:
> vdr-live-0.3.0-21.20150213git6ea279a.fc23.i686 requires libtntnet.so.12
> vdr-live-0.3.0-21.20150213git6ea279a.fc23.i686 requires libcxxtools.so.9
> On armhfp:
> vdr-live-0.3.0-21.20150213git6ea279a.fc23.armv7hl requires libtntnet.so.12
> vdr-live-0.3.0-21.20150213git6ea279a.fc23.armv7hl requires libcxxtools.so.9
> Please resolve this as soon as possible.
> 
>  
> 
> vdr-live depends on the 2 packages
> 
> tntnet-2.3rc1-1.fc23
> 
> 
> cxxtools-2.3rc1-1.fc23
> 
> 
>  
> 
> can you please delete this 2 packages, because there is no vdr-live
> package available that compiles against the new tntnet/cxxtools-2.3 version,
> 
> but vdr-live compiles fine against tntnet/cxxtools-2.2.

Hi Martin,

It's actually self-service if you want to do it yourself before the cut
off date:

fedpkg retire "Reasons for retirement here"

... and repeat it on both f23 and master branches.

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

Re: bodhi: no email notifications for packages in pending state

[Petr Pisar]

On 2015-10-05, Kevin Fenzi  wrote:
> On Mon, 5 Oct 2015 12:00:27 + (UTC)
> Petr Pisar  wrote:
>> On 2015-10-03, Kevin Fenzi  wrote:
>> > Almost all notifications from bodhi (with the exception currently of
>> > adding comments on updates) is sent via FMN (the Fedora notification
>> > service): https://apps.fedoraproject.org/notifications/
>> >
>> Which event is the "an update can be pushed to stable" from the
>> available filters:
>
> There isn't one, but I think that would be a great one to add.=20
>
> Can you file an issue/ticket on it?
>
.

-- Petr

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

Re: Testing chrony seccomp support

[Michael Catanzaro]

On Mon, 2015-10-05 at 17:27 +0200, Miroslav Lichvar wrote:
> Another possibility is to add a new level to the chrony seccomp
> support that would use a blacklisting approach, disabling syscalls or
> their arguments that historically are most dangerous and we can be
> sure won't be ever needed. I hope that's not an empty set.

Sandstorm and systemd-nspawn have lists like that, if you want to
investigate them... of course, the security benefits are much less, but
it's better than no seccomp and you don't have to worry much about
compatibility issues. No reason for chrony to be using kexec, for
example.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: bodhi: no email notifications for packages in pending state

[Orion Poplawski]

On 10/05/2015 09:21 AM, Kevin Fenzi wrote:
> On Mon, 5 Oct 2015 12:00:27 + (UTC)
> Petr Pisar  wrote:
> 
>> On 2015-10-03, Kevin Fenzi  wrote:
>>> On Sat, 3 Oct 2015 16:46:02 +0300
>>> Alexander Ploumistos  wrote:
 For the last couple of days I have been submitting updates (with
 fedpkg) for some of my packages in all the branches. Currently they
 all appear as pending in bodhi and I have not received any messages
 about them, even for the ones that got positive karma.
>>>
>>> Almost all notifications from bodhi (with the exception currently of
>>> adding comments on updates) is sent via FMN (the Fedora notification
>>> service): https://apps.fedoraproject.org/notifications/
>>>
>> Which event is the "an update can be pushed to stable" from the
>> available filters:
> 
> There isn't one, but I think that would be a great one to add. 
> 
> Can you file an issue/ticket on it?
> 
> kevin
> 
> 
> 

I think there already is a request:

https://github.com/fedora-infra/bodhi/issues/298

But perhaps there needs to be a another for the notification message as well.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Testing chrony seccomp support

[Miroslav Lichvar]

On Mon, Oct 05, 2015 at 08:23:05AM -0500, Michael Catanzaro wrote:
> (Also fun is to try making the same list of filters work across
> distros.)

And across supported architectures. So far, I tested it only on x86_64
and i686 and there were quite a few differences. I would be surprised
if it worked on arm even in the default configuration :).

> So chrony might work perfectly now, but who knows how broken it will be
> after a couple months of updates Well, you'll find out after
> testing it in rawhide. Hope seccomp works better for you than it did
> for me. Of course, for programs with few dependencies, there's not
> really much problem.

I guess glibc and getaddrinfo() will be the most problematic part in
the chrony seccomp support. Is there a precedent in Fedora of a
package using a seccomp filter and getaddrinfo() by default?

If we can't enable it by default, I'll be ok with that. Currently I'm
just interested in how it works for others.

Another possibility is to add a new level to the chrony seccomp
support that would use a blacklisting approach, disabling syscalls or
their arguments that historically are most dangerous and we can be
sure won't be ever needed. I hope that's not an empty set.

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

[no subject]

[Martin Hagström]

Hi,

My name is Martin Hagström and I have just submitted my first package
review request: https://bugzilla.redhat.com/show_bug.cgi?id=1268910

I have been using Linux for about a decade and have been a Linux Systems
Administrator for the last three years. In this job I have done quite a bit
of packaging for rpm based systems but this is the first time I've aspired
to maintain a package in a "real" repo.

Happy to answer any questions.

Thanks,
Martin Hagström
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Testing chrony seccomp support

[Michael Catanzaro]

On Mon, 2015-10-05 at 07:02 -0700, Andrew Lutomirski wrote:
> Why is the filter causing SIGSYS instead of forcing an ENOSYS return?
> 
> I'll look into the abrt thing.  It might be an easy fix.
> 
> --Andy

Simply because it's an experimental project, and it's much easier to
crash with a core dump so it can be debugged, than to have obscure
failures all over the place.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: bodhi: no email notifications for packages in pending state

[Kevin Fenzi]

On Mon, 5 Oct 2015 13:26:32 +0200
Michael Schwendt  wrote:

> On Sun, 4 Oct 2015 23:59:13 +0300, Alexander Ploumistos wrote:
> 
> > I've reset email settings to the defaults (two rules, "A particular
> > user's packages (any acl)" and "A particular user "), made sure that
> > my email address is still there and I've got a "This message
> > delivery mechanism is currently active" message.
> > Meanwhile my packages have gone from pending to testing and three of
> > them to stable. No notification yet. Shouldn't I have been notified
> > with these settings? Do I need to turn on "All bodhi events" as
> > well?
> 
> You may want to read the last messages from me in this short thread:
> 
>   
> https://lists.fedoraproject.org/pipermail/devel/2015-August/thread.html#213311
> 
> To get more messages, touching the related filter "rules" may be
> needed.

You will likely need a number of the bodhi rules enabled to match your
account name.

kevin



pgp6XuaOrYl2d.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: bodhi: no email notifications for packages in pending state

[Kevin Fenzi]

On Mon, 5 Oct 2015 12:00:27 + (UTC)
Petr Pisar  wrote:

> On 2015-10-03, Kevin Fenzi  wrote:
> > On Sat, 3 Oct 2015 16:46:02 +0300
> > Alexander Ploumistos  wrote:
> >> For the last couple of days I have been submitting updates (with
> >> fedpkg) for some of my packages in all the branches. Currently they
> >> all appear as pending in bodhi and I have not received any messages
> >> about them, even for the ones that got positive karma.
> >
> > Almost all notifications from bodhi (with the exception currently of
> > adding comments on updates) is sent via FMN (the Fedora notification
> > service): https://apps.fedoraproject.org/notifications/
> >
> Which event is the "an update can be pushed to stable" from the
> available filters:

There isn't one, but I think that would be a great one to add. 

Can you file an issue/ticket on it?

kevin


pgp0M8QeQ6RZP.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: SPF records @fedoraproject.org versus @lists.fedoraproject.org

[Kevin Fenzi]

On Mon, 5 Oct 2015 11:04:40 -0400
Paul Wouters  wrote:

> And openpgpkey-milter :)
> 
> And put in a TLSA record for their MX :)

I don't think it makes much sense for Fedora Infrastructure to get into
the business of being a SMTP server provider. Is this something that
would help forward the goals of the Fedora Project? If so, how?

Additionally I suspect the admin overhead would be large just answering
"Your smtp server sent me spam" type of noise... 

kevin
--
> 
>  Paul
> 
> Sent from my iPhone
> 
> > On Oct 5, 2015, at 10:58, Michel Alexandre Salim
> >  wrote:
> > 
> > On a related note to that, it would be great if active Fedora
> > contributors do get to use an SMTP server with SPF and DKIM set up.
> > 
> > -- 
> > Michel
> > 
> >> On Mon, Oct 5, 2015 at 9:47 PM, Marcin Juszkiewicz
> >>  wrote: W dniu 05.10.2015 o 16:43, Reindl
> >> Harald pisze:
> >>> well, that people should send their mail from the Fedora servers
> >>> and not from a wrong configured random MTA allowing random
> >>> envelope senders
> >> 
> >> Many of those people send their mail from properly configured MTA
> >> allowing random envelope senders for authenticated users.
> >> 
> >> -- 
> >> devel mailing list
> >> devel@lists.fedoraproject.org
> >> https://admin.fedoraproject.org/mailman/listinfo/devel
> >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> > 
> > -- 
> > devel mailing list
> > devel@lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/devel
> > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct



pgpMdJkmno5Ok.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Orphaned packages looking for new Point of Contact

[Orion Poplawski]

On 10/01/2015 06:34 AM, Ankur Sinha wrote:
> On Wed, 2015-09-30 at 13:40 -0600, Kevin Fenzi wrote:
>> suitesparse (el5)
>> suitesparse (f21)
>> suitesparse (f22)
>> suitesparse (f23)
>> suitesparse (master)
> 
> I checked - the package is orphaned, but it does have 3
> "administrators" - should I first check if any of them would like to
> take over before I request ownership?

Sure.  But it's easy enough to transfer later if desired, so I'm not sure it's
that big of a deal.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: SPF records @fedoraproject.org versus @lists.fedoraproject.org

[Reindl Harald]

Am 05.10.2015 um 16:47 schrieb Marcin Juszkiewicz:

W dniu 05.10.2015 o 16:43, Reindl Harald pisze:

well, that people should send their mail from the Fedora servers and
not from a wrong configured random MTA allowing random envelope
senders


Many of those people send their mail from properly configured MTA
allowing random envelope senders for authenticated users


well, and that's why spamfighting is that complicated
a MTA allowing random sender is *not* properly configured

however, at least the bodhi mails should come from a subdomain with a 
SPF record or at least DKIM signed which would also hit 
"whitelist_auth", alternatively STOP THAT NEW mass mails while using 
fedora-easy-karma (which now works after a long time), i know by myself 
that i have commented a testing update


i guess you don't use random sevrers fro your @redhat.com

redhat.com. 600 IN  TXT "v=spf1 
include:u1969764.wl.sendgrid.net include:_spf1.redhat.com 
include:_spf2.redhat.com -all"




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

Re: SPF records @fedoraproject.org versus @lists.fedoraproject.org

[Paul Wouters]

And openpgpkey-milter :)

And put in a TLSA record for their MX :)

 Paul

Sent from my iPhone

> On Oct 5, 2015, at 10:58, Michel Alexandre Salim  
> wrote:
> 
> On a related note to that, it would be great if active Fedora contributors do 
> get to use an SMTP server with SPF and DKIM set up.
> 
> -- 
> Michel
> 
>> On Mon, Oct 5, 2015 at 9:47 PM, Marcin Juszkiewicz  
>> wrote:
>> W dniu 05.10.2015 o 16:43, Reindl Harald pisze:
>>> well, that people should send their mail from the Fedora servers and
>>> not from a wrong configured random MTA allowing random envelope
>>> senders
>> 
>> Many of those people send their mail from properly configured MTA allowing 
>> random envelope senders for authenticated users.
>> 
>> -- 
>> devel mailing list
>> devel@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/devel
>> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> 
> -- 
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: SPF records @fedoraproject.org versus @lists.fedoraproject.org

[Kevin Fenzi]

On Mon, 5 Oct 2015 16:47:09 +0200
Marcin Juszkiewicz  wrote:

> W dniu 05.10.2015 o 16:43, Reindl Harald pisze:
> > well, that people should send their mail from the Fedora servers and
> > not from a wrong configured random MTA allowing random envelope
> > senders
> 
> Many of those people send their mail from properly configured MTA 
> allowing random envelope senders for authenticated users.

There's no "sending from Fedora servers". 

@fedoraproject.org _aliases_ are just aliases. They aren't real
mailboxes. 

We will never have SPF records for fedoraproject.org. 

The bodhi emails are IMHO a bug: 
https://github.com/fedora-infra/bodhi/issues/626

It should ideally not send them at all (in favor of FMN) or  if it has
to for some reason, they should come from a known address and not
pretend to be from the commenter. 

kevin


pgpswSphjdL65.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: SPF records @fedoraproject.org versus @lists.fedoraproject.org

[Michel Alexandre Salim]

On a related note to that, it would be great if active Fedora contributors
do get to use an SMTP server with SPF and DKIM set up.

-- 
Michel

On Mon, Oct 5, 2015 at 9:47 PM, Marcin Juszkiewicz 
wrote:

> W dniu 05.10.2015 o 16:43, Reindl Harald pisze:
>
>> well, that people should send their mail from the Fedora servers and
>> not from a wrong configured random MTA allowing random envelope
>> senders
>>
>
> Many of those people send their mail from properly configured MTA allowing
> random envelope senders for authenticated users.
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Stephen John Smoogen]

On 5 October 2015 at 05:09, Dave Love  wrote:
> Tom Hughes  writes:
>
>> Recently I even saw a case of a header only C++ library bundling
>> another C++ head library which raises slightly metaphysical questions
>> since dependants of a header only library need to be rebuilt when it
>> changes anyway if they are to pickup security fixes. Strictly speaking
>> that's even true of a more traditional library if the security fix
>> happens to be in a header, but I wonder how well we pick up such
>> things and propagate them?
>
> I don't think that's uncommon in applications I see.  I've been puzzled
> throughout why using things like Boost isn't counted and why this only
> seems to be about security, from what people have been saying.
>
> A header-only, or header-mainly, library seems quite likely to affect
> security-sensitive programs.  On the other hand, the sort of (likely
> modified or version-specific) libraries for building the scientific
> programs I'm interested in seem to be problematical on the same level as
> things affecting potentially security-sensitive system programs.
>

I believe people are mostly dealing with security because it is the
side that has the most real world effects and is the hammer which
usually gets people to do something after they ignored it when all the
other arguments have been made. Because in this networked world
everything becomes security sensitive because a hacker doesn't need to
be root to do a lot of things.

Hackers have used HPC computers for bitcoin mining because a grid app
had an overflow which allowed them to run apps as a general user. They
have set up spam farms for similar things. Another just decided to a
lark to change data in a database to see if anyone noticed. All of
which has interfered with research (and affected at least a couple of
Phd's graduation times.)

Most of those break-ins happened because of applications which were
considered non-security related and usually via a bundled pile of PHP
or java.

> I am all in favour of unbundling as much from such packages as
> reasonably practical, from an engineering and system management point of
> view, and have done it.  I'm just puzzled by some of the rationale in
> the discussion.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct



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

Re: SPF records @fedoraproject.org versus @lists.fedoraproject.org

[Marcin Juszkiewicz]

W dniu 05.10.2015 o 16:43, Reindl Harald pisze:

well, that people should send their mail from the Fedora servers and
not from a wrong configured random MTA allowing random envelope
senders


Many of those people send their mail from properly configured MTA 
allowing random envelope senders for authenticated users.

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

Re: SPF records @fedoraproject.org versus @lists.fedoraproject.org

[Reindl Harald]

Am 05.10.2015 um 16:16 schrieb Stephen John Smoogen:

On 4 October 2015 at 03:03, Reindl Harald  wrote:

is there a reason that the list-subdomain has a SPF record but the main
domain not? now that as example "bo...@fedoraproject.org" sends a lot of
mails it would make sense to shortciruit them as ham on spamfilters as it is
possible for the mailing-lists


I think the fact that various people use n...@fedoraproject.org as their
email address. If we put an SPF that bodhi email comes from a certain
address area, then those people will need to send email also from that
zone or be treated as SPAM. Of course I could be completely wrong
here.. and I am ok with that.


well, that people should send their mail from the Fedora servers and not 
from a wrong configured random MTA allowing random envelope senders


however, it would make a lot of sense use for infrastructure mails a own 
subdomain like "lists.fedoraproject.org" because handling them different 
then personal sent mails from probably hacked accounts


BTW - that should also be the bodhi-adress and not the karma commenter 
as envelope:


Return-Path: lupi...@fedoraproject.org
[Fedora Update] [comment] kde-runtime-15.08.1-2.fc22




lists.fedoraproject.org. 300IN  TXT "v=spf1 mx
a:lists.fedoraproject.org a:bastion.fedoraproject.org
a:bastion02.fedoraproject.org a:bastion01.fedoraproject.org ~all"


[harry@srv-rhsoft:~]$ dig TXT fedoraproject.org
; <<>> DiG 9.10.2-P4-RedHat-9.10.2-5.P4.fc22 <<>> TXT fedoraproject.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47349
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1024
;; QUESTION SECTION:
;fedoraproject.org. IN  TXT

;; AUTHORITY SECTION:
fedoraproject.org.  120 IN  SOA ns04.fedoraproject.org.
hostmaster.fedoraproject.org. 2443921540 3600 600 2419200 86400

;; Query time: 27 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: So Okt 04 10:59:15 CEST 2015
;; MSG SIZE  rcvd: 98




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

Re: Orphaned packages looking for new Point of Contact

[Matthias Saou]

On Fri, 2 Oct 2015 00:01:11 +
Zbigniew Jędrzejewski-Szmek  wrote:

> On Thu, Oct 01, 2015 at 06:53:35PM -0400, Matthew Miller wrote:
> > On Thu, Oct 01, 2015 at 08:46:57PM +, Zbigniew
> > Jędrzejewski-Szmek wrote:
> > > >   
> > > > https://kojipkgs.fedoraproject.org//packages/linux_logo/5.11/10.fc22/data/logs/x86_64/build.log
> > > What about a Fedora logo?
> > 
> > We need to ask Fedora Design for a trademark-approved ASCII art
> > version.
> What about the one from screenfetch [1]?
> 
> [1] http://in.waw.pl/~zbyszek/fedora/screenfetch.png (sorry for the
> black-and-whiteness, not so easy to take screenshot under wayland.)

Feel free to submit a logo upstream, then ping me to get it included if
there is no immediate release. I saw that a few logo have been added in
the last few years (OpenBSD, Arch, Raspberry Pi...) and are not yet
included in a new release.

I have actually poked the maintainer about this, and about the order of
the logos, since Richard did file a bug report about it ;-)

Matthias

-- 
Matthias Saou  ██  ██
 ██  ██
Web: http://matthias.saou.eu/  ██
Mail/XMPP:  matth...@saou.eu   ██  
   ██
GPG: 4096R/E755CC63██  ██  ██
 8D91 7E2E F048 9C9C 46AF  ██  ██  ██  ██
 21A9 7A51 7B82 E755 CC63  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: scriplet issues installing deps in f23 mock

[Miroslav Suchý]

Tracked under:
https://bugzilla.redhat.com/show_bug.cgi?id=1268883

What we know so far is:
 * it happen under F23
 * it works in F22
 * it works with dnf
 * it does not work with yum.

So "mock --dnf" can be used as temporary workaround for those who are blocked 
by this.

-- 
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: SPF records @fedoraproject.org versus @lists.fedoraproject.org

[Stephen John Smoogen]

On 4 October 2015 at 03:03, Reindl Harald  wrote:
> is there a reason that the list-subdomain has a SPF record but the main
> domain not? now that as example "bo...@fedoraproject.org" sends a lot of
> mails it would make sense to shortciruit them as ham on spamfilters as it is
> possible for the mailing-lists

I think the fact that various people use n...@fedoraproject.org as their
email address. If we put an SPF that bodhi email comes from a certain
address area, then those people will need to send email also from that
zone or be treated as SPAM. Of course I could be completely wrong
here.. and I am ok with that.

> 
>
> lists.fedoraproject.org. 300IN  TXT "v=spf1 mx
> a:lists.fedoraproject.org a:bastion.fedoraproject.org
> a:bastion02.fedoraproject.org a:bastion01.fedoraproject.org ~all"
> 
>
> [harry@srv-rhsoft:~]$ dig TXT fedoraproject.org
> ; <<>> DiG 9.10.2-P4-RedHat-9.10.2-5.P4.fc22 <<>> TXT fedoraproject.org
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47349
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1024
> ;; QUESTION SECTION:
> ;fedoraproject.org. IN  TXT
>
> ;; AUTHORITY SECTION:
> fedoraproject.org.  120 IN  SOA ns04.fedoraproject.org.
> hostmaster.fedoraproject.org. 2443921540 3600 600 2419200 86400
>
> ;; Query time: 27 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: So Okt 04 10:59:15 CEST 2015
> ;; MSG SIZE  rcvd: 98
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct



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

Re: Self Introduction: Florian Weimer

[Richard W.M. Jones]

On Mon, Oct 05, 2015 at 03:11:52PM +0100, Richard W.M. Jones wrote:
> On Mon, Oct 05, 2015 at 03:47:22PM +0200, Florian Weimer wrote:
> > I recently joined the Red Hat tools team, to work on glibc with Carlos
> > O'Donell.  As a result, I will co-maintain glibc in Fedora.
> 
> Welcome to the Fedora development community.  Let me know if you have
> any questions about how to use fedpkg / commit changes to glibc / etc.

This was a bit clumsily worded.  I don't mean to say only I can help
you with these, but I'll be happy to help if I can.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Self Introduction: Florian Weimer

[Richard W.M. Jones]

On Mon, Oct 05, 2015 at 03:47:22PM +0200, Florian Weimer wrote:
> I recently joined the Red Hat tools team, to work on glibc with Carlos
> O'Donell.  As a result, I will co-maintain glibc in Fedora.

Welcome to the Fedora development community.  Let me know if you have
any questions about how to use fedpkg / commit changes to glibc / etc.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Testing chrony seccomp support

[Andrew Lutomirski]

On Oct 5, 2015 6:23 AM, "Michael Catanzaro"  wrote:
>
> On Mon, 2015-10-05 at 13:58 +0200, Miroslav Lichvar wrote:
> > The rawhide chrony package is now compiled with the seccomp support,
> > but the filtering is not enabled by default. The trouble is it has to
> > cover all system calls needed in all possible configurations of
> > chrony
> > and all libraries it depends on, which is difficult and it may even
> > change over time as the libraries are updated.
>
> Yes; depending on your dependencies (...yeah!) this could be highly
> problematic. As you say, it imposes the requirement that all of your
> dependencies in Fedora never begin to use new syscalls, and never use
> syscalls in unexpected ways, over the supported lifetime of a Fedora
> release, or bundle their updates with corresponding chrony updates if
> they do. Frankly it's a recipe for disaster, given that many
> maintainers submit major version updates in flagrant disregard for our
> current updates policy, and using seccomp would require tightening the
> updates policy much more (since it makes minor version updates quite
> risky -- but we still want to do those...), but the security benefits
> of seccomp are huge so it's possibly worth working towards

Why is the filter causing SIGSYS instead of forcing an ENOSYS return?

I'll look into the abrt thing.  It might be an easy fix.

--Andy

>
> Random example: when I was testing WebKit's experimental seccomp mode
> in Fedora 21, the maintainers of libxshmfence submitted an update to
> start using the new syscall memfd_create() rather than putting shared
> memory in /var/tmp. That's an acceptable update under all of our
> guidelines, since that's an implementation detail that ordinarily
> wouldn't affect programs, but it caused WebKit to crash on start, and
> would have broken pretty much anything else using libxshmfence and
> seccomp, since programs aren't going to have whitelisted a syscall that
> was not previously used (and in this case, didn't even exist when it
> was written). With chrony using seccomp, its dependencies must never do
> such a thing (except in rawhide).
>
> (Also fun is to try making the same list of filters work across
> distros.)
>
> So chrony might work perfectly now, but who knows how broken it will be
> after a couple months of updates Well, you'll find out after
> testing it in rawhide. Hope seccomp works better for you than it did
> for me. Of course, for programs with few dependencies, there's not
> really much problem.
>
> Michael
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[POC-change] Fedora packages point of contact updates

[nobody]

Change in package status over the last 168 hours


97 packages were orphaned
-
SDL_gfx [f23, f22, f21, master, el6, epel7, el5] was orphaned by kevin
 SDL graphics drawing primitives and other support functions
 https://admin.fedoraproject.org/pkgdb/package/SDL_gfx
Sprog [f21] was orphaned by kevin
 A graphical tool to build programs by plugging parts together
 https://admin.fedoraproject.org/pkgdb/package/Sprog
advancecomp [f23, f22, f21, master, el6, epel7, el5] was orphaned by kevin
 Recompression utilities for .PNG, .MNG and .ZIP files
 https://admin.fedoraproject.org/pkgdb/package/advancecomp
autodir [f23, f22, f21, master, el6, el5] was orphaned by kevin
 Creates user directories on demand
 https://admin.fedoraproject.org/pkgdb/package/autodir
bbkeys [f23, f22, f21, master, el6, el5] was orphaned by kevin
 Completely configurable key-combo grabber for blackbox
 https://admin.fedoraproject.org/pkgdb/package/bbkeys
blackbox [f23, f22, f21, master, el6, el5] was orphaned by kevin
 Very small and fast Window Manager
 https://admin.fedoraproject.org/pkgdb/package/blackbox
boa [f23, f22, f21, master, el6, el5] was orphaned by kevin
 Single-tasking HTTP server
 https://admin.fedoraproject.org/pkgdb/package/boa
camE [f23, f22, f21, master, el6, el5] was orphaned by kevin
 Rewrite of the xawtv webcam app, which adds imlib2 support
 https://admin.fedoraproject.org/pkgdb/package/camE
cdargs [f23, f22, f21, master] was orphaned by kevin
 The shell cd with bookmarks and browser
 https://admin.fedoraproject.org/pkgdb/package/cdargs
csmash [f23, f22, f21, master, el6, el5] was orphaned by kevin
 3D tabletennis game
 https://admin.fedoraproject.org/pkgdb/package/csmash
cvs2svn [f23, f22, f21, master, el6, el5] was orphaned by kevin
 CVS to Subversion Repository Converter
 https://admin.fedoraproject.org/pkgdb/package/cvs2svn
d4x [el6, el5] was orphaned by kevin
 Downloader for X that supports resuming and many other features
 https://admin.fedoraproject.org/pkgdb/package/d4x
dclib [f23, f22, f21, master, el6, el5] was orphaned by kevin
 Direct Connect file sharing library
 https://admin.fedoraproject.org/pkgdb/package/dclib
directfb [el6, el5] was orphaned by kevin
 Graphics abstraction library for the Linux Framebuffer Device
 https://admin.fedoraproject.org/pkgdb/package/directfb
elisa [el6, el5] was orphaned by kevin
 Media Center
 https://admin.fedoraproject.org/pkgdb/package/elisa
gcombust [el6, el5] was orphaned by kevin
 Powerful graphical front-end for mkisofs and cdrecord
 https://admin.fedoraproject.org/pkgdb/package/gcombust
gentoo [f23, f22, f21, master, el6, el5] was orphaned by kevin
 Graphical file management program written in GTK+3
 https://admin.fedoraproject.org/pkgdb/package/gentoo
giblib [f23, f22, f21, master, el6, el5] was orphaned by kevin
 Simple library and a wrapper for imlib2
 https://admin.fedoraproject.org/pkgdb/package/giblib
gkrellm-aclock [f23, f22, f21, master, el6, el5] was orphaned by kevin
 Analog clock plugin for GKrellM
 https://admin.fedoraproject.org/pkgdb/package/gkrellm-aclock
gkrellm-freq [f23, f22, f21, el6, master] was orphaned by kevin
 CPU frequency display plugin for GKrellM
 https://admin.fedoraproject.org/pkgdb/package/gkrellm-freq
gkrellm-moon [f23, f22, f21, master, el6, el5] was orphaned by kevin
 Moon clock plugin for GKrellM
 https://admin.fedoraproject.org/pkgdb/package/gkrellm-moon
gkrellm-sun [f23, f22, f21, master, el6, el5] was orphaned by kevin
 Sun clock plugin for GKrellM
 https://admin.fedoraproject.org/pkgdb/package/gkrellm-sun
gtweakui [f22, f21, el6, el5] was orphaned by kevin
 Extra configuration dialogs for GNOME
 https://admin.fedoraproject.org/pkgdb/package/gtweakui
hackedbox [f23, f22, f21, master, el6, el5] was orphaned by kevin
 The bastard son of Blackbox, a small and fast Window Manager
 https://admin.fedoraproject.org/pkgdb/package/hackedbox
html-xml-utils [f23, f22, f21, master] was orphaned by kevin
 A number of simple utilities for manipulating HTML and XML files
 https://admin.fedoraproject.org/pkgdb/package/html-xml-utils
i8kutils [f23, f22, f21, master, el6, el5] was orphaned by kevin
 Dell laptop (Inspiron 8000 and others) SMM BIOS support tools
 https://admin.fedoraproject.org/pkgdb/package/i8kutils
idjc [f23, f22, f21, master] was orphaned by comzeradd
 DJ application for streaming audio
 https://admin.fedoraproject.org/pkgdb/package/idjc
ipw2100-firmware [el5] was orphaned by kevin
 Firmware for Intel® PRO/Wireless 2100 network adaptors
 https://admin.fedoraproject.org/pkgdb/package/ipw2100-firmware
ipw2200-firmware [el5] was orphaned by kevin
 Firmware for Intel® PRO/Wireless 2200 network adaptors
 https://admin.fedoraproject.or

Self Introduction: Florian Weimer

[Florian Weimer]

I recently joined the Red Hat tools team, to work on glibc with Carlos
O'Donell.  As a result, I will co-maintain glibc in Fedora.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Testing chrony seccomp support

[Michael Catanzaro]

On Mon, 2015-10-05 at 13:58 +0200, Miroslav Lichvar wrote:
> The rawhide chrony package is now compiled with the seccomp support,
> but the filtering is not enabled by default. The trouble is it has to
> cover all system calls needed in all possible configurations of
> chrony
> and all libraries it depends on, which is difficult and it may even
> change over time as the libraries are updated.

Yes; depending on your dependencies (...yeah!) this could be highly
problematic. As you say, it imposes the requirement that all of your
dependencies in Fedora never begin to use new syscalls, and never use
syscalls in unexpected ways, over the supported lifetime of a Fedora
release, or bundle their updates with corresponding chrony updates if
they do. Frankly it's a recipe for disaster, given that many
maintainers submit major version updates in flagrant disregard for our
current updates policy, and using seccomp would require tightening the
updates policy much more (since it makes minor version updates quite
risky -- but we still want to do those...), but the security benefits
of seccomp are huge so it's possibly worth working towards

Random example: when I was testing WebKit's experimental seccomp mode
in Fedora 21, the maintainers of libxshmfence submitted an update to
start using the new syscall memfd_create() rather than putting shared
memory in /var/tmp. That's an acceptable update under all of our
guidelines, since that's an implementation detail that ordinarily
wouldn't affect programs, but it caused WebKit to crash on start, and
would have broken pretty much anything else using libxshmfence and
seccomp, since programs aren't going to have whitelisted a syscall that
was not previously used (and in this case, didn't even exist when it
was written). With chrony using seccomp, its dependencies must never do
such a thing (except in rawhide).

(Also fun is to try making the same list of filters work across
distros.)

So chrony might work perfectly now, but who knows how broken it will be
after a couple months of updates Well, you'll find out after
testing it in rawhide. Hope seccomp works better for you than it did
for me. Of course, for programs with few dependencies, there's not
really much problem.

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

Removing packages that have broken dependencies in F23 tree, v2

[Kalev Lember]

Hi all,

Here's another look at F23 broken dependencies. A number of packages
have been fixed last week, but there's also a new broken dependency,
CableSwig, due to gccxml retirement.

The goal is to ship Fedora releases with repos where all packages are
installable. On 2015-10-12, any packages that have remaining broken
dependencies are going to get automatically retired by Fedora release
engineering so that we can enter the Final Freeze with clean
repositories.

Based on today's Branched report [1], the following packages have
remaining broken dependencies (package maintainers BCC'd to this email):

   Package(co)maintainers

CableSwig mrceresa
apache-scout  goldmann
hbase rrati, coolsvap, moceap
moon-buggyrobert
netbeans-platform moceap, dbhole, omajid
nodejs-grunt-contrib-copy ralph
oat   gwei3
oozie rrati, coolsvap, moceap
openstack-heat-gbprkukura
openstack-neutron-gbp rkukura
openstack-swift   zaitcev, apevec, derekh, hguemar, itamarjp, jsteffan, 
ke4qqq, mmagr, russellb
pure  salimma, cicku
pyjigdo   kanarip, jsteffan
python-django-horizon-gbp rkukura
python-fiat   fab
spark willb
vdr-live  martinkg
vfrnavsailer


Impacted dependant packages that would get retired together with the
packages above:

Depending on: apache-scout (2)
wildfly (maintained by: goldmann)
wildfly-8.1.0-3.fc22.src requires apache-scout = 1.2.6-11.fc21

eclipse-jbosstools (maintained by: galileo, goldmann, 
group::eclipse-sig)
eclipse-jbosstools-4.2.2-1.fc22.src requires wildfly = 
8.1.0-3.fc22
eclipse-jbosstools-as-4.2.2-1.fc22.noarch requires wildfly = 
8.1.0-3.fc22


Depending on: hbase (2)
pig (maintained by: pmackinn, coolsvap, java-sig, moceap)
pig-0.13.0-1.fc21.noarch requires hbase = 0.98.3-4.fc22
pig-0.13.0-1.fc21.src requires hbase = 0.98.3-4.fc22

hive (maintained by: pmackinn, coolsvap, java-sig, moceap)
hive-0.12.0-5.fc22.src requires pig = 0.13.0-1.fc21


Depending on: openstack-swift (1)
openstack-swift-plugin-swift3 (maintained by: zaitcev, apevec, itamarjp)

openstack-swift-plugin-swift3-1.7-6.20150601git69f94393.fc23.noarch requires 
openstack-swift = 2.3.0-2.fc23


Depending on: pure (1)
pure-glpk (maintained by: cicku)
pure-glpk-0.5-1.fc23.i686 requires libpure.so.8
pure-glpk-0.5-1.fc23.src requires pure-devel = 0.62-2.fc22

[1] https://lists.fedoraproject.org/pipermail/devel/2015-October/215350.html

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

Perl 32 bit enabling -Duse64bitint (was: Re: Removing packages that have broken dependencies in F23 tree)

[Richard W.M. Jones]

On Sun, Oct 04, 2015 at 01:37:38PM +0100, Richard W.M. Jones wrote:
> On Sun, Oct 04, 2015 at 06:51:28AM +0100, Peter Robinson wrote:
> > On Sun, Oct 4, 2015 at 4:43 AM, Jerry James  wrote:
> > > On Thu, Sep 24, 2015 at 8:34 AM, Kalev Lember  
> > > wrote:
> > >> polymakejjames, rmattes
> > >
> > > At long last I have been able to fix this.  The polymake maintainers,
> > > based on their experience with some unspecified Linux distributions,
> > > not including Fedora but including Ubuntu, assumed that all 32-bit
> > > perl builds include 64-bit native integers.  However, Fedora's perl is
> > > configured so that 32-bit perl has only 32-bit native integers.  The
> > > polymake maintainers expressed great surprise that Fedora is so
> > > backward that we haven't heard about 64-bit native integers in 32-bit
> > > perl yet.  Nonetheless, once the problem was identified, they helped
> > > me fix it and promised to add a test for this problem to their test
> > > suite to prevent its reappearance.
> > 
> > Might be worth filing a bug to track/document why we don't have the
> > 64bit ints on 32 bit perl.
> 
> Debian uses `Configure -Duse64bitint' which seems to be the key.
> 
> I've written quite a few Perl programs where I've had to tell the end
> user that they must use a 64 bit platform.  Didn't realize until now
> there was a way to configure 64 bit ints on a 32 bit platform.

I was kind of hoping a Perl developer might jump in there, but perhaps
because this thread quite old, and has a confusing subject line, no
one has.  Anyway I filed this bug:

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

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: bodhi: no email notifications for packages in pending state

[Petr Pisar]

On 2015-10-03, Kevin Fenzi  wrote:
> On Sat, 3 Oct 2015 16:46:02 +0300
> Alexander Ploumistos  wrote:
>> For the last couple of days I have been submitting updates (with
>> fedpkg) for some of my packages in all the branches. Currently they
>> all appear as pending in bodhi and I have not received any messages
>> about them, even for the ones that got positive karma.
>
> Almost all notifications from bodhi (with the exception currently of
> adding comments on updates) is sent via FMN (the Fedora notification
> service): https://apps.fedoraproject.org/notifications/
>
Which event is the "an update can be pushed to stable" from the available
filters:

All bodhi events
Bodhi comments
Bodhi having their request revoked
Bodhi updates being obsoleted
Buildroot overrides being removed
Critpath updates (of any kind)
Ends of internal bodhi backend mash tasks
New EPEL content has hit the master mirror
New Fedora updates content has hit the master mirror
New buildroot overrides
New errata about updates being mashed
New updates requested for updates-testing
Requests for "stable" status on Bodhi updates
Requests for Bodhi updates to be unpushed
Requests for a new Bodhi mash
Starts of internal bodhi backend mash tasks
Starts of the mash phase of the mashtask
When an update is ejected from the bodhi mash
When the masher confirms content is on the master mirror
When the masher waits for content to sync to the mirrors
When updates complete their requested push to "stable"
When updates complete their requested push to "testing"

I cannot see it there.

-- Petr

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

psabata pushed to perl-Test-Strict (f22). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild"

[notifications]

From 05260351653b5e6bc22ef6dc8b0dd5f85da78cc5 Mon Sep 17 00:00:00 2001
From: Dennis Gilmore 
Date: Thu, 18 Jun 2015 06:42:56 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild


diff --git a/perl-Test-Strict.spec b/perl-Test-Strict.spec
index 90aedc3..9d2ce75 100644
--- a/perl-Test-Strict.spec
+++ b/perl-Test-Strict.spec
@@ -1,6 +1,6 @@
 Name:   perl-Test-Strict
 Version:0.27
-Release:2%{?dist}
+Release:3%{?dist}
 License:GPL+ or Artistic
 Group:  Development/Libraries
 Summary:Check syntax, presence of use strict/warnings, and test 
coverage
@@ -56,6 +56,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Jun 18 2015 Fedora Release Engineering  
- 0.27-3
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
+
 * Mon Jun 08 2015 Jitka Plesnikova  - 0.27-2
 - Perl 5.22 rebuild
 
-- 
cgit v0.10.2



http://pkgs.fedoraproject.org/cgit/perl-Test-Strict.git/commit/?h=f22&id=05260351653b5e6bc22ef6dc8b0dd5f85da78cc5
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Testing chrony seccomp support

[Miroslav Lichvar]

In chrony 2.2-pre1 was added support for system call filtering with
the kernel seccomp facility. In chrony it's mainly useful to reduce
the damage from attackers who can execute arbitrary code, e.g. prevent
gaining the root privileges through a kernel vulnerability.

The rawhide chrony package is now compiled with the seccomp support,
but the filtering is not enabled by default. The trouble is it has to
cover all system calls needed in all possible configurations of chrony
and all libraries it depends on, which is difficult and it may even
change over time as the libraries are updated.

I'm interested to know if this works in other configurations than what
I tried, especially non-default NSS configurations, and get an idea if
this could be enabled by default at some point.

If you would like to help with the testing:

1. echo 'OPTIONS="-F -1"' > /etc/sysconfig/chronyd
2. systemctl restart chronyd
3. occasionally check if chronyd is still running

If you see in the log that the process was killed with status=31/SYS,
it's a problem in the seccomp support. Please let me know it has
crashed for you. Unfortunately, abrt doesn't seem to catch these
crashes, even when /proc/sys/fs/suid_dumpable is set to 2.

For F22 and F23 there is a COPR repo with packages built from the
current development code:
https://copr.fedoraproject.org/coprs/mlichvar/chrony/

Thanks,

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

F-23 Branched report: 20151005 changes

[Fedora Branched Report]

Compose started at Mon Oct  5 07:15:03 UTC 2015
Broken deps for armhfp
--
[CableSwig]
CableSwig-3.20.0-13.fc23.armv7hl requires gccxml
[apache-scout]
apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:uddi-ws)
apache-scout-1.2.6-11.fc21.noarch requires 
mvn(org.apache.juddi:juddi-client)
[hamlib]
hamlib-devel-3.0-2.fc23.armv7hl requires hamlib-tcl(armv7hl-32) = 
0:3.0-2.fc23
[hbase]
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-server)
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-json)
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-core)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
[moon-buggy]
moon-buggy-1.0.51-14.fc23.armv7hl requires libesd.so.0
[netbeans-platform]
1:netbeans-platform-harness-7.0.1-11.fc22.armv7hl requires cobertura >= 
0:1.9.3
[nodejs-grunt-contrib-copy]
nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires 
npm(file-sync-cmp) < 0:0.2
nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires 
npm(file-sync-cmp) >= 0:0.1.0
nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires npm(chalk) >= 
0:0.5.1
[oat]
oat-appraiser-1.6.0-16.fc22.armv7hl requires tomcat-servlet-3.0-api
oat-client-1.6.0-16.fc22.armv7hl requires tomcat-servlet-3.0-api
[oozie]
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.pig:pig)
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-serde)
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-metastore)
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-exec)
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-common)
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-cli)
oozie-4.0.1-5.fc22.noarch requires 
mvn(org.apache.hive.hcatalog:webhcat-java-client)
oozie-4.0.1-5.fc22.noarch requires 
mvn(org.apache.hive.hcatalog:hcatalog-server-extensions)
oozie-4.0.1-5.fc22.noarch requires 
mvn(org.apache.hive.hcatalog:hcatalog-pig-adapter)
oozie-4.0.1-5.fc22.noarch requires 
mvn(org.apache.hive.hcatalog:hcatalog-core)
[openstack-heat-gbp]
openstack-heat-gbp-2014.2-2.fc23.noarch requires openstack-heat-engine 
< 0:2014.3
[openstack-neutron-gbp]
openstack-neutron-gbp-2014.2-2.fc23.noarch requires openstack-neutron < 
0:2014.3
[openstack-swift]
openstack-swift-2.3.0-2.fc23.noarch requires python-pyeclib
[polymake]
polymake-2.13-22.git20141013.fc23.armv7hl requires 
perl(:MODULE_COMPAT_5.20.2)
polymake-2.13-22.git20141013.fc23.armv7hl requires perl = 4:5.20.2
polymake-2.13-22.git20141013.fc23.armv7hl requires libperl.so.5.20
polymake-2.13-22.git20141013.fc23.armv7hl requires liblrsgmp.so.5
[pyjigdo]
pyjigdo-0.4.0.3-9.fc23.noarch requires fuseiso
[python-django-horizon-gbp]
openstack-dashboard-gbp-2014.2-2.fc23.noarch requires 
openstack-dashboard < 0:2014.3
python-django-horizon-gbp-2014.2-2.fc23.noarch requires 
python-django-horizon < 0:2014.3
[python-fiat]
python-fiat-1.5.0-2.fc23.noarch requires ScientificPython
[python-gbpclient]
python-gbpclient-0.9.0-2.fc23.noarch requires python-neutronclient = 
0:2.3.9
[vdr-live]
vdr-live-0.3.0-21.20150213git6ea279a.fc23.armv7hl requires 
libtntnet.so.12
vdr-live-0.3.0-21.20150213git6ea279a.fc23.armv7hl requires 
libcxxtools.so.9
[vfrnav]
vfrnav-20141211-1.fc22.armv7hl requires libgps.so.21
vfrnav-utils-20141211-1.fc22.armv7hl requires libgdal.so.1



Broken deps for i386
--
[CableSwig]
CableSwig-3.20.0-13.fc23.i686 requires gccxml
[apache-scout]
apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:uddi-ws)
apache-scout-1.2.6-11.fc21.noarch requires 
mvn(org.apache.juddi:juddi-client)
[hamlib]
hamlib-devel-3.0-2.fc23.i686 requires hamlib-tcl(x86-32) = 0:3.0-2.fc23
[hbase]
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-server)
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-json)
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-core)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
[moon-buggy]
moon-buggy-1.0.51-14.fc23.i686 requires libesd.so.0
[netbeans-platform]
1:netbeans-platform-harness-7.0.1-11.fc22.i686 requires cobertura >= 
0:1.9.3
[nodejs-grunt-contrib-copy]
nodejs-grunt-co

Re: bodhi: no email notifications for packages in pending state

[Michael Schwendt]

On Sun, 4 Oct 2015 23:59:13 +0300, Alexander Ploumistos wrote:

> I've reset email settings to the defaults (two rules, "A particular
> user's packages (any acl)" and "A particular user "), made sure that
> my email address is still there and I've got a "This message delivery
> mechanism is currently active" message.
> Meanwhile my packages have gone from pending to testing and three of
> them to stable. No notification yet. Shouldn't I have been notified
> with these settings? Do I need to turn on "All bodhi events" as well?

You may want to read the last messages from me in this short thread:

  https://lists.fedoraproject.org/pipermail/devel/2015-August/thread.html#213311

To get more messages, touching the related filter "rules" may be
needed.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Self Introduction: Dominique Martinet

[Dave Love]

Dominique Martinet  writes:

> Hi,
>
> I'm a developper/sysadmin at CEA, a French research institute, mainly
> working on HPC clusters - both maintenance and designing new ones.

That's good to see for some of us.

In case you don't know, it's worth looking under
http://copr.fedoraproject.org/, as well as submitted reviews, for
existing packaging relevant to HPC.  Unfortunately a search won't
necessarily find packages by name that are there, but we should avoid
duplicated work as much as possible.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Dave Love]

Tom Hughes  writes:

> Recently I even saw a case of a header only C++ library bundling
> another C++ head library which raises slightly metaphysical questions
> since dependants of a header only library need to be rebuilt when it
> changes anyway if they are to pickup security fixes. Strictly speaking
> that's even true of a more traditional library if the security fix
> happens to be in a header, but I wonder how well we pick up such
> things and propagate them?

I don't think that's uncommon in applications I see.  I've been puzzled
throughout why using things like Boost isn't counted and why this only
seems to be about security, from what people have been saying.

A header-only, or header-mainly, library seems quite likely to affect
security-sensitive programs.  On the other hand, the sort of (likely
modified or version-specific) libraries for building the scientific
programs I'm interested in seem to be problematical on the same level as
things affecting potentially security-sensitive system programs.

I am all in favour of unbundling as much from such packages as
reasonably practical, from an engineering and system management point of
view, and have done it.  I'm just puzzled by some of the rationale in
the discussion.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Dave Love]

Björn Persson  writes:

> Florian Weimer wrote:
>> I would really like to see DT_NEEDED-based use cases for
>> symbol interposition.
>
> Well, there is the thread wrapper I wrote for the Ada Milter API to
> prevent Libgnat from leaking memory when Libmilter's threads terminate.
> I think what it does is this symbol interposition you guys were talking
> about. The advantage over LD_PRELOAD is that with the right combination
> of static and dynamic linking the library can take care of it all. The
> LD_PRELOAD solution must be done in the initscript or SystemD unit of
> each individual milter that links to the library.

I'm still unclear exactly what situations would count to suggest
examples, but it does look like the sort of thing that needs supporting
for HPC use.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F24 System Wide Change: NetworkManager 1.2

[Jan Kurik]

= Proposed System Wide Change: NetworkManager 1.2  =
https://fedoraproject.org/wiki/Changes/NetworkManager12

Change owner(s):
* Lubomir Rintel < lkundrak AT v3 DOT sk >

Update to NetworkManager to version 1.2

== Detailed Description ==
NetworkManager 1.2 will include significant changes and improvements:
* Port to GDBus
* New libnma library for GUIs
* New VPN services plugin API
* Support for multiple VPN connections with a single plugin
* VPN plugins ported to libnm & libnma
* CLI secret agent with support for VPN secrets
* Capability of editing VPN connections via the TUI interface
* Support for arbitrary software device (bond, bridge, vlan, team) hierarchy
* Support for managing container (LXC, Docker) connectivity
* RFC7217 stable privacy addressing
* CLI improvements, colors, significantly better command completion

== Scope ==
* Proposal owners: Update NetworkManager, connection editor and VPN
plugin packages.
* Other developers: We'll take care of porting the VPN property
plugins; the VPN plugin package maintainers should pull in the patches
or new upstream releases. The libnm-glib and libnm-gtk users (network
management tools in various desktop environments should port their
tools to libnm and libnma; but we're keeping the old libraries as
well.
* Release engineering: N/A (not needed for this Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)

-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Self Introduction: Dominique Martinet

[Dominique Martinet]

Hi,

I'm a developper/sysadmin at CEA, a French research institute, mainly
working on HPC clusters - both maintenance and designing new ones.

More specifically, I'm in the Storage team (tape/Lustre HSM we're proud
of), and have been working on Infiniband developments for a few years
now.
These developments include a RDMA helper lib, libmooshika[1], which
comes with a few utilities and is used by nfs-ganesha[2] for its 9P/RDMA
layer, and for which I've just submitted a package inclusion review
request:
https://bugzilla.redhat.com/show_bug.cgi?id=1268010


I'm also doing a bit more packaging for our clusters so I might be able
to lend a hand either co-maintaining products we use or taking a few
packages once I get an idea of how much time is required (I guess it
greatly depends on the packages themselves though)

-- 
Dominique Martinet
[1] https://github.com/martinetd/mooshika
[2] https://github.com/nfs-ganesha/nfs-ganesha
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf is completly broken

[Honza Šilhan]

> From: "Germano Massullo" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Sunday, October 4, 2015 5:43:42 PM
> Subject: Re: dnf is completly broken

:)

> Il 04/10/2015 16:32, Neal Gompa ha scritto:
> 
> 
> 
> On Sun, Oct 4, 2015 at 10:24 AM, Germano Massullo <
> germano.massu...@gmail.com > wrote:
> 
> 
> In past days I experienced the following problem
> "dnf install" exits if there is a non existing package in the requested
> packages list"
> https://bugzilla.redhat.com/show_bug.cgi?id=1268606
> 
> 
> ​Do you have "
> strict=True
> " in
> /etc/dnf/dnf.conf
> ?​
> No

Actually strict=True is default DNF behavior. You should add 
`--setopt=strict=False`
to your command line [1] if you wanna skip unavailable / broken packages.

Honza


[1] 
http://dnf.readthedocs.org/en/latest/conf_ref.html?highlight=strict#repo-options
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1197456
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: scriplet issues installing deps in f23 mock

[Miroslav Suchý]

Dne 30.9.2015 v 00:17 Cole Robinson napsal(a):
> I'm hitting scriplet errors when trying to build f23 qemu in mock on an up to
> date f23 host. Example:
> 
> $ mock --root fedora-23-x86_64 --init
> ...
> $ mock --root fedora-23-x86_64 --rebuild qemu-2.4.0-4.fc23.src.rpm
> ...
> 
> Transaction Summary
> 
> Install  48 Packages (+596 Dependent packages)
> 
> Total size: 396 M
> Installed size: 1.1 G
> Downloading packages:
> Running transaction check
> Running transaction test
> Transaction test succeeded
> Running transaction (shutdown inhibited)
> error: %prein(texlive-base-4:2014-13.20140525_r34255.fc23.noarch) scriptlet
> failed, exit status 126
> Error in PREIN scriptlet in rpm package
> 4:texlive-base-2014-13.20140525_r34255.fc23.noarch
>   Installing : 2:libpng-1.6.17-2.fc23.x86_64  
> 2/644
> error: texlive-base-4:2014-13.20140525_r34255.fc23.noarch: install failed
> warning: %post(libpng-2:1.6.17-2.fc23.x86_64) scriptlet failed, exit status 
> 126
> Non-fatal POSTIN scriptlet failure in rpm package 
> 2:libpng-1.6.17-2.fc23.x86_64
>   Installing : freetype-2.6.0-3.fc23.x86_64   
> 3/644
> warning: %post(freetype-2.6.0-3.fc23.x86_64) scriptlet failed, exit status 126
> Non-fatal POSTIN scriptlet failure in rpm package freetype-2.6.0-3.fc23.x86_64
>   Installing : xorg-x11-proto-devel-7.7-16.fc23.noarch


libpng just call ldconfig
texlive-base just remove one directory and return true
There is hardly something to fail.

I strongly suspect SELinux. It does not happen on my workstation (with SELinux 
disabled) and it does not happen on
freshly installed F22 machine with SELinux on.

Do you have something in audit.log?


-- 
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct