Re: Harden_all_packages_with_position-independent_code + guile modules

[Nikos Mavrogiannopoulos]

On Thu, 2015-03-12 at 10:41 -0400, Adam Jackson wrote:
> On Thu, 2015-03-12 at 13:45 +, Petr Pisar wrote:
> > On 2015-03-12, Nikos Mavrogiannopoulos  wrote:
> > > In rawhide building the gnutls guile bindings fails, and that's related
> > > to the new hardening flags being enabled with [0]. The failure is quite
> > > peculiar since the loading of a dynamic module fails [1] which already
> > > is position independent.
> > [...]
> > >
> > > [1]. https://bugzilla.redhat.com/show_bug.cgi?id=1196556
> > >
> > The test-suite.log reads "file not found" which is far from "loading DSO
> > failed".
> > 
> > However I can add my recent story: After hardening perl, loading a DSO
> > by perl failed. I believe the reason was the DSO had an undefined symbol
> > which was not defined in any SO_NEEDed libraries. But because the symbol
> > was never used at run-time, before hardening the executable, run-time
> > linking passed. But after hardening, the -znow feature caused resolving
> > all symbols at link time, including the missing symbol, so dlopen(3)
> > failed.
> 
> We may want to revisit this, honestly.  The actual proposal was just to
> build executables as PIE, right?  Forcing -z now is a bit more than
> maybe was expected.

What was the rationale of adding -z now to the hardening flags? Looking
its description doesn't reveal any "hardening" features, and the gnutls
guile module failure to build seems to be directly related to that flag:
https://bugzilla.redhat.com/show_bug.cgi?id=1196556

regards,
Nikos


-- 
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: Harden_all_packages_with_position-independent_code + guile modules

[Reindl Harald]

Am 16.03.2015 um 09:47 schrieb Nikos Mavrogiannopoulos:

What was the rationale of adding -z now to the hardening flags? Looking
its description doesn't reveal any "hardening" features, and the gnutls
guile module failure to build seems to be directly related to that flag:
https://bugzilla.redhat.com/show_bug.cgi?id=1196556


FULL RELRO

http://tk-blog.blogspot.co.at/2009/02/relro-not-so-well-known-memory.html



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: DNF and mock

[Miroslav Suchý]

On 03/15/2015 02:38 PM, Michael Schwendt wrote:
> Is DNF within Mock a fully compatible replacement for Yum yet?
> It seems builds take much longer now since something's downloading
> (or redownloading?) lots of data for each build job before setting
> up the buildroot. I don't have much time to look into it, bug shouldn't
> Mock's buildroot cache files be fresh enough to avoid redownloading
> packages, for example?

yum_cache plugin was not migrated to DNF yet. This can affect first build, but 
should not affect next builds.

-- 
Miroslav Suchy, RHCE, RHCDS
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: Harden_all_packages_with_position-independent_code + guile modules

[Nikos Mavrogiannopoulos]

On Mon, 2015-03-16 at 10:19 +0100, Reindl Harald wrote:
> 
> Am 16.03.2015 um 09:47 schrieb Nikos Mavrogiannopoulos:
> > What was the rationale of adding -z now to the hardening flags? Looking
> > its description doesn't reveal any "hardening" features, and the gnutls
> > guile module failure to build seems to be directly related to that flag:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1196556
> 
> FULL RELRO
> http://tk-blog.blogspot.co.at/2009/02/relro-not-so-well-known-memory.html

If that's all we got I suggest to remove this flag or (better) provide a
way for applications that use modules to compile themselves, without
removing the whole set of hardening flags.



-- 
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: Versioning preloader

[Christopher Meng]

On Mon, Mar 16, 2015 at 1:13 PM, Pranav Kant  wrote:
> I am packaging proxychains-ng[1] which make use of the .so file by its
> preloader only, and is not for any usable development. Hence, the
> upstream maintainer does not want[2] to version this .so file.
>
> To inhibit the rpmlint's unversioned so file warning, I have currently
> written a patch, and making use of it while packaging. But, I was
> wondering of any other alternatives that we might have here.
>
> Any ideas ? Or should I stick with the patch ?

Patch it to versioned is wrong beause this software will neither work
nor be dependency-clean. You should put it underneath
/usr/lib%{?__isa_bits}/%{name}, it's the common solution.

Yours sincerely,
Christopher Meng

http://cicku.me
-- 
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-22 Branched report: 20150316 changes

[Fedora Branched Report]

Compose started at Mon Mar 16 07:15:03 UTC 2015
Broken deps for armhfp
--
[Sprog]
Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0)
[aeskulap]
aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libofstd.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires liboflog.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libijg8.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libijg16.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libijg12.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libdcmnet.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libdcmjpeg.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libdcmimgle.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libdcmimage.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libdcmdata.so.3.6
[avro]
avro-mapred-1.7.5-9.fc22.noarch requires hadoop-mapreduce
avro-mapred-1.7.5-9.fc22.noarch requires hadoop-client
[bro]
broccoli-2.3-1.fc22.armv7hl requires bro-2.3
python-broccoli-2.3-1.fc22.armv7hl requires bro-2.3
[cvc4]
cvc4-1.3-7.fc22.armv7hl requires libboost_thread.so.1.55.0
cvc4-1.3-7.fc22.armv7hl requires libboost_system.so.1.55.0
[dnssec-check]
dnssec-check-1.14.0.1-4.fc20.armv7hl requires libval-threads.so.14
dnssec-check-1.14.0.1-4.fc20.armv7hl requires libsres.so.14
[dock]
dock-1.1.0-1.fc22.noarch requires python-docker-py
[gcc-python-plugin]
gcc-python2-debug-plugin-0.13-2.fc22.armv7hl requires gcc = 
0:4.9.2-1.fc22
gcc-python2-plugin-0.13-2.fc22.armv7hl requires gcc = 0:4.9.2-1.fc22
gcc-python3-debug-plugin-0.13-2.fc22.armv7hl requires gcc = 
0:4.9.2-1.fc22
gcc-python3-plugin-0.13-2.fc22.armv7hl requires gcc = 0:4.9.2-1.fc22
[gtranslator]
gtranslator-2.91.6-7.fc22.armv7hl requires libgdict-1.0.so.6
[kdetoys]
7:kdetoys-4.14.3-1.fc22.noarch requires ktux >= 0:4.14.3
[leksah]
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(utf8-string-0.3.7-013ef9ad8ac70ebb11df31f487b74f26)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(unix-2.6.0.1-7550b9ae9dbc74e4d6570cc239a29030)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(transformers-0.3.0.0-23508e0b4a1c1bc1cf2c2de3bb13e90c)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(time-1.4.0.1-970760bdd865d8b6cafac382276795a2)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(text-0.11.3.1-17cae9ba49c3f3d533bf78a6e387f543)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(strict-0.3.2-04f0cc1e99eff2196c0a7cd16d748b37)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(regex-tdfa-1.1.8-0b03687c4e38c00ef92e9445170081e2)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(regex-base-0.93.2-6a541a53412d1d7d310fa69bca50c85f)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(pretty-1.1.1.0-2de27f83b2c1c65d629a564e9e01b27d)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(parsec-3.1.3-a8bebef411959de671abb0f1f7da556f)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(old-time-1.1.0.1-29c02e2b3bbdfd9a5756f0c46f4d6071)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(network-2.4.1.2-82f6bcf79fe0252b3ab387e8dcb82e71)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(mtl-2.1.2-2f2cd438035824ec2bed4811930bc232)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(ltk-0.12.1.0-2fbb10498719be9dbdbb3d9f8adedbec)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(leksah-server-0.12.1.2-7dbd70c9f5e4dd8b3b5efcb6597b3bfd)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(hslogger-1.2.1-43834164508859009a3cc8aef7fd1e84)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(gtksourceview2-0.12.5.0-588b179d0562576f9afa46559cebf79f)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(gtk-0.12.5.0-2342a114ec8897cecfdda15ac92aed08)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(glib-0.12.5.0-1b94df160e141377711a221615168695)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(gio-0.12.5.0-b012293268f349d8f05c73d053798c7b)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(ghc-7.6.3-18fc786f8ad3478b9bb568d865b0e48d)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(filepath-1.3.0.1-62570c67b40fb99e7078c0d179220531)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(enumerator-0.4.19-a164f71ed1088e349dd8bc4cdee8e449)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(directory-1.2.0.1-504c99535d64699e20e001d81b577d06)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires

Re: DNF and mock

[Michael Šimáček]

On 2015-03-16 06:43, Mikolaj Izdebski wrote:

On 03/15/2015 02:38 PM, Michael Schwendt wrote:

On Thu, 22 Jan 2015 15:15:48 +0100, Miroslav Suchý wrote:


I just spoke with two members of DNF team about default usage of DNF in mock. I 
would like to share outcomes of this
meeting.

First I would like to state that you can already optionally use DNF in your 
mock by setting:
   config_opts['package_manager'] = 'dnf'


I've switched back to Yum for now.


I expect that we will be building Fedora 22- always by yum due to short Fedora 
life cycle. Yum will be still present in
Fedora 24 for sure.


Is DNF within Mock a fully compatible replacement for Yum yet?
It seems builds take much longer now since something's downloading
(or redownloading?) lots of data for each build job before setting
up the buildroot. I don't have much time to look into it, bug shouldn't
Mock's buildroot cache files be fresh enough to avoid redownloading
packages, for example?


Redownloading packages is DNF default setting [1], which you can adjust
in mock config. I personally use caching proxy to avoid this problem and
share packages between multiple chroots.


Configurations shipped with current mock have keepcache=1 by default, so 
the redownloading shouldn't happen if you have yum_cache enabled. But if 
you use different configs than the default ones, you'll need to adjust 
the config manually.


Technically, yum_cache wans't "ported" to dnf, but due to the similarity 
of the two package managers, if the cachedir is set to /var/cache/yum 
(which it is in the shipped configs), it should work without changes.


Michael Simacek



[1] http://dnf.readthedocs.org/en/latest/conf_ref.html#keepcache-label


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

[Bug 1202085] package is against epel policy

[bugzilla]

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

Andrea Veri  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |NOTABUG
Last Closed||2015-03-16 07:32:22



--- Comment #1 from Andrea Veri  ---
@Tuomo: make sure to assign the bug to the proper maintainer so that the issue
can be handled correctly. In this case Emmanuel (eseyman) was responsible for
the submitted update as per [1]. The update was however unpushed already.

[1] https://admin.fedoraproject.org/updates/perl-SOAP-Lite-0.716-4.el6

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=fGj1onB2Jn&a=cc_unsubscribe
--
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

[POC-change] Fedora packages point of contact updates

[nobody]

Change in package status over the last 168 hours


3 packages were orphaned

grads [f22, f21, f20, master, el6, epel7] was orphaned by orion
 Tool for easy acces, manipulation, and visualization of data
 https://admin.fedoraproject.org/pkgdb/package/grads
identicurse [f22, f21, f20, master] was orphaned by smilner
 Curses based Status.net client
 https://admin.fedoraproject.org/pkgdb/package/identicurse
ioprocess [f22, f21, f20, el6, master] was orphaned by kevin
 Slave process to perform risky IO
 https://admin.fedoraproject.org/pkgdb/package/ioprocess

52 packages were retired
-
TurboGears2 [el5] was retired by till
 Next generation front-to-back web development megaframework
 https://admin.fedoraproject.org/pkgdb/package/TurboGears2
bcfg2 [el5] was retired by till
 A configuration management system
 https://admin.fedoraproject.org/pkgdb/package/bcfg2
bodhi [el5] was retired by till
 A modular framework that facilitates publishing software updates
 https://admin.fedoraproject.org/pkgdb/package/bodhi
cmake-fedora [el5] was retired by till
 CMake helper modules for fedora developers
 https://admin.fedoraproject.org/pkgdb/package/cmake-fedora
fedora-easy-karma [el5] was retired by till
 Fedora update feedback made easy
 https://admin.fedoraproject.org/pkgdb/package/fedora-easy-karma
fedora-packager [el5] was retired by till
 Tools for setting up a fedora maintainer environment
 https://admin.fedoraproject.org/pkgdb/package/fedora-packager
func [el5] was retired by till
 Remote management framework
 https://admin.fedoraproject.org/pkgdb/package/func
ghc-attoparsec-conduit [f22] was retired by petersen
 Consume attoparsec parsers via conduit
 https://admin.fedoraproject.org/pkgdb/package/ghc-attoparsec-conduit
ghc-blaze-builder-conduit [f22] was retired by petersen
 Convert streams of builders to streams of bytestrings
 https://admin.fedoraproject.org/pkgdb/package/ghc-blaze-builder-conduit
ghc-network-conduit [f22] was retired by petersen
 Stream socket data using conduits
 https://admin.fedoraproject.org/pkgdb/package/ghc-network-conduit
ghc-zlib-conduit [f22] was retired by petersen
 Streaming compression and decompression conduits
 https://admin.fedoraproject.org/pkgdb/package/ghc-zlib-conduit
glances [el5] was retired by till
 CLI curses based monitoring tool
 https://admin.fedoraproject.org/pkgdb/package/glances
kcometen4 [f22, master] was retired by nucleo
 An OpenGL screensaver with exploding comets for KDE4
 https://admin.fedoraproject.org/pkgdb/package/kcometen4
kde-plasma-smooth-tasks [f22, master] was retired by slankes
 KDE taskbar replacement with window peeking ability
 https://admin.fedoraproject.org/pkgdb/package/kde-plasma-smooth-tasks
kde-plasma-yawp [f22, master] was retired by nucleo
 Yet Another Weather Plasmoid
 https://admin.fedoraproject.org/pkgdb/package/kde-plasma-yawp
lfsc [master] was retired by jjames
 SMT proof checker
 https://admin.fedoraproject.org/pkgdb/package/lfsc
orbited [el5] was retired by till
 A browser(javascript)->tcp bridge
 https://admin.fedoraproject.org/pkgdb/package/orbited
perl-SVK [el5] was retired by till
 A Distributed Version Control System
 https://admin.fedoraproject.org/pkgdb/package/perl-SVK
purple-microblog [master] was retired by olea
 Libpurple plug-in for Pidgin and others, supporting microblog services 
like Twitter
 https://admin.fedoraproject.org/pkgdb/package/purple-microblog
python-daemon [el5] was retired by till
 Library to implement a well-behaved Unix daemon process
 https://admin.fedoraproject.org/pkgdb/package/python-daemon
python-fedora [el5] was retired by till
 Python modules for talking to Fedora Infrastructure Services
 https://admin.fedoraproject.org/pkgdb/package/python-fedora
python-paver [el5] was retired by till
 Python-based build/distribution/deployment scripting tool
 https://admin.fedoraproject.org/pkgdb/package/python-paver
python-pygments [el5] was retired by till
 Syntax highlighting engine written in Python
 https://admin.fedoraproject.org/pkgdb/package/python-pygments
python-pylons [el5] was retired by till
 Pylons web framework
 https://admin.fedoraproject.org/pkgdb/package/python-pylons
python-repoze-what-pylons [el5] was retired by till
 A plugin providing utilities for Pylons applications using repoze.what
 https://admin.fedoraproject.org/pkgdb/package/python-repoze-what-pylons
python-sphinx [el5] was retired by till
 Python documentation generator
 https://admin.fedoraproject.org/pkgdb/package/python-sphinx
python-sphinx-theme-flask [el5] was retired by till
 Sphinx Themes for Flask related projects and Flask itself
 https://admin.fedoraproject.org/pkgdb/package/python-sphinx-theme-fl

Re: DNF and mock

[Mikolaj Izdebski]

On 03/16/2015 12:32 PM, Michael Šimáček wrote:
> Configurations shipped with current mock have keepcache=1 by default, so
> the redownloading shouldn't happen if you have yum_cache enabled. But if
> you use different configs than the default ones, you'll need to adjust
> the config manually.

Right. This is quite new change in mock and I didn't know about it
because I don't use default configs.

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

GNOME 3.15.92 megaupdate

[Kalev Lember]

Hi all,

GNOME 3.15.92 release is this week and I'll take care of handling the
megaupdate for F22. If you are doing any builds that should be included
in the megaupdate, please use 'fedpkg build --target f22-gnome'; I'll
pick up the builds in the side tag for the megaupdate.

Also, the usual spreadsheet can be useful if you want to add extra
bugzilla ticket numbers that should be listed as fixed by the Bodhi
update, or need to add extra builds that for some reason didn't end up
in the f22-gnome side tag.

https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzBuN2VxU0lxbHc&pli=1#gid=0

-- 
Thanks,
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: Reason why non-commiters are not allowed to create buildroot overrides?

[David Howells]

Susi Lehtola  wrote:

> The reason why buildroot overrides can't be made by anyone is that the
> maintainer might not want people to build packages against the new version, if
> for example it breaks things.

Should the broken new version be made unavailable in that case then?

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

Review swap: web-socket-js

[Jonathan Underwood]

Hi,

I am trying to get xpra into Fedora[1], and the only remaining issue
is unbundling of the java script library web-socket-js. I've put
together a package for thatand it's awaiting review [2]. It's a very
simple package, just installing a couple of js files, so should be
very simple to review. Is anyone willing to do a package review swap
for this package?

Cheers,
Jonathan.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1198312
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1199189
-- 
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: pcre2 review

[Petr Pisar]

On 2015-03-13, Petr Pisar  wrote:
> Do you like regular expressions? Do you like regular expressions which
> are not regular any more? Do you think PCRE library API looks like
> a zombie from previous milenium? Do you want to have a fresh new one in
> Fedora?
>
> Whatever your answer to these questions is, PCRE development team
> has already released 10th version of PCRE2 and corresponding package
> review  is waiting
> in the Bugzilla.
>
Thanks to everybody who helped of offered a help with the review. The
package is in F23 now.

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

F22 Self Contained Change: Disabled Repositories Support

[Jaroslav Reznik]

= Proposed Self Contained Change: Disabled Repositories Support =
https://fedoraproject.org/wiki/Changes/DisabledRepoSupport

Change owner(s): Richard Hughes 

The Software tool and PackageKit now support disabled repositories to help 
users locate software in additional repositories which are not meant to be 
enabled by default. 

* This Change is announced after the Change Submission Deadline as an
exception to the process. May not be approved for proposed Fedora release. *

== Detailed Description ==
This feature aims to reduce the technical hurdles for users and developers to 
locate software packaged for a distribution, but which needs to be clearly 
identified as not officially included (or possibly sanctioned) by that 
distribution.

When Software (via PackageKit) queries a repo definition that contains the line 
enabled_metadata=1, even if the repo is disabled, it will download repodata. 
This feature allows a user to locate software in response to a search. If the 
user wants to install the software, she receives a dialog with information 
that the repo must be enabled to satisfy the request, and if relevant, 
information about the nature of the software (for instance, if it is non-
libre).

N.B. This feature does not currently operate in Fedora, since no such repo 
definitions are currently shipped. However, the feature could be used by 
remixers, and in the future in Fedora in the event of a policy change. 

== Scope ==
* Proposal owners: Include enhancements in gnome-software/PackageKit (done)
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
** Note: For this feature to be used in Fedora requires an additional *-
release-extra package to ship disabled repo definition 
* Policies and guidelines: N/A (not a System Wide Change)
** Note: For this feature to be used in Fedora requires clearer approval from 
FESCo and the Council 

___
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

Re: F22 Self Contained Change: Disabled Repositories Support

[Sergio Pascual]

2015-03-16 15:52 GMT+01:00 Jaroslav Reznik :

> = Proposed Self Contained Change: Disabled Repositories Support =
> https://fedoraproject.org/wiki/Changes/DisabledRepoSupport
>
>
"Disabled Repositories Support" sounds better than "Help People Install
Non-Free Software in Fedora", but the result is the same.

Personally, I don't like it
-- 
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: F22 Self Contained Change: Disabled Repositories Support

[Ralf Corsepius]

On 03/16/2015 03:52 PM, Jaroslav Reznik wrote:


This feature aims to reduce the technical hurdles for users and developers to
locate software packaged for a distribution, but which needs to be clearly
identified as not officially included (or possibly sanctioned) by that
distribution.


Does this mean Fedora is going to ship repository configs for these 
"unpronounceable repos".


In the past we had been told this wasn't possible for legal reasons.

Ralf

--
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: F22 Self Contained Change: Disabled Repositories Support

[Dennis Gilmore]

On Monday, March 16, 2015 04:36:40 PM Ralf Corsepius wrote:
> On 03/16/2015 03:52 PM, Jaroslav Reznik wrote:
> > This feature aims to reduce the technical hurdles for users and developers
> > to locate software packaged for a distribution, but which needs to be
> > clearly identified as not officially included (or possibly sanctioned) by
> > that distribution.
> 
> Does this mean Fedora is going to ship repository configs for these
> "unpronounceable repos".
> 
> In the past we had been told this wasn't possible for legal reasons.
> 
> Ralf

No that is not going to happen, the repos in Question are copr repos

Dennis
-- 
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: F22 Self Contained Change: Disabled Repositories Support

[Stephen Gallagher]

On Mon, 2015-03-16 at 16:22 +0100, Sergio Pascual wrote:
> 
> 2015-03-16 15:52 GMT+01:00 Jaroslav Reznik :
> > = Proposed Self Contained Change: Disabled Repositories Support =
> > https://fedoraproject.org/wiki/Changes/DisabledRepoSupport
> > 
> "Disabled Repositories Support" sounds better than "Help People 
> Install Non-Free Software in Fedora", but the result is the same.
> 
> Personally, I don't like it
That's not all it is potentially usable for. For example, at last 
Wednesday's FESCo meeting, we gave GNOME Software permission to use 
this functionality to point at a curated set of COPR repositories. 
These are all free software, just with a lower standard of packaging. 
That's a perfectly sound use of this feature, I would say.


signature.asc
Description: This is a digitally signed message part
-- 
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: F22 Self Contained Change: Disabled Repositories Support

[Ralf Corsepius]

On 03/16/2015 04:49 PM, Dennis Gilmore wrote:

On Monday, March 16, 2015 04:36:40 PM Ralf Corsepius wrote:

On 03/16/2015 03:52 PM, Jaroslav Reznik wrote:

This feature aims to reduce the technical hurdles for users and developers
to locate software packaged for a distribution, but which needs to be
clearly identified as not officially included (or possibly sanctioned) by
that distribution.


Does this mean Fedora is going to ship repository configs for these
"unpronounceable repos".

In the past we had been told this wasn't possible for legal reasons.

Ralf


No that is not going to happen, the repos in Question are copr repos


OK, in this case, I do not see any sense in this request - It's a waste 
of time and resources.


Ralf


--
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: F22 Self Contained Change: Disabled Repositories Support

[Josh Boyer]

On Mar 16, 2015 12:23 PM, "Ralf Corsepius"  wrote:
>
> On 03/16/2015 04:49 PM, Dennis Gilmore wrote:
>>
>> On Monday, March 16, 2015 04:36:40 PM Ralf Corsepius wrote:
>>>
>>> On 03/16/2015 03:52 PM, Jaroslav Reznik wrote:

 This feature aims to reduce the technical hurdles for users and
developers
 to locate software packaged for a distribution, but which needs to be
 clearly identified as not officially included (or possibly sanctioned)
by
 that distribution.
>>>
>>>
>>> Does this mean Fedora is going to ship repository configs for these
>>> "unpronounceable repos".
>>>
>>> In the past we had been told this wasn't possible for legal reasons.
>>>
>>> Ralf
>>
>>
>> No that is not going to happen, the repos in Question are copr repos
>
>
> OK, in this case, I do not see any sense in this request - It's a waste
of time and resources.

The work is already done and has no impact on the wider package maintainer
set.  The Change is simply informational.

josh
-- 
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: F22 Self Contained Change: Disabled Repositories Support

[Ralf Corsepius]

On 03/16/2015 05:26 PM, Josh Boyer wrote:


On Mar 16, 2015 12:23 PM, "Ralf Corsepius" mailto:rc040...@freenet.de>> wrote:
 >
 > On 03/16/2015 04:49 PM, Dennis Gilmore wrote:
 >>
 >> On Monday, March 16, 2015 04:36:40 PM Ralf Corsepius wrote:
 >>>
 >>> On 03/16/2015 03:52 PM, Jaroslav Reznik wrote:
 
  This feature aims to reduce the technical hurdles for users and
developers
  to locate software packaged for a distribution, but which needs to be
  clearly identified as not officially included (or possibly
sanctioned) by
  that distribution.
 >>>
 >>>
 >>> Does this mean Fedora is going to ship repository configs for these
 >>> "unpronounceable repos".
 >>>
 >>> In the past we had been told this wasn't possible for legal reasons.
 >>>
 >>> Ralf
 >>
 >>
 >> No that is not going to happen, the repos in Question are copr repos
 >
 >
 > OK, in this case, I do not see any sense in this request - It's a
waste of time and resources.

The work is already done and has no impact on the wider package
maintainer set.

This only means you already wasted time and resources.


 The Change is simply informational.

a) This change impacts users, while these COPRs are not useful to them.
b) According to Mr. Gallagher, these COPRs and this change serve to 
establish his vision of a 2-class society - Sorry, but you don't really 
want to know what I think of this.


--
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: F22 Self Contained Change: Disabled Repositories Support

[Josh Boyer]

On Mon, Mar 16, 2015 at 12:50 PM, Ralf Corsepius  wrote:
> On 03/16/2015 05:26 PM, Josh Boyer wrote:
>>
>>
>> On Mar 16, 2015 12:23 PM, "Ralf Corsepius" > > wrote:
>>  >
>>  > On 03/16/2015 04:49 PM, Dennis Gilmore wrote:
>>  >>
>>  >> On Monday, March 16, 2015 04:36:40 PM Ralf Corsepius wrote:
>>  >>>
>>  >>> On 03/16/2015 03:52 PM, Jaroslav Reznik wrote:
>>  
>>   This feature aims to reduce the technical hurdles for users and
>> developers
>>   to locate software packaged for a distribution, but which needs to
>> be
>>   clearly identified as not officially included (or possibly
>> sanctioned) by
>>   that distribution.
>>  >>>
>>  >>>
>>  >>> Does this mean Fedora is going to ship repository configs for these
>>  >>> "unpronounceable repos".
>>  >>>
>>  >>> In the past we had been told this wasn't possible for legal reasons.
>>  >>>
>>  >>> Ralf
>>  >>
>>  >>
>>  >> No that is not going to happen, the repos in Question are copr repos
>>  >
>>  >
>>  > OK, in this case, I do not see any sense in this request - It's a
>> waste of time and resources.
>>
>> The work is already done and has no impact on the wider package
>> maintainer set.
>
> This only means you already wasted time and resources.

That is your opinion.  The opinion of the people that did the work differs.

>>  The Change is simply informational.
>
> a) This change impacts users, while these COPRs are not useful to them.

There are no COPR repo files that are installed by default today,
which means none of them use this mechanism yet.  Which means there is
literally no change for any user at this time.  As I said, the Change
is informational.

If such repo files are installed by default, it will be at the
discretion of the various Working Groups not the Change proposer.

> b) According to Mr. Gallagher, these COPRs and this change serve to
> establish his vision of a 2-class society - Sorry, but you don't really want
> to know what I think of this.

Stephen isn't the Change proposer, nor did he request the Change to be
developed.  However, you are correct in that I don't want to know what
you think of this.

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

Postfix - switching to dynamically loaded database plugins

[Jaroslav Skarvada]

Hi,

dynamically loaded database plugins has been supported in Debian
by downstream patch for a while. This patch went finally upstream,
so I am also introducing this feature in Fedora Rawhide (f23).

Previously, all database map support libraries were linked to the Postfix
binary, which required careful downstream selection of what libraries
to support and link. For users there was no way how to remove the
unneeded dependencies from the Postfix package (not counting
recompilation).

With the recent Postfix change (since postfix-3.0.0-4.fc23), users can
choose database maps they want by simply installing appropriate
Postfix subpackage(s). This also allows us to support more types of
database maps without adding additional dependencies to the Postfix base
package.

The following Postfix subpackages were introduced in Rawhide:

postfix-cdb
postfix-ldap
postfix-mysql
postfix-pcre
postfix-pgsql
postfix-sqlite

For users upgrading Postfix package in Rawhide it effectively means
that they need to install subpackages for all database maps they
use. E.g. if they use MySQL and LDAP maps, they need to install
postfix-mysql and postfix-ldap subpackages in addition to the
base Postfix package, otherwise their postfix setup will not work
correctly.

I will probably propose f23 Change for this feature later

thanks & regards

Jaroslav
-- 
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: Harden_all_packages_with_position-independent_code + guile modules

[Adam Jackson]

On Fri, 2015-03-13 at 12:14 +0100, Florian Weimer wrote:
> On 03/12/2015 03:41 PM, Adam Jackson wrote:
> 
> > We may want to revisit this, honestly.  The actual proposal was just to
> > build executables as PIE, right?  Forcing -z now is a bit more than
> > maybe was expected.
> 
> People tell conflicting things about PIE.  I have asked essentially the
> same thing, and I was told, no, PIE itself alters symbol resolution.  Is
> this true or not?

PIE does alter symbol resolution, though not in a particularly big way.
In a normal executable, taking the address of a global function takes
the address of the definition found in the executable itself, if any; in
a PIE, you take the address of the first definition found by the runtime
linker.  Normally that's not a correctness issue since the executable
usually ends up as the first object searched, but it does mean an
LD_PRELOAD can override more symbols than it used to because the
(now-PIE) executable is importing more symbols than before.

- ajax

-- 
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: Harden_all_packages_with_position-independent_code + guile modules

[Jakub Jelinek]

On Mon, Mar 16, 2015 at 01:24:19PM -0400, Adam Jackson wrote:
> On Fri, 2015-03-13 at 12:14 +0100, Florian Weimer wrote:
> > On 03/12/2015 03:41 PM, Adam Jackson wrote:
> > 
> > > We may want to revisit this, honestly.  The actual proposal was just to
> > > build executables as PIE, right?  Forcing -z now is a bit more than
> > > maybe was expected.
> > 
> > People tell conflicting things about PIE.  I have asked essentially the
> > same thing, and I was told, no, PIE itself alters symbol resolution.  Is
> > this true or not?
> 
> PIE does alter symbol resolution, though not in a particularly big way.
> In a normal executable, taking the address of a global function takes
> the address of the definition found in the executable itself, if any; in
> a PIE, you take the address of the first definition found by the runtime
> linker.  Normally that's not a correctness issue since the executable
> usually ends up as the first object searched, but it does mean an
> LD_PRELOAD can override more symbols than it used to because the
> (now-PIE) executable is importing more symbols than before.

???  PIE is the first object in symbol search scope, before LD_PRELOAD,
identically to normal executables.

Jakub
-- 
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: F22 Self Contained Change: Disabled Repositories Support

[Mike Pinkerton]

On 16 Mar 2015, at 12:57, Josh Boyer wrote:

a) This change impacts users, while these COPRs are not useful to  
them.


There are no COPR repo files that are installed by default today,
which means none of them use this mechanism yet.  Which means there is
literally no change for any user at this time.  As I said, the Change
is informational.

If such repo files are installed by default, it will be at the
discretion of the various Working Groups not the Change proposer.


Why would an official "product" want to endorse "unofficial" repos?

If the working group deems the software to be that useful, wouldn't  
it be better to bring its packaging up to the quality of the  
"official" Fedora repo, and make it more easily discoverable by all  
Fedora users, regardless of whether they choose to use that "product"  
or a spin or a "non-product" install of Fedora?


Just asking what the thinking is here ...

--
Mike

--
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: ImageMagick update to 6.9.0-9. So-name bump: libMagick++-6.Q16.so.3 -> libMagick++-6.Q16.so.6

[Pavel Alexeev]

15.03.2015 16:57, Michael Schwendt пишет:
> On Tue, 10 Mar 2015 14:49:28 +0100, Ralf Corsepius wrote:
>
>> Right now, many issues/problems are interacting and affecting packages 
>> simultanously, which occasionally render fixing these issues quite 
>> complicated.
>>
>> So far I've hit:
>> - GCC-5.0
>> - "Hardening"
>> - boost upgrade
>> - ImageMagick
>> - autotool upgrade.
>>
>> Openly said, the situation on f23 is a mess.
> Agreed. People run into failed builds, find out that a lib needs a rebuild
> because of GCC C++ ABI issues. After the rebuild, runtime linking fails for
> other dependencies, and they need a rebuild, too. This is non-trivial (and
> dangerous) for larger dep-chains in the distribution. I'm also not sure how
> many packagers even run Rawhide instead of F22 testing.
The main question should it be done in such manner? May be it have worth
run at least off-tree (without commits and versions bump) mass rebuild?
It allow estimate amount of broken packages and see dependencies. Do we
have resources to do so?

-- 
With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact
with me use jabber: hubbi...@jabber.ru
-- 
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: F22 Self Contained Change: Disabled Repositories Support

[Stephen Gallagher]

On Mon, 2015-03-16 at 13:48 -0400, Mike Pinkerton wrote:
> On 16 Mar 2015, at 12:57, Josh Boyer wrote:
> 
> > > a) This change impacts users, while these COPRs are not useful 
> > > to   them.
> > 
> > There are no COPR repo files that are installed by default today, 
> > which means none of them use this mechanism yet.  Which means 
> > there is literally no change for any user at this time.  As I 
> > said, the Change is informational.
> > 
> > If such repo files are installed by default, it will be at the 
> > discretion of the various Working Groups not the Change proposer.
> 
> Why would an official "product" want to endorse "unofficial" repos?
> 
> If the working group deems the software to be that useful, wouldn't  
> it be better to bring its packaging up to the quality of the   
> "official" Fedora repo, and make it more easily discoverable by all  
> Fedora users, regardless of whether they choose to use that 
> "product"   or a spin or a "non-product" install of Fedora?
> 
> Just asking what the thinking is here ...
> 


One representative example would be software that is extremely useful 
to a large group of people but whose packaging is a nightmare. For 
example, a great many people enjoy the Chromium repository in COPR. 
Due to Google's upstream practices, it's basically impossible to get 
it to meet Fedora's packaging policies. However, Google as an upstream 
is at least responsive enough that it can be trusted to close security 
issues in a timely basis. With that in mind, is it worth introducing 
barriers to our users from installing Chromium simply because of 
packaging problems?

I'd say this is a fair case.

Other examples might be preview releases of certain software that are 
not yet stable enough to be in Fedora proper or whose installation 
might be too disruptive during a stable lifecycle. Like for example 
the recent GNOME 3.12 repositories for Fedora 20 users since we had 
the long cycle.


signature.asc
Description: This is a digitally signed message part
-- 
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: Harden_all_packages_with_position-independent_code + guile modules

[Adam Jackson]

On Mon, 2015-03-16 at 18:31 +0100, Jakub Jelinek wrote:
> On Mon, Mar 16, 2015 at 01:24:19PM -0400, Adam Jackson wrote:
> > On Fri, 2015-03-13 at 12:14 +0100, Florian Weimer wrote:
> > PIE does alter symbol resolution, though not in a particularly big way.
> > In a normal executable, taking the address of a global function takes
> > the address of the definition found in the executable itself, if any; in
> > a PIE, you take the address of the first definition found by the runtime
> > linker.  Normally that's not a correctness issue since the executable
> > usually ends up as the first object searched, but it does mean an
> > LD_PRELOAD can override more symbols than it used to because the
> > (now-PIE) executable is importing more symbols than before.
> 
> ???  PIE is the first object in symbol search scope, before LD_PRELOAD,
> identically to normal executables.

Yeah, sorry, I was reading readelf's output wrong.  Those symbols get
emitted as relocations (where they wouldn't for an executable), but they
resolve to the providing object.  My error, I apologize.

- ajax

-- 
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: F22 Self Contained Change: Disabled Repositories Support

[Michael Catanzaro]

On Mon, 2015-03-16 at 15:25 -0400, Stephen Gallagher wrote:
> Other examples might be preview releases of certain software that are 
> not yet stable enough to be in Fedora proper or whose installation 
> might be too disruptive during a stable lifecycle. Like for example 
> the recent GNOME 3.12 repositories for Fedora 20 users since we had 
> the long cycle.

This is a bad example IMO. We are not set up to handle coprs that
include essential system packages. If you try to remove the gnome-3.12
copr with gnome-software, it just uninstalls your desktop environment
and leaves you with a broken computer.

Installing a single application that's not in Fedora from a copr is one
thing, or a newer version of an application, but not if they are core
system packages.

-- 
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: F22 Self Contained Change: Disabled Repositories Support

[Diogo Campos (gmail)]

One representative example would be software that is extremely useful
to a large group of people but whose packaging is a nightmare. For
example, a great many people enjoy the Chromium repository in COPR.


Probably Brackets [1] is a good candidate too. And Atom [2]. Both 
already are in the COPRs.

[1] http://brackets.io/
[2] https://atom.io/

---

Additionally: maybe move all (and/or add new) games to a dedicated COPR 
could be useful too. Could serve as a testing ground for separation of 
repos and policies, and as a incentive to have new games packaged for 
Fedora. The cool thing about this is that it seems like a simple and 
automatic implementation of the "Rings thing" discussed in another 
thread.


If above is successful, in a longer term thing: maybe move all the 
(graphical?) apps to a "Fedora Apps COPR" which uses the libs from the 
"Official Fedora Repos" to kinda mold and prepare Fedora for the 
Runtime/Sandbox/Apps future?
-- 
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: Reason why non-commiters are not allowed to create buildroot overrides?

[Rex Dieter]

David Howells wrote:

> Susi Lehtola  wrote:
> 
>> The reason why buildroot overrides can't be made by anyone is that the
>> maintainer might not want people to build packages against the new
>> version, if for example it breaks things.
> 
> Should the broken new version be made unavailable in that case then?

Technically, it's not generally available until the maintainer submits an 
update for it.

-- Rex

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

[Michael Schwendt]

On Mon, 16 Mar 2015 12:32:41 +0100, Michael Šimáček wrote:

> Configurations shipped with current mock have keepcache=1 by default, so 
> the redownloading shouldn't happen if you have yum_cache enabled. But if 
> you use different configs than the default ones, you'll need to adjust 
> the config manually.

It's the default with a local buildroot override repo added (cost=0 and
metadata_expire=0). That has worked flawlessly for several years.

I've tried to take a look at it a few times with extra Mock runs. The "dnf
update" step for the Rawhide build target has been choking while downloading
metadata from very slow mirrors as well as downloading up to 176 packages
before the builddeps step. For every build job. When I interrupted everything
and restarted from scratch, it repopulated the buildroot cache and did not
download any updates anymore for subsequent build jobs. I'm puzzled. Could it
be that we've been assigned to a semi-broken set of rawhide mirrors for
some time?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

unable to get new certificate?

[Neal Becker]

fedora-packager-setup 
Setting up Fedora packager environment
Certificate has expired, getting a new one
FAS Password: 
[... silence ]

Seems to just hang

-- 
Those who fail to understand recursion are doomed to repeat it

-- 
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: unable to get new certificate?

[Kevin Fenzi]

On Mon, 16 Mar 2015 18:57:32 -0400
Neal Becker  wrote:

> fedora-packager-setup 
> Setting up Fedora packager environment
> Certificate has expired, getting a new one
> FAS Password: 
> [... silence ]
> 
> Seems to just hang

Are you behind a web proxy? If you wait a few minutes does it say
anything?

kevin




pgp84TRT7CoZl.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: unable to get new certificate?

[Neal Becker]

Kevin Fenzi wrote:

> On Mon, 16 Mar 2015 18:57:32 -0400
> Neal Becker  wrote:
> 
>> fedora-packager-setup
>> Setting up Fedora packager environment
>> Certificate has expired, getting a new one
>> FAS Password:
>> [... silence ]
>> 
>> Seems to just hang
> 
> Are you behind a web proxy? If you wait a few minutes does it say
> anything?
> 
> kevin
Not behind a proxy.  It did eventually work - it took a LONG time - like 10 
minutes.

-- 
Those who fail to understand recursion are doomed to repeat it

-- 
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: ImageMagick update to 6.9.0-9. So-name bump: libMagick++-6.Q16.so.3 -> libMagick++-6.Q16.so.6

[Kevin Fenzi]

On Mon, 16 Mar 2015 21:02:25 +0300
Pavel Alexeev  wrote:

> The main question should it be done in such manner? May be it have
> worth run at least off-tree (without commits and versions bump) mass
> rebuild? It allow estimate amount of broken packages and see
> dependencies. Do we have resources to do so?

I was hoping to run a rebuild in copr on our new cloud (which would
help this and also help make sure the new cloud is running ok). 

We will see how long such a rebuild will take and if it's not too long
run it. 

kevin



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