Re: unaccessability
On 8 November 2013 00:11, Rahul Sundaram methe...@gmail.com wrote: It would be awfully convenient to have a single place for all these related tasks. Trying to design a GUI for all users who would find something convenient isn't possible. Sooner or later you have to limit scope of you get a huge feature-creep issue and a huge bloated program that isn't good at anything at all. I'll repeat my previous point; if you want to help guide the development of gnome-software, the place to do this is by filing bugs on gnome bugzilla and talking with the developers and designers in #gnome-design. Fedora users demanding that GNOME has to do X, Y, or Z before it's suitable for Fedora will not work. Richard. -- 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: AppData questions
On 8 November 2013 01:04, Rex Dieter rdie...@math.unl.edu wrote: which claims to be a (the?) tool to create some necessary database, how does this fit in (if at all)? As I understand it, it's a libappstream-kind-thing that takes the xml files as inputs and exposes a GObject API. gnome-software doesn't use this right now, but might in the future. At the moment large parts of gnome-software are performance critical, and that includes loading the XML files, so it would need some careful profiling before even considering this as a dep. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
dnf-0.4.7
Hi, dnf-0.4.7 is built for rawhide [1]. F20 version is going to have to wait a few of days because we are missing a dependency there. There's a couple of bugfixes in 0.4.7 but the main thing is that we are slowly starting with forming the API [2]. More in the blog post [3] and the release notes [4]. Ales [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=6154289 [2] http://akozumpl.github.io/dnf/api.html#deprecation-policy [3] http://dnf.baseurl.org/2013/11/08/dnf-0-4-7-released/ [4] http://akozumpl.github.io/dnf/release_notes.html#id18 -- 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: unaccessability
2013/11/7 Christian Schaller cscha...@redhat.com: Ok, so I guess the solution would be for the launcher to do something like this: gnome-terminal --geometry 80x37 --disable-factory --role=bitchx --class=bitchx --name bitchX IRC --title BitchX IRC Isn't the Terminal attribute of desktop files[1] supposed to tell the launcher program that it should start the application inside a terminal? My impression is that Gnome at least used to support it, and I know that KDE does support it. It should quite easily allow specifying launchers for terminal-based programs that do not usually need command line arguments. [1] http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: rpm macro magic help
On Thu, 07 Nov 2013 14:10:19 +0100, Sandro Mani wrote:
Well, a Shell Function would be more readable, for example. It would
accept normal arguments to fill in variables -- instead of global RPM
macros, which are substituted in the entire spec file.
Uhm, how can one this be done? Shell variables are substituted after
macro expansion, so i.e.
With the benefit that the function is more readable and more comprehensible
(especially if adding comments) than a global RPM macro. In a Shell function
you could evaluate the arguments and create conditional sections, whereas
in the RPM macro that would get even less readable.
The linked spec is an entertaining exercise, but also an example of
macro-madness. Several values (e.g. paths) are expanded multiple times
instead of defining them once at the beginning and reusing them later. And
the macro is not even fully reusable yet due to hardcoded library file
names.
%define do_install() \
(cd build_win%{1}_%{2}; \
%{expand:%%{mingw%{1}_make}} INSTALL_ROOT=%{buildroot} install; \
)\
mkdir -p %{buildroot}%{expand:%%{mingw%{1}_bindir}}; \
mv %{buildroot}%{expand:%%{mingw%{1}_libdir}}/quazip-%{2}-?.dll
%{buildroot}%{ expand:%%{mingw%{1}_bindir}}; \
mv %{buildroot}%{expand:%%{mingw%{1}_libdir}}/libquazip-%{2}-?.a
%{buildroot}% {expand:%%{mingw%{1}_libdir}}/libquazip-%{2}.dll.a; \
(cd build_win%{1}_%{2}_static; \
%{expand:%%{mingw%{1}_make}} INSTALL_ROOT=%{buildroot} install; \
)\
mv %{buildroot}%{expand:%%{mingw%{1}_libdir}}/libquazip-%{2}-.a
%{buildroot}%{ expand:%%{mingw%{1}_libdir}}/libquazip-%{2}.a; \
mv %{buildroot}%{expand:%%{mingw%{1}_includedir}}/%{pkgname}
%{buildroot}%{exp and:%%{mingw%{1}_includedir}}/%{pkgname}-%{2}; \
mkdir -p %{buildroot}%{expand:%%{mingw%{1}_libdir}}/pkgconfig; \
cat %{buildroot}%{expand:%%{mingw%{1}_libdir}}/pkgconfig/%{pkgname}-%{2}.pc
EOF\
prefix=%{expand:%%{mingw%{1}_prefix}}\
exec_prefix=%{expand:%%{mingw%{1}_prefix}}\
libdir=%{expand:%%{mingw%{1}_libdir}}\
includedir=%{expand:%%{mingw%{1}_includedir}}/%{pkgname}-%{2}\
\
Name: %{pkgname}\
Description: Qt/C++ wrapper for the minizip library\
Version: %{version}\
\
Requires:\
Libs: -L\\${libdir} -lquazip\
Cflags: -I\\${includedir}\
\
Requires.private: libzip\
EOF\
%{nil}
function do_build {
arch=$1
qt_version=$2
%{mingw${arch}_qmake_${qt_version}}
}
would hardly work? Or are you suggesting passing the entire macros as
arguments? I.e.
function do_build {
qmake=$1
make=$2
${qmake} args
${make} %{?_smp_mflags}}
[...]
do_build %{mingw32_qmake_qt4} %{mingw32_make}
Yes, something like that is *much* more readable IMO, because it becomes
clear which commands will be used, and since most of the code is Shell
based, it becomes easier to insert guards and/or debugging help.
--
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: Draft Product Description for Fedora Workstation
tor 2013-11-07 klockan 09:14 + skrev Peter Robinson: I don't see many people forcing things through, I believe that the vast majority of contributors either like the change or aren't bothered by it. Just so that my silence is not counted as approval. I disapprove. Mattias smime.p7s Description: S/MIME cryptographic signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F-20 Branched report: 20131108 changes
Compose started at Fri Nov 8 09:15:03 UTC 2013 Broken deps for armhfp -- [blueman] blueman-1.23-7.fc20.armv7hl requires obex-data-server = 0:0.4.3 blueman-1.23-7.fc20.armv7hl requires gvfs-obexftp [bwm-ng] bwm-ng-0.6-11.1.fc20.armv7hl requires libstatgrab.so.9 [cloud-init] cloud-init-0.7.2-7.fc20.noarch requires dmidecode [cobbler] cobbler-2.4.0-2.fc20.noarch requires syslinux [condor-wallaby] condor-wallaby-client-5.0.3-4.fc20.noarch requires python-qmf = 0:0.9.1073306 [fts] fts-server-3.1.1-1.fc20.armv7hl requires libactivemq-cpp.so.14 [glpi] glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Version glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Stdlib glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-ServiceManager glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Loader glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-I18n glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Cache-apc glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Cache [gnome-do-plugins] gnome-do-plugins-thunderbird-0.8.4-14.fc20.armv7hl requires thunderbird [gofer] ruby-gofer-0.75-4.fc20.noarch requires rubygem(qpid) = 0:0.16.0 [gradle] gradle-1.0-18.fc20.noarch requires plexus-container-default [grass] grass-6.4.3-2.fc20.armv7hl requires libgeos-3.3.8.so grass-libs-6.4.3-2.fc20.armv7hl requires libgeos-3.3.8.so [gtkd] gtkd-geany-tags-2.0.0-29.20120815git9ae9181.fc18.noarch requires gtkd = 0:2.0.0-29.20120815git9ae9181.fc18 [kawa] 1:kawa-1.11-5.fc19.armv7hl requires servlet25 [koji] koji-vm-1.8.0-2.fc20.noarch requires python-virtinst [kyua-cli] kyua-cli-0.5-3.fc19.armv7hl requires liblutok.so.0 kyua-cli-tests-0.5-3.fc19.armv7hl requires liblutok.so.0 [monotone] monotone-1.0-11.fc19.armv7hl requires libbotan-1.8.2.so perl-Monotone-1.0-11.fc19.armv7hl requires perl(:MODULE_COMPAT_5.16.2) [mozilla-firetray] mozilla-firetray-thunderbird-0.3.6-0.5.143svn.fc18.1.armv7hl requires thunderbird = 0:11 [msp430-libc] msp430-libc-20120224-2.fc19.noarch requires msp430-gcc = 0:4.6.3 [nifti2dicom] nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtksys.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkWidgets.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkVolumeRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkViews.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkTextAnalysis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkParallel.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkInfovis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkImaging.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkIO.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkHybrid.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGraphics.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGeovis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGenericFiltering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkFiltering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCommon.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCharts.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libQVTK.so.5.10 [nocpulse-common] nocpulse-common-2.2.7-2.fc20.noarch requires perl(RHN::DBI) [openbox] gdm-control-3.5.2-2.fc20.armv7hl requires gnome-panel gnome-panel-control-3.5.2-2.fc20.armv7hl requires gnome-panel [openpts] openpts-0.2.6-7.fc20.armv7hl requires tboot [osm2pgsql] osm2pgsql-0.82.0-1.fc20.armv7hl requires libgeos-3.3.8.so [oyranos] oyranos-libs-0.4.0-7.fc19.armv7hl requires libraw.so.5 [perl-BerkeleyDB] perl-BerkeleyDB-0.53-1.fc20.armv7hl requires libdb = 0:5.3.21 [perl-Language-Expr] perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) [perl-MIME-Lite-HTML] perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) [perl-Padre] perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) [pure] pure-doc-0.57-4.fc20.noarch requires pure = 0:0.57-4.fc20 [python-tag] python-tag-2013.1-1.fc20.armv7hl requires libboost_python.so.1.53.0 [rootplot] rootplot-2.2.1-7.fc19.noarch requires root-python [ruby-spqr] ruby-spqr-0.3.6-7.fc20.noarch requires ruby-qpid-qmf [rubygem-audited-activerecord] rubygem-audited-activerecord-3.0.0-3.fc19.noarch requires rubygem(activerecord) 0:4 [rubygem-fog] rubygem-fog-1.11.1-1.fc20.noarch requires rubygem(nokogiri) 0:1.6 [scala]
[Fedora Base Design WG] Reminder: Meeting on #fedora-meeting at 15:00 UTC today
Hi everyone. Just as a reminder, meeting time in roughly 1 1/2 hours from now. See you there! Thanks regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Manager Core Services| Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch pknir...@redhat.com Wankelstrasse 5 | Web: http://www.redhat.com/ D-70563 Stuttgart, Germany -- 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: Draft Product Description for Fedora Workstation
On Thu, Nov 07, 2013 at 09:55:12PM +0100, Miloslav Trmač wrote: On Thu, Nov 7, 2013 at 9:48 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Thu, 07.11.13 20:09, Miloslav Trmač (m...@volny.cz) wrote: Is there a technical reason why we can't use their packaging format, interpreting it with our technologies but staying compatible? Well, the most relevant bit is that they use apparmor for sandboxing. Nobody else uses that. Are the packages expected to ship their own apparmor policy? That would appear to be at odds with the idea of protecting against malicious packages. If they aren't expected to ship their own, could we implement the same sandboxing policy using SELinux? (https://wiki.ubuntu.com/AppDevUploadProcess seems to suggest Ubuntu will be using some higher-level profile format, not raw AppArmor.) The whole plan is here : https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement Looking at : https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement/Manifest I would say no. From a quick look, some abstraction are quite apparmor specific, see the concept of read_path, which is something we can hardly translate to selinux ( since apparmor use path, while selinux use a 2 tier system with label assigned to path, and then privileges assigned based on label ). What we could do is to have a better abstraction that would be apparmor and selinux comptaible. Since despites what Lennart claim, AppArmor is also used by Opensuse. And I am sure people using smackd ( such as intel people ) would be delighted to not be left in the cold. SELinux is still pretty RH/Fedora specific, even if Debian and gentoo support it in theory ( in practice, Debian didn't seems to support it that well ). And I don't think it is a good idea to use .deb as an image format. .deb is just an ar archive; if this were the only difference, it would not be worth fragmenting the ecosystem over IMHO. (Especially if the GNOME apps alternative is a compressed disk image, which saves disk space and costs extra CPU time and memory, making exactly the wrong tradeoff in most situations AFAICS.) While I do not see any obvious problem into using deb, I do not think it will bring much gain. It will matter for people managing the low level format, ie few people. Reusing the manifests ( if it was doable ) would have yield much more gain. -- Michael Scherer -- 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: rpm macro magic help
On 08.11.2013 13:47, Michael Schwendt wrote: On Thu, 07 Nov 2013 14:10:19 +0100, Sandro Mani wrote: Well, a Shell Function would be more readable, for example. It would accept normal arguments to fill in variables -- instead of global RPM macros, which are substituted in the entire spec file. Uhm, how can one this be done? Shell variables are substituted after macro expansion, so i.e. With the benefit that the function is more readable and more comprehensible (especially if adding comments) than a global RPM macro. In a Shell function you could evaluate the arguments and create conditional sections, whereas in the RPM macro that would get even less readable. The linked spec is an entertaining exercise, but also an example of macro-madness. Several values (e.g. paths) are expanded multiple times instead of defining them once at the beginning and reusing them later. And the macro is not even fully reusable yet due to hardcoded library file names. Well I'm certainly not claiming that it is a generic, package independent macro, and yeah, multiple expansions could be avoided. But as I said, all this was mainly curiosity-driven, not written with excessive care (and not something I would put up for review without further attention). -- 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: unaccessability
On 8 November 2013 00:11, Rahul Sundaram methe...@gmail.com wrote: HI On Thu, Nov 7, 2013 at 6:51 PM, Adam Williamson awill...@redhat.com wrote: Honestly, I don't think Software is really aimed at your use case, and you may as well just keep using yum. It's meant to be a cool way to find neat software, not a comprehensive package catalog. Part of the problem that I have with that response is that Fedora will provide no gui for a package catalog by default and finding new software is often interconnected with installing known software. You go in looking for say openarena and decide to check out what fun new games are available. You want to read about reviews on tmux and screen and decide which one to install. Yum doesn't provide me with a convenient view and yumex isn't provide me with any screenshots or reviews. It would be awfully convenient to have a single place for all these related tasks. Indeed, it's a perennial feature in reviews of new Fedora releases that the software centre is poor (which I suppose is the inspiration for this new thing). The Ubuntu one (while it was useful, I know there's now also some crazy app-store type thing) actually listed packages, so you could find, for example, the particular package needed for nvidia support or sshd in the same place as you could select OpenOffice and have all the components installed. It sounds like we still wont have a single place gui for package management. -- imalone http://ibmalone.blogspot.co.uk -- 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: Draft Product Description for Fedora Workstation
Michael scherer wrote: SELinux is still pretty RH/Fedora specific, even if Debian and gentoo support it in theory ( in practice, Debian didn't seems to support it that well ). Millions of Android devices now have SELinux. Android 4.3 enabled SELinux and defaults to Permissive. Android 4.4 defaults to Enforcing. -- 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: Draft Product Description for Fedora Workstation
On Wed, Nov 06, 2013 at 02:45:46PM -0500, Rahul Sundaram wrote: Hi On Wed, Nov 6, 2013 at 2:38 PM, Adam Williamson wrote: I'm still slightly out of sync with the fedora.next stuff (REALLY picked a bad time to go on vacation), but it does seem to me that a decent amount of 'mature reflection' was done on it before it was approved, at least. I don't really have a problem in believing that but it would be useful to know in more detail how the initial proposals came to be (who were involved? what problems are we trying to solve? what are failures of the current model? did it go through Red Hat management internally before being proposed and is more headcount being allotted? Was Fedora Board and FESCo members aware that a proposal were coming through and what was their rationale for choosing to go forward? etc) I suspect Mattew discussed this around him before, as anything anyone would propose. Would chatting with Spot on IRC count as going with Red Hat management, or just 2 community member talking together ? Because the outcome would be the same. But the The proposal was discussed IRL during Flock, the proposal was discussed here before[1] and got lot of feedback, the proposal was checked by Board[3] , by FESCO[2]. And I think this was in line with the discussion on the whole product or platform on the Board mailling list, who was started by the user base discussion initiated by Robyn [4]. So it all boil down to thing have changed, and so we think we should also do some changes, for all those reasons. [1] https://lists.fedoraproject.org/pipermail/devel/2013-July/186323.html [2] https://fedorahosted.org/fesco/ticket/1158 [3] https://fedoraproject.org/wiki/Fedora.next/boardproposal [4] http://wordshack.wordpress.com/2013/04/04/board-meeting-topic-for-the-day-user-base-aka-target-audience/ -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Broken dependencies: perl-SOAP-Lite
perl-SOAP-Lite has broken dependencies in the rawhide tree: On x86_64: perl-SOAP-Lite-0.716-3.fc20.noarch requires perl(SOAP::Transport::TCP) On i386: perl-SOAP-Lite-0.716-3.fc20.noarch requires perl(SOAP::Transport::TCP) On armhfp: perl-SOAP-Lite-0.716-3.fc20.noarch requires perl(SOAP::Transport::TCP) Please resolve this as soon as possible. -- 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
Re: unaccessability
Hi On Fri, Nov 8, 2013 at 4:51 AM, Richard Hughes wrote: On 8 November 2013 00:11, Rahul Sundaram wrote: It would be awfully convenient to have a single place for all these related tasks. Trying to design a GUI for all users who would find something convenient isn't possible. Sooner or later you have to limit scope of you get a huge feature-creep issue and a huge bloated program that isn't good at anything at all. I agree with that but I think you are drawing the line at the wrong place. I'll repeat my previous point; if you want to help guide the development of gnome-software, the place to do this is by filing bugs on gnome bugzilla and talking with the developers and designers in #gnome-design. Fedora users demanding that GNOME has to do X, Y, or Z before it's suitable for Fedora will not work. I have filed a bug report already in case you didn't notice. Noone can demand anything. I am just expressing our views on why not being inclusive of more than just gui packages is problematic. Rahul -- 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: AppData questions
On Thu, 7 Nov 2013 13:04:39 +, Richard Hughes wrote: $ file screenshot-soundconverter.png screenshot-soundconverter.png: PNG image data, 502 x 534, 8-bit/color RGBA, non-interlaced ScreenshotSizeWidthMin=624 ScreenshotSizeHeightMin=351 503 is smaller than 624 and the screenshot is the wrong aspect ratio. The reason we need a minim width is so we avoid *scaling up* the screenshot which looks awful. Well, then the contributed appdata file [1] is wrong, and the screenshot needs to be corrected. [1] https://bugs.launchpad.net/soundconverter/+bug/1227535 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Broken dependencies: perl-Language-Expr
perl-Language-Expr has broken dependencies in the rawhide tree: On x86_64: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- 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
Re: unaccessability
On Fri, 2013-11-08 at 14:06 +0200, Joonas Sarajärvi wrote: 2013/11/7 Christian Schaller cscha...@redhat.com: Ok, so I guess the solution would be for the launcher to do something like this: gnome-terminal --geometry 80x37 --disable-factory --role=bitchx --class=bitchx --name bitchX IRC --title BitchX IRC Isn't the Terminal attribute of desktop files[1] supposed to tell the launcher program that it should start the application inside a terminal? My impression is that Gnome at least used to support it, and I know that KDE does support it. It should quite easily allow specifying launchers for terminal-based programs that do not usually need command line arguments. [1] http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html GNOME supports the Terminal key just fine. But just having your commandd run in a terminal is not quite enough to give it an identity as a separate application - to the rest of the system it will appear just as a terminal. The extra arguments that Christian shows there help to overcome this problem. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Base] Summary/Minutes from today's Base WG meeting (2013-11-08)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 == #fedora-meeting: Fedora Base Design Working Group (2013-11-08) == Meeting started by pknirsch at 15:00:59 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2013-11-08/fedora_base_design_working_group.2013-11-08-15.00.log.html . Meeting summary - --- * Governance discussion draft (pknirsch, 15:12:13) * LINK: https://fedoraproject.org/wiki/Server/Governance_Charter (jwb, 15:17:02) * LINK: https://fedoraproject.org/wiki/Server/Governance_Charter looks good :) (haraldh, 15:19:36) * AGREED: (haraldh, 15:20:05) * AGREED: Proposal: Take the server governance charter and replace the names and present to FESCO for approval (pknirsch, 15:22:11) * ACTION: haraldh Proposal: Take the server governance charter and replace the names and present to FESCO for approval (pknirsch, 15:23:36) * Regular meeting times (pknirsch, 15:28:03) * Keep meeting time at 15:00 UTC for the time being (pknirsch, 15:33:00) * Base mailing list discussion (pknirsch, 15:33:28) * AGREED: (haraldh, 15:37:11) * AGREED: Stay with fedora-devel mailinglist, use [Base] in subject to indicate emails around Base Design discussions (pknirsch, 15:39:33) * Role of Base Design group discussion (pknirsch, 15:42:57) * LINK: https://fedoraproject.org/wiki/Critical_path_package?rd=Critical_path_packages#Where_can_I_find_the_critical_path.3F (dgilmore, 15:45:34) * LINK: https://admin.fedoraproject.org/pkgdb/lists/critpath?tg_format=plaincollctn_list=f20 (dgilmore, 15:45:57) * LINK: http://fpaste.org/52688/38392758/ (pknirsch, 16:19:54) * Base definition: installer, compose tools, minimal install (for some definition there), and functionality the majority products want to use (pknirsch, 16:21:30) * Open Floor (pknirsch, 16:25:50) * jreznik working on a communication plan with other WGs (pknirsch, 16:33:25) * ACTION: jreznik working on a communication plan with other WGs (pknirsch, 16:34:04) Meeting ended at 16:41:32 UTC. Action Items - * haraldh Proposal: Take the server governance charter and replace the names and present to FESCO for approval * jreznik working on a communication plan with other WGs Action Items, by person - --- * haraldh * haraldh Proposal: Take the server governance charter and replace the names and present to FESCO for approval * jreznik * jreznik working on a communication plan with other WGs * **UNASSIGNED** * (none) People Present (lines said) - --- * pknirsch (195) * dgilmore (105) * haraldh (69) * jreznik (68) * jwb (57) * masta (15) * zodbot (9) * kmacleod (1) * sgallagh (1) * Southern_Gentlem (1) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJSfRaIAAoJEH7ltONmPFDRLtUP/A+1Gs7Mp5aQ9dRAhMLE9uUe CXawhmK3QNrJy6E3cA33ECF3TSjAi/Roq3gDCtyE9hIzT4AcLbZVUj4JwcCQzhkE Mr9TVE3JXjfVHk3OFWPLaW41q71TDLo8rpb9mEpjR+ZzeW86FqGKz/PCsZjImUjf XROLmA7ybr+5T2UoSpC1LoBkk4V7A3uX902thV9WCC+WdbBCLHKLHkwamEXXM4ds zOMoYMK3fHD31Vz9SVk1wLn9dkaIlFNwgT6aXzqMubhJ8V65vdLuZ0hvjtwXk5sd blGb0BNlDoOaD6kU6JBF9/zBX6MhiXyyQCsThtWvo3jshzthLiDNU2he4PW8kzST wRgMu4oL87igMdNskJQpugOyc7kIaHA9hoYuy3NH9PJL460hbU9/NVf0EHBPEvUI Z3KrtZpyROl76P9ohX1olz2Vk3V/c55qBCVQ96fDlCcxASDwdwiLi03gQOGfZQ3G 7HkNbtNkJhE1yGt76BOvYrRsgf2NR1xu59A9cUZy+eUKZF6v+MmF5u5qisJbBGLN WeBfwAzb6YZ35pc/20SXec5veEXGCf0r7OyNgOFVUfnordAy9pgk9u/IP/xqGhfL j0qQl27/X32EKNOQy7Uf13NeRBsld/uIvDT1+bgmMuUnt/RsfZy2yZPDhGAgALqJ eaCw0DbJqqitFCoA365k =B1/8 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Fri, 2013-11-08 at 08:37 -0600, Michael Cronenworth wrote: Michael scherer wrote: SELinux is still pretty RH/Fedora specific, even if Debian and gentoo support it in theory ( in practice, Debian didn't seems to support it that well ). Millions of Android devices now have SELinux. Android 4.3 enabled SELinux and defaults to Permissive. Android 4.4 defaults to Enforcing. *can't quite believe this is the first he's read about this* -- 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: [Fedora Base Design WG] Reminder: Meeting on #fedora-meeting at 15:00 UTC today
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/08/2013 08:19 AM, Phil Knirsch wrote: Hi everyone. Just as a reminder, meeting time in roughly 1 1/2 hours from now. See you there! Thanks regards, Phil I can not make the meeting, I am at a conference in Washington DC. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJ9JXgACgkQrlYvE4MpobPMbwCfQG+P9xTVRRS48R6Qc+0bVoad qM0An013I6+KcmePhM9YD7MEIlm79ZJw =oU3A -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
EPEL Fedora 5 updates-testing report
The following Fedora EPEL 5 Security updates need testing: Age URL 565 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5 79 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11276/ssmtp-2.61-21.el5 55 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11560/fail2ban-0.8.10-4.el5 19 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11893/libguestfs-1.20.12-1.el5 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12004/GraphicsMagick-1.3.18-2.el5 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12067/drupal7-context-3.1-1.el5 The following builds have been pushed to Fedora EPEL 5 updates-testing drupal7-context-3.1-1.el5 drupal7-strongarm-2.0-1.el5 Details about builds: drupal7-context-3.1-1.el5 (FEDORA-EPEL-2013-12067) Allows you to manage contextual conditions and reactions of your site Update Information: - Update to upstream 3.1 release for bug fixes - Upstream changelog for this release: https://drupal.org/node/2113785 - Fixes CVE-2013-4445, CVE-2013-4446 BZ 1020777, BZ 1020262, BZ 1020781, BZ 1020784 Upstream updated to rc1 ChangeLog: * Fri Nov 8 2013 Peter Borsa peter.bo...@gmail.com - 3.1-1 - Update to upstream 3.1 release for bug fixes - Upstream changelog for this release: https://drupal.org/node/2113785 - Fixes CVE-2013-4445, CVE-2013-4446 BZ 1020777, BZ 1020262, BZ 1020781, BZ 1020784 * Sat Sep 28 2013 Scott Dodson sdod...@redhat.com - 3.0-0.7.rc1 - Update to upstream 3.0-rc1 - Upstream changelog for this release is available at https://drupal.org/node/2098831 References: [ 1 ] Bug #1020777 - CVE-2013-4445 CVE-2013-4446 drupal-context: multiple vulnerabilities https://bugzilla.redhat.com/show_bug.cgi?id=1020777 drupal7-strongarm-2.0-1.el5 (FEDORA-EPEL-2013-12063) Strongarm gives a way to override the default variable values Update Information: - Update to upstream 2.0 release for bug fixes - Upstream changelog for this release: https://drupal.org/node/1632574 ChangeLog: * Fri Nov 8 2013 Peter Borsa peter.bo...@gmail.com - 2.0-1 - Update to upstream 2.0 release for bug fixes - Upstream changelog for this release: https://drupal.org/node/1632574 * Sat Aug 3 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 2.0-0.8.rc1 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild References: [ 1 ] Bug #993735 - drupal7-strongarm possibly affected by F-20 unversioned docdir change https://bugzilla.redhat.com/show_bug.cgi?id=993735 ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL Fedora 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 565 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6 79 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11274/ssmtp-2.61-21.el6 40 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11703/chicken-4.8.0.4-4.el6 28 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11785/phpMyAdmin-3.5.8.2-1.el6 21 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11865/quassel-0.9.1-1.el6 10 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11970/python-backports-ssl_match_hostname-3.4.0.2-1.el6 5 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12025/seamonkey-2.22-1.el6 1 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12040/python-djblets-0.7.23-1.el6,ReviewBoard-1.7.17-1.el6.1 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12064/drupal7-context-3.1-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing RemoteBox-1.1-1.el6 alpine-2.11-1.el6 dnsyo-1.1.4-2.el6 drupal7-context-3.1-1.el6 drupal7-strongarm-2.0-1.el6 hg-git-0.4.0-2.el6 rubygem-passenger-3.0.21-11.el6 sysusage-5.3-2.el6 youtube-dl-2013.11.07-1.el6 Details about builds: RemoteBox-1.1-1.el6 (FEDORA-EPEL-2013-12061) Open Source VirtualBox Client with Remote Management Update Information: Rebase to 1.1. References: [ 1 ] Bug #1026110 - RemoteBox 1.6.2.el6 has unsatisfied dependencies https://bugzilla.redhat.com/show_bug.cgi?id=1026110 [ 2 ] Bug #954074 - Review Request: RemoteBox - Open Source VirtualBox Client with Remote Management https://bugzilla.redhat.com/show_bug.cgi?id=954074 alpine-2.11-1.el6 (FEDORA-EPEL-2013-12008) powerful, easy to use console email client Update Information: new 2.11 bugfix release. ChangeLog: * Wed Nov 6 2013 Rex Dieter rdie...@fedoraproject.org 2.11-1 - alpine-2.11, drop old/unused patches * Thu Oct 31 2013 Rex Dieter rdie...@fedoraproject.org 2.10-4 - re-add README.fedora * Sat Aug 3 2013 Dennis Gilmore den...@ausil.us - 2.10-3 - remove refrences to non existant README.fedora file * Sat Aug 3 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 2.10-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild * Fri Mar 15 2013 Paul Wouters pwout...@redhat.com - 2.10-1 - Build from new upstream for 2.10, fixes rhbz#838359 * Wed Feb 13 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 2.03-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild References: [ 1 ] Bug #838359 - alpine crashes when suspending in password prompt mode https://bugzilla.redhat.com/show_bug.cgi?id=838359 dnsyo-1.1.4-2.el6 (FEDORA-EPEL-2013-12059) Check DNS against many global DNS servers Update Information: Latest upstream release Latest upstream version New package: dnsyo. References: [ 1 ] Bug #1021091 - Review Request: dnsyo - Check DNS against many global DNS servers https://bugzilla.redhat.com/show_bug.cgi?id=1021091 drupal7-context-3.1-1.el6 (FEDORA-EPEL-2013-12064) Allows you to manage contextual conditions and reactions of your site Update Information: - Update to upstream 3.1 release for bug fixes - Upstream changelog for this release: https://drupal.org/node/2113785 - Fixes CVE-2013-4445, CVE-2013-4446 BZ 1020777, BZ 1020262, BZ 1020781, BZ 1020784 Upstream updated to rc1 ChangeLog: * Fri Nov 8 2013 Peter Borsa peter.bo...@gmail.com - 3.1-1 - Update to upstream 3.1 release for bug fixes - Upstream changelog for this release: https://drupal.org/node/2113785 - Fixes CVE-2013-4445,
Re: [Base] Summary/Minutes from today's Base WG meeting (2013-11-08)
Dennis Gilmore (den...@ausil.us) said: Meeting started by pknirsch at 15:00:59 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2013-11-08/fedora_base_design_working_group.2013-11-08-15.00.log.html Apologies for not making the meeting. Some comments * LINK: http://fpaste.org/52688/38392758/ (pknirsch, 16:19:54) * Base definition: installer, compose tools, minimal install (for some definition there), and functionality the majority products want to use (pknirsch, 16:21:30) My concern with this, as a base design, is that the current implementation of anaconda leads to a dependency tree that is *not* small; it's much larger than the minimal install, as it extends to storage tools, NetworkManager, graphical toolsets, and other items. (You could even arguably pull in X and in the future wayland.) It's not a *bad* thing to have as a base design - I could make the argument that changes in that base (NM, X, etc.) are all things that should be coordinated as a layer under the separate products. But it does give a wider area of coverage than may be expected. (Also, stabilizing the build dependencies therein. Wheee.) Bill -- 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 QA] #432: Test day results app should be more navigable: create an event, export results, view all events
#432: Test day results app should be more navigable: create an event, export results, view all events +--- Reporter: adamwill| Owner: jskladan Type: enhancement | Status: new Priority: major | Milestone: Component: QA tools: test day app | Version: Keywords: | Blocked By: Blocking: | +--- I find myself having to refer to the Test Day SOP or https://fedoraproject.org/wiki/User:Jskladan/Sandbox:TestdayApp all the time to find the 'magic URLs' to do anything with the test day results app. It's not very internally navigable - you can't find your way from any given part of the UI to the 'new event' or 'export results' or 'view all events' pages, so far as I can tell. It might be nice if there were more internal links, and perhaps if the content from https://fedoraproject.org/wiki/User:Jskladan/Sandbox:TestdayApp were put somewhere more permanent and linked to from within the app itself. -- Ticket URL: https://fedorahosted.org/fedora-qa/ticket/432 Fedora QA http://fedorahosted.org/fedora-qa Fedora Quality Assurance ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: [Base] Summary/Minutes from today's Base WG meeting (2013-11-08)
On Fri, 2013-11-08 at 10:51 -0600, Dennis Gilmore wrote: * LINK: http://fpaste.org/52688/38392758/ (pknirsch, 16:19:54) * Base definition: installer, compose tools, minimal install (for some definition there), and functionality the majority products want to use (pknirsch, 16:21:30) Hey, I read your minutes, and discussed some of my thoughts on this with my workstation wg peers. Basically, I think that defining a 'base' as a particular set of packages (minimal install, or some variant thereof) does not really provide us what we need to build one or more products.' What we really need as a base is a definition of the apis that are guaranteed to be stable and that the products and applications can rely on. Packages can to some extent serve as a proxy for that, but they are really just an implementation detail of how the product is put together. For example, when you talk about an OS being systemd-based, the important part is not that systemd is part of the minimal install, but the fact that applications can rely on org.freedesktop.login1 and so on being available on the session bus, and that installing a unit file in /usr/lib/systemd/system is the proper way to make a service known to the system, etc. There will of course be APIs that are product-specific. Eg, the server product might define a remote management api that is not relevant for a workstation. And desktop applications running on the workstation need to know which session services they can rely on. Just my 2 cents, Matthias -- 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: Draft Product Description for Fedora Workstation
On Fri, Nov 8, 2013 at 2:31 PM, Michael scherer m...@zarb.org wrote: On Thu, Nov 07, 2013 at 09:55:12PM +0100, Miloslav Trmač wrote: On Thu, Nov 7, 2013 at 9:48 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Thu, 07.11.13 20:09, Miloslav Trmač (m...@volny.cz) wrote: Is there a technical reason why we can't use their packaging format, interpreting it with our technologies but staying compatible? Well, the most relevant bit is that they use apparmor for sandboxing. Nobody else uses that. Are the packages expected to ship their own apparmor policy? That would appear to be at odds with the idea of protecting against malicious packages. If they aren't expected to ship their own, could we implement the same sandboxing policy using SELinux? (https://wiki.ubuntu.com/AppDevUploadProcess seems to suggest Ubuntu will be using some higher-level profile format, not raw AppArmor.) The whole plan is here : https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement Looking at : https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement/Manifest I would say no. From a quick look, some abstraction are quite apparmor specific, see the concept of read_path, which is something we can hardly translate to selinux ( since apparmor use path, while selinux use a 2 tier system with label assigned to path, and then privileges assigned based on label ). Yes, that's one thing that we cannot (and shouldn't) support, but read_path is listed in the Red-flagged for manual review (use should actively be discouraged with updates made to policy groups and templates) section; is it likely to be frequently used? Mirek What we could do is to have a better abstraction that would be apparmor and selinux comptaible. Since despites what Lennart claim, AppArmor is also used by Opensuse. And I am sure people using smackd ( such as intel people ) would be delighted to not be left in the cold. SELinux is still pretty RH/Fedora specific, even if Debian and gentoo support it in theory ( in practice, Debian didn't seems to support it that well ). And I don't think it is a good idea to use .deb as an image format. .deb is just an ar archive; if this were the only difference, it would not be worth fragmenting the ecosystem over IMHO. (Especially if the GNOME apps alternative is a compressed disk image, which saves disk space and costs extra CPU time and memory, making exactly the wrong tradeoff in most situations AFAICS.) While I do not see any obvious problem into using deb, I do not think it will bring much gain. It will matter for people managing the low level format, ie few people. Reusing the manifests ( if it was doable ) would have yield much more gain. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Summary/Minutes from today's Base WG meeting (2013-11-08)
Forgot one thing - the installer question. I think it already came up tangentially in some of the workstation prd discussions, but I think we should at least be open to the idea that the different products need to be able to define their own install experience. That would imply that the 'installer' you mention as part of base should perhaps be just a shared installer backend which can support different frontends. I know the anaconda team has been working towards establishing such a separation, with kickstart being the interface between frontend and backend. I don't know how far that got though, so maybe this is more of a long-term goal. Just wanted to mention 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: Workstation PRD summary and next steps
Hello, On Thu, Nov 7, 2013 at 10:55 PM, Christian Schaller cscha...@redhat.com wrote: The next update of the PRD will be posted to the fedora-desktop list as that is the designated 'home' of the working group and product and we want to avoid cluttering up the general Fedora-devel list with product specific further discussion. That's fine for the intermediate versions; please do post a at least near-final version to the wider community before asking the Board to ratify it. Mirek -- 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: Workstation PRD summary and next steps
On Fri, Nov 8, 2013 at 3:38 PM, Miloslav Trmač m...@volny.cz wrote: Hello, On Thu, Nov 7, 2013 at 10:55 PM, Christian Schaller cscha...@redhat.com wrote: The next update of the PRD will be posted to the fedora-desktop list as that is the designated 'home' of the working group and product and we want to avoid cluttering up the general Fedora-devel list with product specific further discussion. That's fine for the intermediate versions; please do post a at least near-final version to the wider community before asking the Board to ratify it. I think you mean FESCo? 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: Workstation PRD summary and next steps
On Fri, Nov 8, 2013 at 10:01 PM, Josh Boyer jwbo...@fedoraproject.org wrote: On Fri, Nov 8, 2013 at 3:38 PM, Miloslav Trmač m...@volny.cz wrote: Hello, On Thu, Nov 7, 2013 at 10:55 PM, Christian Schaller cscha...@redhat.com wrote: The next update of the PRD will be posted to the fedora-desktop list as that is the designated 'home' of the working group and product and we want to avoid cluttering up the general Fedora-devel list with product specific further discussion. That's fine for the intermediate versions; please do post a at least near-final version to the wider community before asking the Board to ratify it. I think you mean FESCo? https://fedoraproject.org/wiki/Fedora.next/boardproposal says be presented to the Board for ratification. Mirek -- 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: Workstation PRD summary and next steps
On Fri, Nov 8, 2013 at 4:06 PM, Miloslav Trmač m...@volny.cz wrote: On Fri, Nov 8, 2013 at 10:01 PM, Josh Boyer jwbo...@fedoraproject.org wrote: On Fri, Nov 8, 2013 at 3:38 PM, Miloslav Trmač m...@volny.cz wrote: Hello, On Thu, Nov 7, 2013 at 10:55 PM, Christian Schaller cscha...@redhat.com wrote: The next update of the PRD will be posted to the fedora-desktop list as that is the designated 'home' of the working group and product and we want to avoid cluttering up the general Fedora-devel list with product specific further discussion. That's fine for the intermediate versions; please do post a at least near-final version to the wider community before asking the Board to ratify it. I think you mean FESCo? https://fedoraproject.org/wiki/Fedora.next/boardproposal says be presented to the Board for ratification. So it does! My mistake. Though I do hesitate to not run it past FESCo first. They're intimately involved in several areas, and that is the group that the WG liaisons ... liaise to. Getting a FESCo ack would probably go a long way with the Board. 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: Workstation PRD summary and next steps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/08/2013 04:06 PM, Miloslav Trmač wrote: On Fri, Nov 8, 2013 at 10:01 PM, Josh Boyer jwbo...@fedoraproject.org wrote: On Fri, Nov 8, 2013 at 3:38 PM, Miloslav Trmač m...@volny.cz wrote: Hello, On Thu, Nov 7, 2013 at 10:55 PM, Christian Schaller cscha...@redhat.com wrote: The next update of the PRD will be posted to the fedora-desktop list as that is the designated 'home' of the working group and product and we want to avoid cluttering up the general Fedora-devel list with product specific further discussion. That's fine for the intermediate versions; please do post a at least near-final version to the wider community before asking the Board to ratify it. I think you mean FESCo? https://fedoraproject.org/wiki/Fedora.next/boardproposal says be presented to the Board for ratification. Oof, good point. I submitted the ServerWG to the wrong group. *fixes* -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJ9VWoACgkQeiVVYja6o6OmgQCfTUHwlidg/SZMNqmC0DwNMFWM Hr8An2Jnbdtvz8PbCEvJpG9nfsaUJ500 =XcIB -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Workstation PRD summary and next steps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/08/2013 04:19 PM, Stephen Gallagher wrote: On 11/08/2013 04:06 PM, Miloslav Trmač wrote: On Fri, Nov 8, 2013 at 10:01 PM, Josh Boyer jwbo...@fedoraproject.org wrote: On Fri, Nov 8, 2013 at 3:38 PM, Miloslav Trmač m...@volny.cz wrote: Hello, On Thu, Nov 7, 2013 at 10:55 PM, Christian Schaller cscha...@redhat.com wrote: The next update of the PRD will be posted to the fedora-desktop list as that is the designated 'home' of the working group and product and we want to avoid cluttering up the general Fedora-devel list with product specific further discussion. That's fine for the intermediate versions; please do post a at least near-final version to the wider community before asking the Board to ratify it. I think you mean FESCo? https://fedoraproject.org/wiki/Fedora.next/boardproposal says be presented to the Board for ratification. Oof, good point. I submitted the ServerWG to the wrong group. *fixes* https://fedorahosted.org/board/ticket/168 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJ9VkYACgkQeiVVYja6o6NO6wCaAoKV3TWezMGw4jIZ1/g2tXHh Cq4AoIcxTJrBiUjZb6MeSiD8vSyHEKQ2 =34IP -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Le vendredi 08 novembre 2013 à 21:24 +0100, Miloslav Trmač a écrit : On Fri, Nov 8, 2013 at 2:31 PM, Michael scherer m...@zarb.org wrote: On Thu, Nov 07, 2013 at 09:55:12PM +0100, Miloslav Trmač wrote: On Thu, Nov 7, 2013 at 9:48 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Thu, 07.11.13 20:09, Miloslav Trmač (m...@volny.cz) wrote: Is there a technical reason why we can't use their packaging format, interpreting it with our technologies but staying compatible? Well, the most relevant bit is that they use apparmor for sandboxing. Nobody else uses that. Are the packages expected to ship their own apparmor policy? That would appear to be at odds with the idea of protecting against malicious packages. If they aren't expected to ship their own, could we implement the same sandboxing policy using SELinux? (https://wiki.ubuntu.com/AppDevUploadProcess seems to suggest Ubuntu will be using some higher-level profile format, not raw AppArmor.) The whole plan is here : https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement Looking at : https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement/Manifest I would say no. From a quick look, some abstraction are quite apparmor specific, see the concept of read_path, which is something we can hardly translate to selinux ( since apparmor use path, while selinux use a 2 tier system with label assigned to path, and then privileges assigned based on label ). Yes, that's one thing that we cannot (and shouldn't) support, but read_path is listed in the Red-flagged for manual review (use should actively be discouraged with updates made to policy groups and templates) section; is it likely to be frequently used? I can imagine that for any application having some kind of private database ( like a list of music file, save for games, or scoreboard, etc ), this would be used. So yeah, not much, but not that uncommon either IMHO. But even on the others fields, there will be some issues like the need to keep the policy in sync ( for policy_groups ), and the need to keep the template in sync (as the system work by taking template to generate the policy). Keep in sync the content and the name. It could be doable to adapt, but I am quite sure that sooner or later, we will face problem to keep the SElinux and AppArmor policies in sync, due to the difference of approach. I also expect that a conversion wouldn't be straightforward due to different stacks, etc. I do not really see that as a sustainable approach. -- Michael Scherer -- 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: unaccessability
Matthias Clasen wrote: On Fri, 2013-11-08 at 14:06 +0200, Joonas Sarajärvi wrote: 2013/11/7 Christian Schaller cscha...@redhat.com: Ok, so I guess the solution would be for the launcher to do something like this: gnome-terminal --geometry 80x37 --disable-factory --role=bitchx --class=bitchx --name bitchX IRC --title BitchX IRC Isn't the Terminal attribute of desktop files[1] supposed to tell the launcher program that it should start the application inside a terminal? My impression is that Gnome at least used to support it, and I know that KDE does support it. It should quite easily allow specifying launchers for terminal-based programs that do not usually need command line arguments. [1] [http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html GNOME supports the Terminal key just fine. But just having your commandd run in a terminal is not quite enough to give it an identity as a separate application - to the rest of the system it will appear just as a terminal. The extra arguments that Christian shows there help to overcome this problem. But they hardcode the terminal application to gnome-terminal, which is unacceptable! Kevin Kofler -- 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: Workstation PRD summary and next steps
Christian Schaller wrote: The next update of the PRD will be posted to the fedora-desktop list as that is the designated 'home' of the working group and product and we want to avoid cluttering up the general Fedora-devel list with product specific further discussion. In other words, you want to move all discussion to a list that's mostly only followed by GNOME people where you can expect all changes to be swept through without any criticism… By the way, I also sense a contradiction in that it has been claimed several times that no decision on the desktop environment(s) to be shipped has been made, yet I see several posts making the implied assumption that it will be GNOME. Kevin Kofler -- 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: Workstation PRD summary and next steps
On Sat, 2013-11-09 at 01:03 +0100, Kevin Kofler wrote: Christian Schaller wrote: The next update of the PRD will be posted to the fedora-desktop list as that is the designated 'home' of the working group and product and we want to avoid cluttering up the general Fedora-devel list with product specific further discussion. In other words, you want to move all discussion to a list that's mostly only followed by GNOME people where you can expect all changes to be swept through without any criticism… No, we want to move to a forum where the working group members have a chance to discuss things without being drowned out by 100+ mails/day from you. The other working groups are doing the same on their respective mailing lists. -- 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: unaccessability
- Original Message - snip But they hardcode the terminal application to gnome-terminal, which is unacceptable! Just don't use GNOME? More seriously, this is the bug with the instructions on how to write the terminal chooser patch for glib: https://bugzilla.gnome.org/show_bug.cgi?id=627943 So far, not one of the people that so really badly needs their own terminal emulator selected by glib either wrote a patch, or paid somebody to write that patch. (Were these the power users you spoke of?) I don't think anyone's going to work on this, so feel free to pick it up. -- 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: unaccessability
On Sat, 09 Nov 2013 00:58:05 +0100 Kevin Kofler kevin.kof...@chello.at wrote: Matthias Clasen wrote: On Fri, 2013-11-08 at 14:06 +0200, Joonas Sarajärvi wrote: 2013/11/7 Christian Schaller cscha...@redhat.com: Ok, so I guess the solution would be for the launcher to do something like this: gnome-terminal --geometry 80x37 --disable-factory --role=bitchx --class=bitchx --name bitchX IRC --title BitchX IRC Isn't the Terminal attribute of desktop files[1] supposed to tell the launcher program that it should start the application inside a terminal? My impression is that Gnome at least used to support it, and I know that KDE does support it. It should quite easily allow specifying launchers for terminal-based programs that do not usually need command line arguments. [1] [http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html GNOME supports the Terminal key just fine. But just having your commandd run in a terminal is not quite enough to give it an identity as a separate application - to the rest of the system it will appear just as a terminal. The extra arguments that Christian shows there help to overcome this problem. But they hardcode the terminal application to gnome-terminal, which is unacceptable! Let me rephrase that in a way that is more productive: Would it be possible to use xdg-terminal or whatever is set as default handler for application/x-xdg-terminal-emulator to run the command? That may well have reduced functionality, but still might fit in with what the user set. kevin signature.asc 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
Re: Workstation PRD summary and next steps
On 11/09/2013 01:14 AM, Matthias Clasen wrote: On Sat, 2013-11-09 at 01:03 +0100, Kevin Kofler wrote: Christian Schaller wrote: The next update of the PRD will be posted to the fedora-desktop list as that is the designated 'home' of the working group and product and we want to avoid cluttering up the general Fedora-devel list with product specific further discussion. In other words, you want to move all discussion to a list that's mostly only followed by GNOME people where you can expect all changes to be swept through without any criticism… No, we want to move to a forum where the working group members have a chance to discuss things without being drowned out by 100+ mails/day from you. The other working groups are doing the same on their respective mailing lists. I am sure these lists will be public and open to everybody? 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: Workstation PRD summary and next steps
Le samedi 09 novembre 2013 à 01:21 +0100, Ralf Corsepius a écrit : On 11/09/2013 01:14 AM, Matthias Clasen wrote: On Sat, 2013-11-09 at 01:03 +0100, Kevin Kofler wrote: Christian Schaller wrote: The next update of the PRD will be posted to the fedora-desktop list as that is the designated 'home' of the working group and product and we want to avoid cluttering up the general Fedora-devel list with product specific further discussion. In other words, you want to move all discussion to a list that's mostly only followed by GNOME people where you can expect all changes to be swept through without any criticism… No, we want to move to a forum where the working group members have a chance to discuss things without being drowned out by 100+ mails/day from you. The other working groups are doing the same on their respective mailing lists. I am sure these lists will be public and open to everybody? They already are : https://lists.fedoraproject.org/pipermail/desktop/2013-November/thread.html https://lists.fedoraproject.org/pipermail/server/2013-November/thread.html ( and looking for the others is left as a exercise for the reader ) It was also posted on devel-announce : https://lists.fedoraproject.org/pipermail/devel-announce/2013-October/001258.html -- Michael Scherer -- 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] 2013-11-11 @ 16:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2013-11-11 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! It's meeting time again on Monday! (I'm being all organized and sending this out on Friday, yay me.) Beta is done now, so let's look back on it and forward to Final. It would also probably be a good idea to take a look at the Fedora.next proposals currently in progress. This is a reminder of the upcoming QA meeting. Please add any topic suggestions to the meeting wiki page: https://fedoraproject.org/wiki/QA/Meetings/2013 The current proposed agenda is included below. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 20 Beta retrospective 3. Fedora 20 Final planning 4. Fedora.next thoughts so far 5. Open floor -- 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
[Test-Announce] Fedora 20 QA Retrospective page is up
The Retrospective page for Fedora 20 QA is now up (a bit late, but not
as late as last time...):
https://fedoraproject.org/wiki/Fedora_20_QA_Retrospective
We use the retrospective page to track things that went well and things
that didn't go so well during the Fedora 20 validation process, and for
tracking ideas we have but don't have time to act on during the rush of
doing validation (that's the wishlist).
Please, add any feedback you have of this type to the retrospective
page! There are instructions on the page for adding feedback.
All feedback is useful, and once 20 validation is done, we'll take a
look at all the items on the page and come up with specific
recommendations for addressing them which we'll file as trac tickets and
work on in the time before Fedora 21 validation starts up. We've been
doing this for a while now and it's turned out to be a great way to keep
constantly improving our processes.
You can look at the previous pages for inspiration:
https://fedoraproject.org/wiki/Category:QA_Retrospective
And I'll copy/paste James' old list of leading questions to prompt
feedback (thanks, James!):
1. Were you able to participate in any Fedora 20 Alpha, Beta or
Final test runs?
2. What worked well, what prevented you from participating, were
instructions clear?
3. What worked (or didn't work) well about Fedora Test Days this
release?
4. Are you a maintainer, why do you think your critpath updates
haven't been tested? What could you do to encourage more
testing of your proposed updates?
5. Did you escalate any bugs for consideration as
{Alpha,Beta,Final} release Blockers? Why not? Was the process
well documented and did it make sense?
6. Did you attend or contribute to any Fedora blocker meetings?
Why not? What did you like, dislike? What prevented you from
participating?
7. Did you find any of the release criteria changes or validation
test extensions particularly useful or problematic?
8. Can you think of any obviously important areas we are not
currently covering in the validation tests and criteria?
9. How are you finding the new tools that have been introduced over
the last few cycles, like the blocker bugs tool and the test day
results tool?
10. Unlimited time and resource ... what do you think the the QA
team should focus on for Fedora 21 and beyond /pony
--
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
Broken dependencies: perl-PDL
perl-PDL has broken dependencies in the F-20 tree: On x86_64: perl-PDL-2.4.10-6.fc19.x86_64 requires perl(:MODULE_COMPAT_5.16.2) perl-PDL-2.4.10-6.fc19.x86_64 requires libgd.so.2()(64bit) On i386: perl-PDL-2.4.10-6.fc19.i686 requires perl(:MODULE_COMPAT_5.16.2) perl-PDL-2.4.10-6.fc19.i686 requires libgd.so.2 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: slic3r
slic3r has broken dependencies in the F-20 tree: On x86_64: slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3) On i386: slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3) On armhfp: slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-BerkeleyDB
perl-BerkeleyDB has broken dependencies in the F-20 tree: On x86_64: perl-BerkeleyDB-0.53-1.fc20.x86_64 requires libdb = 0:5.3.21 On i386: perl-BerkeleyDB-0.53-1.fc20.i686 requires libdb = 0:5.3.21 On armhfp: perl-BerkeleyDB-0.53-1.fc20.armv7hl requires libdb = 0:5.3.21 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-MIME-Lite-HTML
perl-MIME-Lite-HTML has broken dependencies in the F-20 tree: On x86_64: perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On i386: perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On armhfp: perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Padre
perl-Padre has broken dependencies in the F-20 tree: On x86_64: perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On i386: perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On armhfp: perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Language-Expr
perl-Language-Expr has broken dependencies in the F-20 tree: On x86_64: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Review Request: perl-DBD-ODBC - ODBC Driver for DBI
Hello there, would someone please review package in $subj, bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=1028521 ? Thanks! Cheers Jan -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1024821] ctstream-9 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1024821 --- Comment #5 from Fedora Update System upda...@fedoraproject.org --- ctstream-9-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=4VPnFthUkla=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1024821] ctstream-9 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1024821 --- Comment #6 from Fedora Update System upda...@fedoraproject.org --- ctstream-9-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=A1M0H3Y89ba=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1006003] perl-version-0.9904 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1006003 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|MODIFIED|CLOSED Fixed In Version||perl-version-0.99.04-2.fc20 Resolution|--- |CURRENTRELEASE Last Closed||2013-11-09 01:20:10 -- 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=fKpgP1R1rIa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1028653] New: Freshclam cannot notify clamd of database updates due to permission denied
https://bugzilla.redhat.com/show_bug.cgi?id=1028653
Bug ID: 1028653
Summary: Freshclam cannot notify clamd of database updates due
to permission denied
Product: Fedora
Version: 19
Component: amavisd-new
Severity: low
Assignee: st...@silug.org
Reporter: rocketra...@gmail.com
QA Contact: extras...@fedoraproject.org
CC: enrico.sch...@informatik.tu-chemnitz.de,
kana...@kanarip.com,
perl-devel@lists.fedoraproject.org,
redhat-bugzi...@linuxnetz.de, st...@silug.org
The problem initially reported in Bug #548234 is happening again. Here are the
permissions on /var/spool/amavisd with a default installation of amavisd-new:
# ls -ld /var/spool/amavisd
drwx--x---. 8 amavis amavis 4096 May 10 13:27 /var/spool/amavisd
# rpm -q --info amavisd-new
Name: amavisd-new
Version : 2.8.0
Release : 5.fc19
The permissions and group ownership for /var/spool/amavisd should be:
# ls -ld /var/spool/amavisd
drwxrwx---. 8 amavis clamupdate 4096 May 10 13:27 /var/spool/amavisd
^^^ ^^
+++ This bug was initially created as a clone of Bug #548234 +++
clamav-update (freshclam) is unable to notify clamav of updates to the database
via local socket.
This is on a fresh newly installed Fedora 12 system (not an upgrade). The
following package versions are installed:
clamav-0.95.2-5.fc12.i686
clamav-lib-0.95.2-5.fc12.i686
clamav-server-0.95.2-5.fc12.i686
clamav-filesystem-0.95.2-5.fc12.noarch
clamav-update-0.95.2-5.fc12.i686
clamav-data-0.95.2-5.fc12.noarch
amavisd-new-2.6.4-1.fc12.noarch
How reproducible:
Every time.
Steps to Reproduce:
1. Delete /var/lib/clamav/daily.cld
2. Run freshclam
Actual results:
Freshclam gets the following error:
WARNING: Clamd was NOT notified: Can't connect to clamd through
/var/spool/amavisd/clamd.sock
connect(): Permission denied
Expected results:
Notify works correctly.
Additional info:
I have configured /etc/freshclam.conf with
AllowSupplementaryGroups yes
and also added the clamupdate user to the amavis group:
# grep -E (amavis|clamupdate) /etc/passwd
clamupdate:x:490:471:Clamav database update user:/var/lib/clamav:/sbin/nologin
amavis:x:489:470::/var/spool/amavisd:/sbin/nologin
# grep -E (amavis|clamupdate) /etc/group
clamupdate:x:471:
amavis:x:470:clamupdate
I can also confirm that freshclam is using the clamupdate user and is loading
the supplementary amavis group via strace, where I can see this information
near the top of the trace:
setgroups32(2, [471, 470]) = 0
setgid32(471) = 0
setuid32(490) = 0
However, freshclam still fails. This is the access failure from the strace:
connect(5, {sa_family=AF_FILE, path=/var/spool/amavisd/clamd.sock}, 110) = -1
EACCES (Permission denied)
Permissions on the clamd.sock file are as follows:
# ls -l /var/spool/amavisd/clamd.sock
srwxrwxrwx 1 amavis amavis 0 2009-12-16 19:04 /var/spool/amavisd/clamd.sock
# stat /var/spool/amavisd/clamd.sock
File: `/var/spool/amavisd/clamd.sock'
Size: 0 Blocks: 0 IO Block: 4096 socket
Device: fd01h/64769dInode: 5243668 Links: 1
Access: (0777/srwxrwxrwx) Uid: ( 489/ amavis) Gid: ( 470/ amavis)
Access: 2009-12-16 19:07:10.706297129 -0500
Modify: 2009-12-16 19:04:36.167296751 -0500
Change: 2009-12-16 19:04:36.167296751 -0500
--- Additional comment from Enrico Scholz on 2009-12-17 03:38:52 EST ---
what are the permissions for the /var/spool/amavisd directory? Are there
SELinux avcs?
--- Additional comment from Raman Gupta on 2009-12-17 12:04:13 EST ---
Yup, /var/spool/amavisd directory permissions are set to 700 -- sorry I should
have noticed that. Changing them to 770 works.
Should changing these directory perms be permanently applied to the amavisd-new
package? The user/group is amavis and the amavis group has no other users in it
by default, so changing the perms to 770 is effectively the same access level
by default. However, changing the perm to 770 in the package would allow clamav
notifications to work as expected out of the box (with the appropriate config
and supplementary group entries of course, but a user expects to make those)
[1]. It would also prevent people's notifications from breaking every time
there is an update to the amavisd-new package, and the directory permissions
are reset.
If you think this is a good idea, could you change the component to amavisd-new
and mark this as an enhancement?
[1] Note I don't have selinux enabled so perhaps there might be a package
change to selinux perms as well.
--- Additional comment from Enrico Scholz on 2010-01-17 05:06:24 EST ---
reassigned to amavisd-new
--- Additional comment from Bug Zapper on 2010-11-03 23:09:21 EDT ---
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately
[389-devel] Please review: [389 Project] #47589: Winsync replica initialization and incremental updates from DS to AD fails on RHEL7
https://fedorahosted.org/389/ticket/47589 https://fedorahosted.org/389/attachment/ticket/47589/0001-Ticket-47589-Winsync-replica-initialization-and-incr.patch Bug description: Cherry-picking the fix for Ticket #47492 - PassSync removes User must change password flag on the Windows side (commit 8d34f77f6d8d3c83dce1f29e6df709df1adef09d) dropped one line to set suffix in map_entry_dn_outbound. Fix description: This patch recovers the suffix setting code. Note: this fix requires 389-ds-base-1.3.1 respin. -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
