Re: Looking for new maintainer: ownCloud (Fedora / EPEL)

[Pierre-Yves Chibon]

On Mon, Aug 31, 2015 at 01:17:56AM +0200, Matěj Cepl wrote:
> On 2015-08-29, 21:27 GMT, Adam Williamson wrote:
> > Hi, folks. So I've been maintaining ownCloud for the last little
> > while. Unfortunately I sat down today to try again and update the
> > package to the latest upstream (8.1.1), and somewhere in the second
> > hour of insanely stupid PHP autoloader code, I just snapped. I can't
> > take this crap any more.
> 
> Hi, Adam,
> 
> thank you very much for your effort! Whatever future holds, you 
> have made it possible to run ownCloud on RHEL with more or less 
> working setup. THANK YOU!
> 
> > I'm very sorry to folks who are using it, but I really can't deal with
> > the crap any more. If all you need is calendar/contact sync, there are
> > easier ways. Check out Radicale or something like it.
> 
> Of course, if Radicale works for you, gnu be with you and go for 
> it! That’s all what really matters. However, let me add a word 
> of warning for others, because it doesn’t have to work for 
> everybody:
> 
> * Radicale (https://github.com/Kozea/Radicale) is a tiny project 
> with a five and half substantial (more than 10 commits) 
> committers (the half is for "System User"), huge majority of 
> them (534, next in the order 26) by one commiter. There is 
> nothing wrong with a project like that, but it has some 
> consequences.
> 
> * Radicale does not and will not support full Ca*DAV specs and 
> it seems to be "works for me" level of support and there doesn't 
> seem to be much effort to fix issues which the maintainer is not 
> interested in.  So for example, Thunderbird/SOGO DOES NOT work 
> (creates a duplicate items in the addressbook and calendar) and 
> the issue seems to be open since 2013 
> (https://github.com/Kozea/Radicale/issues/42).
> 
> Again, if it works for Adam (or anybody else) it is awesome, but 
> I would strongly discourage anybody who is not willing to invest 
> substntial amount of a sweat equity from packaging the package 
> for Fedora/EPEL.

Not entirely sure if you meant packaging radicale, but if that is the case,
radicale is already packaged in Fedora and epel 6 and 7.

Pierre
-- 
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 output to STDOUT/STDERR

[Michal Luscon]

Would you mind filling a proper bugzilla report on bugzilla.redhat.com?

Regards,

Michal Luscon


On 08/31/2015 08:16 AM, Joachim Backes wrote:
Some dnf messages are not relevant me, so I redirect STDERR to 
/dev/null if using dnf. But this has the disadvantage the the prompt 
"Is this ok [y/N]:" gets lost too. Obviously it is written to STDERR.


So my proposal for dnf: write the prompt "Is this ok [y/N]:" to STDOUT 
and not to STDERR.


Kind regards

Joachim Backes


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

[Test-Announce] Proposal to CANCEL: 2015-08-31 Fedora QA Meeting

[Adam Williamson]

Hi folks! Sorry for the late notice, but I'm proposing we cancel
Monday's QA meeting. I don't think there's anything major that needs
discussing - we all know where we are on Beta testing, I guess.

If anyone can think of something urgent to discuss, please reply to
this mail and we can get together at the usual time (15:00 UTC in
#fedora-meeting).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net


___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-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

GNOME 3.17.91 megaupdate

[Kalev Lember]

Hi all,

Just a quick heads up that it's GNOME 3.17.91 release this week and we
are still using the f23-gnome side tag for builds - please use 'fedpkg
build --target f23-gnome' if you are helping with builds.

I'll take care of submitting them all in a single bodhi update ticket
later this week.

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: dnf output to STDOUT/STDERR

[Joachim Backes]

On 31.08.2015 09:54, Michal Luscon wrote:

Would you mind filling a proper bugzilla report on bugzilla.redhat.com?

Regards,

Michal Luscon


On 08/31/2015 08:16 AM, Joachim Backes wrote:

Some dnf messages are not relevant to me, so I redirect STDERR to
/dev/null if using dnf. But this has the disadvantage the the prompt
"Is this ok [y/N]:" gets lost too. Obviously it is written to STDERR.

So my proposal for dnf: write the prompt "Is this ok [y/N]:" to STDOUT
and not to STDERR.

Kind regards

Joachim Backes




Did it: https://bugzilla.redhat.com/show_bug.cgi?id=1258364

--

Fedora release 23 (Twenty Three)
Kernel-4.2.0-0.rc8.git3.1.fc23.x86_64


Joachim Backes 
https://www-user.rhrk.uni-kl.de/~backes
--
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: Looking for new maintainer: ownCloud (Fedora / EPEL)

[Matěj Cepl]

On 2015-08-31, 07:05 GMT, Pierre-Yves Chibon wrote:
>> Again, if it works for Adam (or anybody else) it is awesome, but
>> I would strongly discourage anybody who is not willing to invest
>> substntial amount of a sweat equity from packaging the package
>> for Fedora/EPEL.
>
> Not entirely sure if you meant packaging radicale, but if that is the case,
> radicale is already packaged in Fedora and epel 6 and 7.

OK, perhaps I was more afraid that many people will read Adam’s 
email as “ownCloud is crap, Radicale rulez, let’s jump on that 
wagon everybody!”. Radicale is a minefield, and if your path 
happens to avoid the disaster than you may feel it works well.  
However, one step from the safe path and you are doomed (e.g., 
using Thunderbird).

Best,

Matěj

-- 
http://www.ceplovi.cz/matej/, Jabber: mc...@ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
 
SCSI is *not* magic. There are *fundamental* *technical*
reasons why you have to sacrifice a young goat to your SCSI
chain every now and then.
-- John F. Woods

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

rawhide report: 20150831 changes

[Fedora Rawhide Report]

Compose started at Mon Aug 31 05:15:03 UTC 2015
Broken deps for i386
--
[ScientificPython]
ScientificPython-2.8-20.fc22.i686 requires libmpi.so.1
[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)
[aws]
aws-tools-2015-2.fc23.i686 requires libaws_ssl.so
[blender]
1:blender-2.75-4.fc24.i686 requires libjemalloc.so.1
1:blenderplayer-2.75-4.fc24.i686 requires libjemalloc.so.1
[bro]
bro-2.3.2-6.fc23.i686 requires libjemalloc.so.1
[calligra]
calligra-kexi-map-form-widget-2.9.6-7.fc24.i686 requires 
libmarblewidget.so.21
calligra-reports-map-element-2.9.6-7.fc24.i686 requires 
libmarblewidget.so.21
calligra-semanticitems-2.9.6-7.fc24.i686 requires libmarblewidget.so.21
[cego]
cego-2.20.21-3.fc23.i686 requires liblfcbase.so.1
[dpm-contrib-admintools]
dpm-contrib-admintools-0.2.1-6.fc23.i686 requires MySQL-python(x86-32)
[dpm-dsi]
dpm-dsi-1.9.5-7.fc24.i686 requires globus-gridftp-server-progs(x86-32) 
= 0:8.1
[ghc-citeproc-hs]
ghc-citeproc-hs-0.3.9-6.fc23.i686 requires libHSxml-1.3.13-ghc7.8.4.so
ghc-citeproc-hs-0.3.9-6.fc23.i686 requires 
ghc(xml-1.3.13-62bfe61c33b8015ab0b36aed75278ed2)
ghc-citeproc-hs-devel-0.3.9-6.fc23.i686 requires 
ghc-devel(xml-1.3.13-62bfe61c33b8015ab0b36aed75278ed2)
[ghc-hakyll]
ghc-hakyll-4.5.4.0-3.fc23.i686 requires libHSxml-1.3.13-ghc7.8.4.so
[ghc-scotty]
ghc-scotty-0.9.0-3.fc23.i686 requires 
libHSstringsearch-0.3.6.5-ghc7.8.4.so
ghc-scotty-0.9.0-3.fc23.i686 requires 
ghc(wai-extra-3.0.4.5-71421e9684582df3095add7548e2ff46)
ghc-scotty-devel-0.9.0-3.fc23.i686 requires 
ghc-devel(wai-extra-3.0.4.5-71421e9684582df3095add7548e2ff46)
[ghc-texmath]
ghc-texmath-0.8.0.1-3.fc23.i686 requires libHSxml-1.3.13-ghc7.8.4.so
ghc-texmath-0.8.0.1-3.fc23.i686 requires 
ghc(xml-1.3.13-62bfe61c33b8015ab0b36aed75278ed2)
ghc-texmath-devel-0.8.0.1-3.fc23.i686 requires 
ghc-devel(xml-1.3.13-62bfe61c33b8015ab0b36aed75278ed2)
[gnatcoll]
gnatcoll-2014-4.fc23.i686 requires libgtkada-3.8.so.2
[golang-github-kraman-libcontainer]
golang-github-kraman-libcontainer-devel-0-0.4.gitd700e5b.fc24.noarch 
requires golang(github.com/docker/docker/pkg/netlink)
[golang-github-prometheus-prometheus]
golang-github-prometheus-prometheus-devel-0.15.0-1.fc24.noarch requires 
golang(gopkg.in/fsnotify.v1)
[gtksourceview-sharp]
gtksourceview-sharp-2.0.12-24.fc23.i686 requires gtksourceview
[hadoop]
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-servlet)
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
hadoop-hdfs-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-hdfs-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core)
hadoop-mapreduce-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-mapreduce-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey.contribs:jersey-guice)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-servlet)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-client)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey.contribs:jersey-guice)
hadoop-yarn-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-json)
hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core)
hadoop-yarn-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-client)
hadoop-yarn-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey.contribs:jersey-guice)
[hawaii-shell]
hawaii-shell-0.3.0-3.fc22.i686 requires 
libqtaccountsservice-qt5.so.0.1.2
[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)
[hledger]
ghc-hledger-0.24-1.fc23.i686 requires libHSwizards-1.0.1-ghc7.8.4.s

F-23 Branched report: 20150831 changes

[Fedora Branched Report]

Compose started at Mon Aug 31 07:15:04 UTC 2015
Broken deps for armhfp
--
[GMT]
GMT-5.1.2-1.fc23.armv7hl requires libgdal.so.1
[ScientificPython]
ScientificPython-2.8-20.fc22.armv7hl requires libmpi.so.1
[airinv]
airinv-1.00.1-4.fc23.armv7hl requires libboost_system.so.1.57.0
airinv-1.00.1-4.fc23.armv7hl requires libboost_serialization.so.1.57.0
airinv-1.00.1-4.fc23.armv7hl requires libboost_regex.so.1.57.0
airinv-1.00.1-4.fc23.armv7hl requires libboost_random.so.1.57.0
airinv-1.00.1-4.fc23.armv7hl requires libboost_python.so.1.57.0
airinv-1.00.1-4.fc23.armv7hl requires libboost_program_options.so.1.57.0
airinv-1.00.1-4.fc23.armv7hl requires libboost_locale.so.1.57.0
airinv-1.00.1-4.fc23.armv7hl requires libboost_iostreams.so.1.57.0
airinv-1.00.1-4.fc23.armv7hl requires libboost_filesystem.so.1.57.0
airinv-1.00.1-4.fc23.armv7hl requires libboost_date_time.so.1.57.0
[airrac]
airrac-1.00.1-3.fc23.armv7hl requires libboost_system.so.1.57.0
airrac-1.00.1-3.fc23.armv7hl requires libboost_serialization.so.1.57.0
airrac-1.00.1-3.fc23.armv7hl requires libboost_regex.so.1.57.0
airrac-1.00.1-3.fc23.armv7hl requires libboost_random.so.1.57.0
airrac-1.00.1-3.fc23.armv7hl requires libboost_python.so.1.57.0
airrac-1.00.1-3.fc23.armv7hl requires libboost_program_options.so.1.57.0
airrac-1.00.1-3.fc23.armv7hl requires libboost_locale.so.1.57.0
airrac-1.00.1-3.fc23.armv7hl requires libboost_iostreams.so.1.57.0
airrac-1.00.1-3.fc23.armv7hl requires libboost_filesystem.so.1.57.0
airrac-1.00.1-3.fc23.armv7hl requires libboost_date_time.so.1.57.0
[airtsp]
airtsp-1.01.2-3.fc23.armv7hl requires libboost_system.so.1.57.0
airtsp-1.01.2-3.fc23.armv7hl requires libboost_serialization.so.1.57.0
airtsp-1.01.2-3.fc23.armv7hl requires libboost_regex.so.1.57.0
airtsp-1.01.2-3.fc23.armv7hl requires libboost_random.so.1.57.0
airtsp-1.01.2-3.fc23.armv7hl requires libboost_python.so.1.57.0
airtsp-1.01.2-3.fc23.armv7hl requires libboost_program_options.so.1.57.0
airtsp-1.01.2-3.fc23.armv7hl requires libboost_locale.so.1.57.0
airtsp-1.01.2-3.fc23.armv7hl requires libboost_iostreams.so.1.57.0
airtsp-1.01.2-3.fc23.armv7hl requires libboost_filesystem.so.1.57.0
airtsp-1.01.2-3.fc23.armv7hl requires libboost_date_time.so.1.57.0
[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)
[aws]
aws-tools-2015-2.fc23.armv7hl requires libaws_ssl.so
[cduce]
cduce-0.6.0-13.fc23.armv7hl requires ocaml(Curl) = 
0:c9482fe21d30ad4b5f1ca281b3da3d99
[coin-or-Ipopt]
coin-or-Ipopt-openmpi-3.12.4-1.fc23.armv7hl requires libscalapack.so.2
coin-or-Ipopt-openmpi-3.12.4-1.fc23.armv7hl requires libmpiblacs.so.2
coin-or-Ipopt-openmpi-3.12.4-1.fc23.armv7hl requires libmpi_mpifh.so.2
coin-or-Ipopt-openmpi-3.12.4-1.fc23.armv7hl requires libmpi_cxx.so.1
coin-or-Ipopt-openmpi-3.12.4-1.fc23.armv7hl requires libmpi.so.1
[cp2k]
cp2k-mpich-2.6.0-4.fc23.armv7hl requires libscalapack.so.2
cp2k-mpich-2.6.0-4.fc23.armv7hl requires libmpifort.so.12
cp2k-mpich-2.6.0-4.fc23.armv7hl requires libmpiblacs.so.2
cp2k-mpich-2.6.0-4.fc23.armv7hl requires libmpi.so.12
cp2k-mpich-2.6.0-4.fc23.armv7hl requires libelpa.so.3
cp2k-openmpi-2.6.0-4.fc23.armv7hl requires libscalapack.so.2
cp2k-openmpi-2.6.0-4.fc23.armv7hl requires libmpiblacs.so.2
cp2k-openmpi-2.6.0-4.fc23.armv7hl requires libmpi_usempif08.so.0
cp2k-openmpi-2.6.0-4.fc23.armv7hl requires libmpi_usempi_ignore_tkr.so.0
cp2k-openmpi-2.6.0-4.fc23.armv7hl requires libmpi_mpifh.so.2
cp2k-openmpi-2.6.0-4.fc23.armv7hl requires libmpi.so.1
cp2k-openmpi-2.6.0-4.fc23.armv7hl requires libelpa.so.3
[dans-gdal-scripts]
dans-gdal-scripts-0.23-10.fc23.armv7hl requires libgdal.so.1
[dpm-contrib-admintools]
dpm-contrib-admintools-0.2.1-6.fc23.armv7hl requires 
MySQL-python(armv7hl-32)
[engrid]
engrid-2.0.0-0.4.gitbaef0ce.fc23.armv7hl requires 
libboost_thread.so.1.57.0
engrid-2.0.0-0.4.gitbaef0ce.fc23.armv7hl requires 
libboost_system.so.1.57.0
[gazebo]
gazebo-5.1.0-5.fc23.armv7hl requires libgdal.so.1
gazebo-libs-5.1.0-5.fc23.armv7hl requires libgdal.so.1
player-gazebo-5.1.0-5.fc23.armv7hl requires libgdal.so.1
[gmsh]
gmsh-mpich-libs-2.9.3-3.fc23.armv7hl requires libmpi.so.12
gmsh-openmpi-libs-2.9.3-3.fc23.armv7hl requires libmpi.so.1
[gnome-python2]
gnome-python2-bonobo-2.28.1-16.fc23.armv7hl requires 
pyorbit(armv7hl-32) >= 0:2.0.1
[golang-github-influxdb-influxdb]
golang-github-influxd

Sane ownCloud alternatives (was: Re: Looking for new maintainer: ownCloud (Fedora / EPEL))

[Martin Kolman]

On Mon, 2015-08-31 at 12:13 +0200, Matěj Cepl wrote:
> On 2015-08-31, 07:05 GMT, Pierre-Yves Chibon wrote:
> > > Again, if it works for Adam (or anybody else) it is awesome, but
> > > I would strongly discourage anybody who is not willing to invest
> > > substntial amount of a sweat equity from packaging the package
> > > for Fedora/EPEL.
> > 
> > Not entirely sure if you meant packaging radicale, but if that is 
> > the case,
> > radicale is already packaged in Fedora and epel 6 and 7.
> 
> OK, perhaps I was more afraid that many people will read Adam’s 
> email as “ownCloud is crap, Radicale rulez, let’s jump on that 
> wagon everybody!”. Radicale is a minefield, and if your path 
> happens to avoid the disaster than you may feel it works well.  
> However, one step from the safe path and you are doomed (e.g., 
> using Thunderbird).
That kinda reminds me - is there some sane ownClooud alternative or at
least a project aiming to become one ?

While a have seen various projects dubbed "ownCloud alternative" they
usually just aim for a small part of what ownCloud does - for example
Seafile seems to target file sync, sharing and file based collaboration
and the Radicale project mentioned above does just address book
syncing.

So is there no sane "full ownCloud alternative" that integrates:
* file sync
* calendars
* contacts
* task lists
* collaborative document editing
* plugin/extension API (preferably with support for Python plugins ;-)
)
into one UI/account/framework ?

> 
> Best,
> 
> Matěj
> 
> -- 
> http://www.ceplovi.cz/matej/, Jabber: mc...@ceplovi.cz
> GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
>  
> SCSI is *not* magic. There are *fundamental* *technical*
> reasons why you have to sacrifice a young goat to your SCSI
> chain every now and then.
> -- John F. Woods
> 
-- 
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: Sane ownCloud alternatives (was: Re: Looking for new maintainer: ownCloud (Fedora / EPEL))

[Neal Gompa]

On Mon, Aug 31, 2015 at 9:54 AM, Martin Kolman  wrote:

> On Mon, 2015-08-31 at 12:13 +0200, Matěj Cepl wrote:
> > On 2015-08-31, 07:05 GMT, Pierre-Yves Chibon wrote:
> > > > Again, if it works for Adam (or anybody else) it is awesome, but
> > > > I would strongly discourage anybody who is not willing to invest
> > > > substntial amount of a sweat equity from packaging the package
> > > > for Fedora/EPEL.
> > >
> > > Not entirely sure if you meant packaging radicale, but if that is
> > > the case,
> > > radicale is already packaged in Fedora and epel 6 and 7.
> >
> > OK, perhaps I was more afraid that many people will read Adam’s
> > email as “ownCloud is crap, Radicale rulez, let’s jump on that
> > wagon everybody!”. Radicale is a minefield, and if your path
> > happens to avoid the disaster than you may feel it works well.
> > However, one step from the safe path and you are doomed (e.g.,
> > using Thunderbird).
> That kinda reminds me - is there some sane ownClooud alternative or at
> least a project aiming to become one ?
>
> While a have seen various projects dubbed "ownCloud alternative" they
> usually just aim for a small part of what ownCloud does - for example
> Seafile seems to target file sync, sharing and file based collaboration
> and the Radicale project mentioned above does just address book
> syncing.
>
> So is there no sane "full ownCloud alternative" that integrates:
> * file sync
> * calendars
> * contacts
> * task lists
> * collaborative document editing
> * plugin/extension API (preferably with support for Python plugins ;-)
> )
> into one UI/account/framework ?
>
> >
> > Best,
> >
> > Matěj
> >
> > --
> > http://www.ceplovi.cz/matej/, Jabber: mc...@ceplovi.cz
> > GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
> >
> > SCSI is *not* magic. There are *fundamental* *technical*
> > reasons why you have to sacrifice a young goat to your SCSI
> > chain every now and then.
> > -- John F. Woods
> >
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


​As far as I know, ownCloud stands alone in offering the functionality it
does.​


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
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


6 packages were orphaned

create-tx-configuration [f23, epel7] was orphaned by immanetize
 An easy way to create Transifex client configuration files
 https://admin.fedoraproject.org/pkgdb/package/create-tx-configuration
dock [f23, f22, f21, master] was orphaned by mmilata
 Improved builder for Docker images
 https://admin.fedoraproject.org/pkgdb/package/dock
mate-dialogs [f21] was orphaned by raveit65
 Displays dialog boxes from shell scripts
 https://admin.fedoraproject.org/pkgdb/package/mate-dialogs
pgfouine [epel7] was orphaned by jmlich
 PgFouine PostgreSQL log analyzer
 https://admin.fedoraproject.org/pkgdb/package/pgfouine
pidgin-epel [master] was orphaned by mcepl
 A Gtk+ based multiprotocol instant messaging client
 https://admin.fedoraproject.org/pkgdb/package/pidgin-epel
rubygem-rbovirt [el6] was orphaned by vondruch
 A Ruby client for oVirt REST API
 https://admin.fedoraproject.org/pkgdb/package/rubygem-rbovirt

17 packages were retired
-
ScientificPython [el6] was retired by till
 A collection of Python modules that are useful for scientific computing
 https://admin.fedoraproject.org/pkgdb/package/ScientificPython
create-tx-configuration [master] was retired by immanetize
 An easy way to create Transifex client configuration files
 https://admin.fedoraproject.org/pkgdb/package/create-tx-configuration
ekg [f23, master] was retired by till
 A client compatible with Gadu-Gadu
 https://admin.fedoraproject.org/pkgdb/package/ekg
ekg2 [f23, master] was retired by till
 Multi-protocol instant messaging and chat client
 https://admin.fedoraproject.org/pkgdb/package/ekg2
fwbuilder [f23, master] was retired by till
 Firewall Builder
 https://admin.fedoraproject.org/pkgdb/package/fwbuilder
javanotes [f23, master] was retired by till
 Introduction to Programming Using Java, By David J. Eck
 https://admin.fedoraproject.org/pkgdb/package/javanotes
jtnef [f23, master] was retired by till
 Java TNEF package
 https://admin.fedoraproject.org/pkgdb/package/jtnef
mod_proxy_fcgi [master] was retired by ktdreyer
 FastCGI support module for mod_proxy 2.2
 https://admin.fedoraproject.org/pkgdb/package/mod_proxy_fcgi
php-channel-pdepend [f23, master] was retired by llaumgui
 PHP Depend PEAR channel
 https://admin.fedoraproject.org/pkgdb/package/php-channel-pdepend
php-channel-phpmd [f23, master] was retired by llaumgui
 PHP Mess Detector PEAR channel
 https://admin.fedoraproject.org/pkgdb/package/php-channel-phpmd
python-sgutils [f23, master] was retired by till
 Python support for sg3_utils
 https://admin.fedoraproject.org/pkgdb/package/python-sgutils
rubygem-rack-mount [f23, master] was retired by till
 Stackable dynamic tree based Rack router
 https://admin.fedoraproject.org/pkgdb/package/rubygem-rack-mount
rubygem-regin [f23, master] was retired by till
 Ruby Regexp Introspection
 https://admin.fedoraproject.org/pkgdb/package/rubygem-regin
rubygem-rest-client [el5] was retired by till
 Simple REST client for Ruby
 https://admin.fedoraproject.org/pkgdb/package/rubygem-rest-client
scap-workbench [el6] was retired by mpreisle
 Scanning, tailoring, editing and validation tool for SCAP content
 https://admin.fedoraproject.org/pkgdb/package/scap-workbench
scitools [el6] was retired by till
 A Python library for scientific computing
 https://admin.fedoraproject.org/pkgdb/package/scitools
swig2 [f23, el6, epel7, el5] was retired by till
 Connects C/C++/Objective C to some high-level programming languages
 https://admin.fedoraproject.org/pkgdb/package/swig2

5 packages unorphaned
-
caja-terminal [f23, master] was unorphaned by raveit65
 Terminal embedded in Caja
 https://admin.fedoraproject.org/pkgdb/package/caja-terminal
eclipse-color-theme [f23, master] was unorphaned by mbooth
 An Eclipse plugin which permits color theme switching
 https://admin.fedoraproject.org/pkgdb/package/eclipse-color-theme
python-caja [f23, master] was unorphaned by raveit65
 Python bindings for Caja
 https://admin.fedoraproject.org/pkgdb/package/python-caja
python-sysv_ipc [f23, f22, f21, master, epel7] was unorphaned by athmane
 System V IPC for Python - Semaphores, Shared Memory and Message Queues
 https://admin.fedoraproject.org/pkgdb/package/python-sysv_ipc
willie [f23, f22, f21, master, epel7] was unorphaned by cicku
 Simple, lightweight and easy-to-use IRC Utility bot
 https://admin.fedoraproject.org/pkgdb/package/willie

0 packages were unretired


3 packages were given

libqb [f23, f22, f21, master, epel7] was given by asalkeld to beekhof
 An IPC library for high performance servers
 https://admin.fe

Re: Sane ownCloud alternatives (was: Re: Looking for new maintainer: ownCloud (Fedora / EPEL))

[Solomon Peachy]

On Mon, Aug 31, 2015 at 03:54:59PM +0200, Martin Kolman wrote:
> So is there no sane "full ownCloud alternative" that integrates:
> * file sync
> * calendars
> * contacts
> * task lists
> * collaborative document editing
> * plugin/extension API (preferably with support for Python plugins ;-)
> )
> into one UI/account/framework ?

The closest thing that comes to mind is Horde, though not all the 
interesting bits (eg file manager/sync) are packaged for Fedora.

FWIW, from my perspective, OwnCloud seems to basically consist of file 
synchronization with PIM stuff bolted onto the side, whereas Horde is a 
PIM/groupware system first, with the other stuff bolted on.

 - Solomon
-- 
Solomon Peachy pizza at shaftnet dot org
Delray Beach, FL  ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum viditur.


pgpZFSePr6erx.pgp
Description: 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

Fedora Rawhide 20150831 compose check report

[Fedora compose checker]

Missing expected images:

Kde Live i386
Cloud base Disk i386
Cloud base Disk x86_64
Kde Live x86_64
Cloud atomic Disk x86_64
Kde Disk armhfp

Images in this compose but not Rawhide 20150830:

Security Live x86_64
Xfce Disk armhfp
Cinnamon Live i386

No images in Rawhide 20150830 but not this.

Failed openQA tests: 20 of 22

ID: 947 Test: x86_64 workstation_live default_install
ID: 946 Test: x86_64 generic_boot default_install
ID: 945 Test: x86_64 universal server_no_swap
ID: 944 Test: x86_64 universal server_lvmthin
ID: 943 Test: x86_64 universal server_ext3
ID: 942 Test: x86_64 universal server_btrfs
ID: 941 Test: x86_64 universal fedup_desktop
ID: 940 Test: x86_64 universal fedup_minimal
ID: 938 Test: x86_64 universal server_software_raid
ID: 937 Test: x86_64 universal server_multi_empty
ID: 936 Test: x86_64 universal server_simple_free_space
ID: 935 Test: x86_64 universal server_simple_encrypted
ID: 934 Test: x86_64 universal server_delete_partial
ID: 933 Test: x86_64 universal server_repository_http_variation
ID: 932 Test: x86_64 universal server_repository_http_graphical
ID: 931 Test: x86_64 universal server_mirrorlist_graphical
ID: 930 Test: x86_64 universal server_delete_pata
ID: 928 Test: x86_64 universal server_scsi_updates_img
ID: 927 Test: x86_64 universal server_sata_multi
ID: 926 Test: x86_64 universal package_set_minimal
-- 
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: Looking for new maintainer: ownCloud (Fedora / EPEL)

[Stephen John Smoogen]

On 31 August 2015 at 04:13, Matěj Cepl  wrote:
> On 2015-08-31, 07:05 GMT, Pierre-Yves Chibon wrote:
>>> Again, if it works for Adam (or anybody else) it is awesome, but
>>> I would strongly discourage anybody who is not willing to invest
>>> substntial amount of a sweat equity from packaging the package
>>> for Fedora/EPEL.
>>
>> Not entirely sure if you meant packaging radicale, but if that is the case,
>> radicale is already packaged in Fedora and epel 6 and 7.
>
> OK, perhaps I was more afraid that many people will read Adam’s
> email as “ownCloud is crap, Radicale rulez, let’s jump on that
> wagon everybody!”. Radicale is a minefield, and if your path
> happens to avoid the disaster than you may feel it works well.
> However, one step from the safe path and you are doomed (e.g.,
> using Thunderbird).
>

They are all minefields. They are either hidden from view (e.g.
packaging crap of doom) or in the fact they don't have a lot of
support.



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

Attempting to contact unresponsive maintainer - dvossel

[Kevin Fenzi]

Greetings, we've been told that the email addresses
for this package maintainer is no longer valid.  I'm starting the
unresponsive maintainer policy to find out if they are still interested
in maintaining their packages (and if so, have them update their email
addresses in FAS).  If they're not interested in maintaining or we
can't locate them I'll have FESCo orphan the packages so that others
can take them over.

If you have a way to contact this maintainer, please let them
know that we'd appreciate knowing what to do with their packages.
Thanks!

*  dvossel - former email: dvos...@redhat.com

Point of contact:

resource-agents -- Open Source HA Reusable Cluster Resource Scripts
( master f23 f22 f21 ) 

Co-maintainer:

libqb -- An IPC library for high performance servers ( master f23 f22
f21 epel7 ) 
sbd -- Storage-based death ( master f23 f22 f21 )

kevin


pgpjwRSxB2wmO.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: [Base] Base Design WG agenda meeting August, 31st 2015 14:15 UTC on #fedora-meeting-2

[Harald Hoyer]

On 27.08.2015 14:36, Harald Hoyer wrote:
> Agenda:
> 
> - Fedora.Base - RHEL.Base - Flock recap
> - Ring 1 vs Ring 0
> - define the minimal install (continued)
> - define the docker base image (continued)
> - minimal disk image for importing into libvirt (continued)
> - generic installer? (continued)
> - Open Floor
> 
> Please add items by replying to this mail.


Minutes:

Minutes (text):

Log:

-- 
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 20150831 compose check report

[Fedora compose checker]

Missing expected images:

Cloud atomic Disk x86_64
Cloud base Disk i386
Cloud base Disk x86_64

No images in this compose but not 23 Branched 20150830

Images in 23 Branched 20150830 but not this:

Cinnamon Live i386
Soas Live i386
Cinnamon Live x86_64

Failed openQA tests: 3 of 22

ID: 967 Test: x86_64 universal server_no_swap
ID: 963 Test: x86_64 universal fedup_desktop
ID: 962 Test: x86_64 universal fedup_minimal
-- 
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

[Review swap] ps2emu-tools

[Stephen Chandler Paul]

Hi! I've been trying to get a review for a package I've been trying to
get upstream, ps2emu-tools (you can find the bugzilla here

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

). It's a set of tools used to record the ps2 data coming in and out of
any PS2 devices connected to the system, such as laptop touchpads. I've
heard that a good way to get reviews is to offer to do a review swap,
so I figured I might as well. If anyone would like their package
reviewed in exchange for mine, please let me know.

Cheers,
Stephen Chandler 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: Sane ownCloud alternatives (was: Re: Looking for new maintainer: ownCloud (Fedora / EPEL))

[John Mark Walker]

Pyd.io - https://pyd.io 
On Aug 31, 2015 10:06 AM, Neal Gompa  wrote:On Mon, Aug 31, 2015 at 9:54 AM, Martin Kolman  wrote:On Mon, 2015-08-31 at 12:13 +0200, Matěj Cepl wrote:
> On 2015-08-31, 07:05 GMT, Pierre-Yves Chibon wrote:
> > > Again, if it works for Adam (or anybody else) it is awesome, but
> > > I would strongly discourage anybody who is not willing to invest
> > > substntial amount of a sweat equity from packaging the package
> > > for Fedora/EPEL.
> >
> > Not entirely sure if you meant packaging radicale, but if that is
> > the case,
> > radicale is already packaged in Fedora and epel 6 and 7.
>
> OK, perhaps I was more afraid that many people will read Adam’s
> email as “ownCloud is crap, Radicale rulez, let’s jump on that
> wagon everybody!”. Radicale is a minefield, and if your path
> happens to avoid the disaster than you may feel it works well.
> However, one step from the safe path and you are doomed (e.g.,
> using Thunderbird).
That kinda reminds me - is there some sane ownClooud alternative or at
least a project aiming to become one ?

While a have seen various projects dubbed "ownCloud alternative" they
usually just aim for a small part of what ownCloud does - for example
Seafile seems to target file sync, sharing and file based collaboration
and the Radicale project mentioned above does just address book
syncing.

So is there no sane "full ownCloud alternative" that integrates:
* file sync
* calendars
* contacts
* task lists
* collaborative document editing
* plugin/extension API (preferably with support for Python plugins ;-)
)
into one UI/account/framework ?

>
> Best,
>
> Matěj
>
> --
> http://www.ceplovi.cz/matej/, Jabber: mcepl@ceplovi.cz
> GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
>
> SCSI is *not* magic. There are *fundamental* *technical*
> reasons why you have to sacrifice a young goat to your SCSI
> chain every now and then.
>     -- John F. Woods
>
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct​As far as I know, ownCloud stands alone in offering the functionality it does.​-- 真実はいつも一つ！/ Always, there's only one truth!

-- 
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: Looking for new maintainer: ownCloud (Fedora / EPEL)

[Adam Williamson]

On Mon, 2015-08-31 at 12:13 +0200, Matěj Cepl wrote:
> On 2015-08-31, 07:05 GMT, Pierre-Yves Chibon wrote:
> > > Again, if it works for Adam (or anybody else) it is awesome, but
> > > I would strongly discourage anybody who is not willing to invest
> > > substntial amount of a sweat equity from packaging the package
> > > for Fedora/EPEL.
> > 
> > Not entirely sure if you meant packaging radicale, but if that is
> > the case,
> > radicale is already packaged in Fedora and epel 6 and 7.
> 
> OK, perhaps I was more afraid that many people will read Adam’s 
> email as “ownCloud is crap, Radicale rulez, let’s jump on that 
> wagon everybody!”. Radicale is a minefield, and if your path 
> happens to avoid the disaster than you may feel it works well.  
> However, one step from the safe path and you are doomed (e.g., 
> using Thunderbird).

I said Radicale 'or something like it'. I like Radicale because its
design approach happens to tie in exactly with my requirements: it
actively chooses not to be a full caldav/carddav implementation but
instead one which is designed to be as simple as possible in order to
work with a commonly used subset of clients. I love that, because all
my clients are in the subset and I'm very happy with a server that's
as simple as goddamn possible.

But if it doesn't work for you, there are many options which are still
not as big as 'an entire personal cloud system with seven different
JavaScript minifiers and a code lexer in it'. There's using SabreDAV
directly, and Radicale even directs you to several other alternatives
in its 'technical choices' page, http://radicale.org/technical_choices/ 
.

There isn't really a great alternative to ownCloud (that I know of) if
you actually *want* a 'personal cloud server' with all the bits OC
has, but I realized I just don't and I can't stand the pain of
maintaining that beast just to keep my calendar and contacts
synchronized. I do honestly feel bad about it, but I'd rather be up-
front than pretend I'm still doing it but actually never get around to
it.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net


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

Re: Bad default error policy causes printing issues and BIG usability issues

[valent.turko...@gmail.com]

On 15 December 2014 at 10:03, valent.turko...@gmail.com <
valent.turko...@gmail.com> wrote:

>
> On Sun, Dec 7, 2014 at 6:56 AM, Samuel Sieb  wrote:
>>
>> On 12/06/2014 10:29 AM, valent.turko...@gmail.com wrote:
>>
>>> Any of these actions is simple uses error but results in permanently
>>> disabling of priner (Stops printer) and users can't print even when they
>>> resolve issue that was stopping them from accessing the printer.
>>>
>>> Yes, I've run into this a lot.  The worst part of it is that if the user
>> isn't an admin, they can't fix the printer even if they knew where to find
>> the setting.
>>
>
> Jup, same thing here, I have admin level account and still need to
> "unlock" printer panel in order to turn printer back on :(
> Let's continue discussion here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1171418
>
>

Hi dear Fedora developers, I'm again being really frustrated by this
default policy on Fedora 22. Still nothing changed.

I swear Windows 95 had better printing usability than latest Fedora.
Will this agony ever end? :)
-- 
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: [Base] Base Design WG agenda meeting August, 31st 2015 14:15 UTC on #fedora-meeting-2

[Brendan Conoboy]

On 08/31/2015 08:17 AM, Harald Hoyer wrote:
[snip]

Minutes:

Minutes (text):

Log:



For today's meeting we didn't really use zodbot minute keeping 
features, so in the interest of sparking some discussion I'd like to 
recap.


At Flock 2015 there was a 2 hour session on the subject of rings which 
are basically policy zones inhabited by packages.  Right now fedora 
packaging has 1 policy, so the entire OS is in a single ring. 
Creating more rings means creating more policies.  By doing this 
Fedora can become adopt the flexible to appeal to diverse development 
communities and thus grow.  The general consensus at Flock was that 
Environments and Stacks should take the lead in helping to define new 
rings, and especially how the rings interact.  As a side note, 
everyone agreed the word "rings" breaks down the further you get away 
from the center, but nobody has come up with something better yet 
(Venns? Blobs? Zones?).  A week or so ago, a small Environments and 
Stacks meeting took place where it was generally agreed that the Base 
working group was the right place to define Ring 0.  That brings us to 
this morning's BaseWG meeting.  I talked a lot so here is a rough 
recap integrating a few of the questions and comments people had (Do 
read the log if you have time!)


Right now the Fedora distribution is 1 ring, let's call it ring 1. 
The distribution contains an operating system and numerous 
applications that run on that operating system.  When we talk about 
defining ring 0 we're really talking about distinguishing between the 
operating system and the applications that run on top of it.


We want to go from this:

Ring 1: The Fedora Distribution

To this:

The Fedora Distribution:
Ring 0: The Linux Operating System
Ring 1: The Applications and Stacks

It seems quite modest, but working through the details on what this 
means is hard.  What is an operating system in the Linux context? 
Ring 0 will likely have the strictest set of policies of all the 
rings, so we want to keep it as small as possible, but it is more than 
a minimal install.  These are the traits of rings in general and ring 
0 in particular as I see it:


1. Ring 0 is a repository of rpm packages built in koji.

2. Ring 0 contains, but is not limited to, the minimal install of 
packages to go from Power On to a login prompt.


3. Ring 0 passes repoclosure on its own (Packages listed as hard 
"Requires" in a ring 0 spec file are themselves are implicitly ring 0).


4. Ring 0 is not self hosting.  Packages listed in "BuildRequires" do 
not need to be members of Ring 1.  This isn't ideal, but it's a 
practical consideration.


5. Ring membership is at the source package level, not the binary 
package.  If one source package's binary/noarch sub-package is in ring 
0, all sub-packages are in ring 0.


6. Ring 0 contains the minimal libraries that define the OS API/ABI, 
such as glibc.  This probably happens implicitly by #3, repoclosure.


7. Ring 0 contains the tools needed to update existing packages and 
install new packages.


That's the starting point, but it is by no means comprehensive.  The 
OS probably provides specific services beyond the ability to login, 
for instance.  Which styles of boot are supported?  Where does 
installation infrastructure like anaconda land?  This is equal parts 
philosophy and practicality.  Also, policies for ring 0 may differ 
from what Base has previously adopted: Do we create a ring 0 minimal 
compose since we already need to check repoclosure?  This might be a 
great way to refactor primary/secondary such that we can gracefully 
transition i686 down and secondary arches up.  Lots of opportunities, 
much to consider.


--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.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: [Base] Base Design WG agenda meeting August, 31st 2015 14:15 UTC on #fedora-meeting-2

[Simo Sorce]

On Mon, 2015-08-31 at 10:18 -0700, Brendan Conoboy wrote:
> On 08/31/2015 08:17 AM, Harald Hoyer wrote:
> [snip]
> > Minutes:
> > 
> > Minutes (text):
> > 
> > Log:
> > 
> 
> For today's meeting we didn't really use zodbot minute keeping 
> features, so in the interest of sparking some discussion I'd like to 
> recap.
> 
> At Flock 2015 there was a 2 hour session on the subject of rings which 
> are basically policy zones inhabited by packages.  Right now fedora 
> packaging has 1 policy, so the entire OS is in a single ring. 
> Creating more rings means creating more policies.  By doing this 
> Fedora can become adopt the flexible to appeal to diverse development 
> communities and thus grow.  The general consensus at Flock was that 
> Environments and Stacks should take the lead in helping to define new 
> rings, and especially how the rings interact.  As a side note, 
> everyone agreed the word "rings" breaks down the further you get away 
> from the center, but nobody has come up with something better yet 
> (Venns? Blobs? Zones?).  A week or so ago, a small Environments and 
> Stacks meeting took place where it was generally agreed that the Base 
> working group was the right place to define Ring 0.  That brings us to 
> this morning's BaseWG meeting.  I talked a lot so here is a rough 
> recap integrating a few of the questions and comments people had (Do 
> read the log if you have time!)
> 
> Right now the Fedora distribution is 1 ring, let's call it ring 1. 
> The distribution contains an operating system and numerous 
> applications that run on that operating system.  When we talk about 
> defining ring 0 we're really talking about distinguishing between the 
> operating system and the applications that run on top of it.
> 
> We want to go from this:
> 
> Ring 1: The Fedora Distribution
> 
> To this:
> 
> The Fedora Distribution:
> Ring 0: The Linux Operating System
> Ring 1: The Applications and Stacks
> 
> It seems quite modest, but working through the details on what this 
> means is hard.  What is an operating system in the Linux context? 
> Ring 0 will likely have the strictest set of policies of all the 
> rings, so we want to keep it as small as possible, but it is more than 
> a minimal install.  These are the traits of rings in general and ring 
> 0 in particular as I see it:
> 
> 1. Ring 0 is a repository of rpm packages built in koji.
> 
> 2. Ring 0 contains, but is not limited to, the minimal install of 
> packages to go from Power On to a login prompt.
> 
> 3. Ring 0 passes repoclosure on its own (Packages listed as hard 
> "Requires" in a ring 0 spec file are themselves are implicitly ring 0).
> 
> 4. Ring 0 is not self hosting.  Packages listed in "BuildRequires" do 
> not need to be members of Ring 1.  This isn't ideal, but it's a 
> practical consideration.
> 
> 5. Ring membership is at the source package level, not the binary 
> package.  If one source package's binary/noarch sub-package is in ring 
> 0, all sub-packages are in ring 0.

Can you elaborate more on this point (5) ?

I can totally see how a package may be critical and therefore deserve to
be in ring 0 and yet have optional features in terms of subpackages that
are not necessarily ring 0.
For example some library that offers optionally bindings for somewhat
rarely used languages (say ocaml). The subpackages for those bindings
shouldn't necessarily be ring 0.

Or did I misunderstand the point ?

> 6. Ring 0 contains the minimal libraries that define the OS API/ABI, 
> such as glibc.  This probably happens implicitly by #3, repoclosure.
> 
> 7. Ring 0 contains the tools needed to update existing packages and 
> install new packages.
> 
> That's the starting point, but it is by no means comprehensive.  The 
> OS probably provides specific services beyond the ability to login, 
> for instance.  Which styles of boot are supported?  Where does 
> installation infrastructure like anaconda land?  This is equal parts 
> philosophy and practicality.  Also, policies for ring 0 may differ 
> from what Base has previously adopted: Do we create a ring 0 minimal 
> compose since we already need to check repoclosure?  This might be a 
> great way to refactor primary/secondary such that we can gracefully 
> transition i686 down and secondary arches up.  Lots of opportunities, 
> much to consider.
> 
> -- 
> Brendan Conoboy / Red Hat, Inc. / b...@redhat.com


-- 
Simo Sorce * Red Hat, Inc * New York

-- 
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: [Base] Base Design WG agenda meeting August, 31st 2015 14:15 UTC on #fedora-meeting-2

[Brendan Conoboy]

On 08/31/2015 11:41 AM, Simo Sorce wrote:

On Mon, 2015-08-31 at 10:18 -0700, Brendan Conoboy wrote:

On 08/31/2015 08:17 AM, Harald Hoyer wrote:
[snip]

Minutes:

Minutes (text):

Log:



For today's meeting we didn't really use zodbot minute keeping
features, so in the interest of sparking some discussion I'd like to
recap.

At Flock 2015 there was a 2 hour session on the subject of rings which
are basically policy zones inhabited by packages.  Right now fedora
packaging has 1 policy, so the entire OS is in a single ring.
Creating more rings means creating more policies.  By doing this
Fedora can become adopt the flexible to appeal to diverse development
communities and thus grow.  The general consensus at Flock was that
Environments and Stacks should take the lead in helping to define new
rings, and especially how the rings interact.  As a side note,
everyone agreed the word "rings" breaks down the further you get away
from the center, but nobody has come up with something better yet
(Venns? Blobs? Zones?).  A week or so ago, a small Environments and
Stacks meeting took place where it was generally agreed that the Base
working group was the right place to define Ring 0.  That brings us to
this morning's BaseWG meeting.  I talked a lot so here is a rough
recap integrating a few of the questions and comments people had (Do
read the log if you have time!)

Right now the Fedora distribution is 1 ring, let's call it ring 1.
The distribution contains an operating system and numerous
applications that run on that operating system.  When we talk about
defining ring 0 we're really talking about distinguishing between the
operating system and the applications that run on top of it.

We want to go from this:

Ring 1: The Fedora Distribution

To this:

The Fedora Distribution:
Ring 0: The Linux Operating System
Ring 1: The Applications and Stacks

It seems quite modest, but working through the details on what this
means is hard.  What is an operating system in the Linux context?
Ring 0 will likely have the strictest set of policies of all the
rings, so we want to keep it as small as possible, but it is more than
a minimal install.  These are the traits of rings in general and ring
0 in particular as I see it:

1. Ring 0 is a repository of rpm packages built in koji.

2. Ring 0 contains, but is not limited to, the minimal install of
packages to go from Power On to a login prompt.

3. Ring 0 passes repoclosure on its own (Packages listed as hard
"Requires" in a ring 0 spec file are themselves are implicitly ring 0).

4. Ring 0 is not self hosting.  Packages listed in "BuildRequires" do
not need to be members of Ring 1.  This isn't ideal, but it's a
practical consideration.

5. Ring membership is at the source package level, not the binary
package.  If one source package's binary/noarch sub-package is in ring
0, all sub-packages are in ring 0.


Can you elaborate more on this point (5) ?

I can totally see how a package may be critical and therefore deserve to
be in ring 0 and yet have optional features in terms of subpackages that
are not necessarily ring 0.
For example some library that offers optionally bindings for somewhat
rarely used languages (say ocaml). The subpackages for those bindings
shouldn't necessarily be ring 0.

Or did I misunderstand the point ?


Let's take gcc for example.  The gcc package produces numerous 
subpackages including various compilers and libraries.  One of those 
libraries, libgcc, is linked into nearly every dynamically linked ELF 
executable on your system (Run ldd to confirm), including /sbin/init. 
 Since we really want /sbin/init to function we need to include 
libgcc in ring 0.  Since ring membership is at a source level rather 
than a sub-package level, gcc is ring 0.  There are other good 
arguments for the executable-generating tools living in ring 0, but 
this one illustrates the point.


Ring policies might include things like how long the package is 
supported, what build system can generate it, what release cycle it is 
on, what the packaging guidelines are, what the updates rebase policy 
is, and so forth.  These types of policies apply to source rpms as a 
whole.  You can't apply one to gcc-c++ and another to libgcc.


I think the question you are posing might be, in the context of gcc, 
might be: Does gcc-g++ need to appear in the same repository as 
libgcc? IE, can we decouple what we build from what is presented to 
users?  If the threshold for must-include is repoclosure then no, we 
don't need to include gcc-c++, we only need to include libgcc and make 
gcc-c++ available elsewhere.  In talking to Langdon about this,

Re: Sane ownCloud alternatives (was: Re: Looking for new maintainer: ownCloud (Fedora / EPEL))

[Haïkel]

There's also cozy cloud , though it's JavaScript much less insane than
owncloud.
https://cozy.io/

Regards,
H.
-- 
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: Bad default error policy causes printing issues and BIG usability issues

[Germano Massullo]

Il 06/12/2014 19:29, valent.turko...@gmail.com ha scritto:
> Who is responsible for user experience of Fedora desktop? To whom
> should I point this issue to?
https://fedoraproject.org/wiki/QA
you could also fill a bugreport against CUPS component in
https://bugzilla.redhat.com/
I agree with you. I migrated some offices to Fedora and sometimes I
receive phone calls about printing troubles. When I go personally to
check what is wrong I often saw a big CUPS queue and the printer in pause
-- 
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: [Review swap] ps2emu-tools

[Christopher Meng]

On 9/1/15, Stephen Chandler Paul  wrote:
> Hi! I've been trying to get a review for a package I've been trying to
> get upstream, ps2emu-tools (you can find the bugzilla here
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1245351
>
> ). It's a set of tools used to record the ps2 data coming in and out of
> any PS2 devices connected to the system, such as laptop touchpads. I've
> heard that a good way to get reviews is to offer to do a review swap,
> so I figured I might as well. If anyone would like their package
> reviewed in exchange for mine, please let me know.

Swapped with abcmidi[1].

[1]---https://bugzilla.redhat.com/show_bug.cgi?id=1257410
-- 

Yours sincerely,
Christopher Meng

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

[Test-Announce] i18n Test Day tomorrow (2015-09-01)!

[Adam Williamson]

It's time for another Test Day tomorrow (2015-09-01)! Continuing the
"all those places in the world that aren't America" theme with
[i18n][1], it's the [i18n Test Day][2]! Here we'll be testing things
like complex language input, rendering of non-Latin text, and DNF
langpack installation. If you have some time to stop by and help out,
please do - we always want to make sure everyone using Fedora gets the
best possible experience regardless of the language they speak!

As always for Test Days, the live action is in #fedora-test-day on
Freenode IRC. If you don’t know how to use IRC, you can [read these
instructions][3], or just use [WebIRC][4].

 [1]: https://fedoraproject.org/wiki/I18N
 [2]: https://fedoraproject.org/wiki/Test_Day:2015-09-01_i18n
 [3]: http://fedoraproject.org/wiki/How_to_use_IRC
 [4]: http://webchat.freenode.net/?channels=fedora-test-day
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net


___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-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: Bad default error policy causes printing issues and BIG usability issues

[Chris Murphy]

On Mon, Aug 31, 2015 at 3:37 PM, Germano Massullo
 wrote:
> Il 06/12/2014 19:29, valent.turko...@gmail.com ha scritto:
>> Who is responsible for user experience of Fedora desktop? To whom
>> should I point this issue to?
> https://fedoraproject.org/wiki/QA
> you could also fill a bugreport against CUPS component in
> https://bugzilla.redhat.com/
> I agree with you. I migrated some offices to Fedora and sometimes I
> receive phone calls about printing troubles. When I go personally to
> check what is wrong I often saw a big CUPS queue and the printer in pause

Like I mentioned today in the bug report, I think there's more going
on here. Issue 1 is whether non-admins can create/delete/modify state
of printers (queues);

Issue 2 is more challenging, more information is needed on the various
failures that seem to be more common on Linux than on OS X, both of
which use CUPS. I don't know if there's usually enough information for
CUPS to put a job on hold, rather than the queue. Some logic would
need to be present or you get situations where jobs vanish because the
queue isn't on hold and the printer isn't receiving data for some
reason. There was a period on OS X where something similar happened,
and new jobs printed just silently built-up or just vanished; but this
behavior was replaced quite a long time ago when at print time the
user gets an information dialog that the print queue is currently
stopped, and asks if they want to add the job to the queue rather than
print (because printing is offline). At least that way the user gets
the notification that the print queue is stopped.



-- 
Chris Murphy
-- 
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: A backup service using fuse, sqlite and btrfs.

[Chris Murphy]

I have a better chance of seeding clouds to make rain than read code
to get the answers to these questions, but I tried anyway.

- Is this a versioning system, or is it both a versioning system and a
backup? Backup implies copying data to a separate device.

- If it's a backup, does it depend on the source being Btrfs? Or just
the destination? Or both?

- Do you envision Fedora Server and Fedora Workstation components, to
achieve a sort of turn key + integrated Fedora solution for network
backups?

- Does this apply to just user data, or system settings as well, or
the entire installation?


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

Volunteer to organize Env-and-Stacks WG meeting this week? (2015-09-03)

[Honza Horak]

I'm sorry but I'm not able to organize the WG meeting this week. If 
somebody else is volunteering to organize the meeting (which should be 
at 5pm UTC this week), feel free to do so.


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