Re: Sponsors - who does (not) work on FE-NEEDSPONSOR tickets
2015-08-15 9:13 GMT+02:00 Miroslav Suchý : > Recently we had discussion here about the queue of package reviews with > FE-NEEDSPONSOR flag. > I suggested to write some script which would query db and reveal those > sponsors who does not make his duty. > > Here comes this script: >https://github.com/xsuchy/guard-fedora-sponsors > > It is first version and I'm sure there will be some false negatives. The > current logic is: > 1. query FAS to get all usernames from packager group who are sponsors > 2. for each such user get all bugs from past 365 day for Package Review > component which are assigned to this sponsor > 3. give the sponsor some credit when he changed bug status (to whatever > state) as this indicate some work on this bug > 4. give the sponsor some credit if he remove FE-NEEDSPONSOR from blocking > bugs as this indicate finishing sponsor work > > This does not reflect if you sponsor somebody directly. Hi Miroslav, this is not the only problem with your script. I think the underlying definition of "sponsoring work" is flawed. A sponsor not only sponsors new contributors into the packager group but acts as guide ever after. Even though I have not accepted any new candidates throughout the last year, I still look after all of my 24 protégés. I not only answer questions when they occur, I also look at every commit, build and update. This of course, takes some time and thus limits the number of packagers a sponsor can take care of. While I see the need for sponsoring new contributors in a timely manner, I always found the focus on sponsoring as many as possible questionable. And I'm afraid your script can encourage this behavior, no matter if the output says "no sponsor work" or "recent sponsor activity". I think the least you should do is change the wording to "has not accepted any new candidates" or alike, but you will never be able to know who did actual "sponsor work". Best regards, Christoph -- 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 18 laptop regression
Am Samstag, den 05.01.2013, 23:38 +0100 schrieb Lennart Poettering: > On Sat, 05.01.13 09:14, alex...@hushmail.com (alex...@hushmail.com) wrote: > > > Closing the laptop lid now suspends, without a visible option to > disable it. > > You can edit /etc/systemd/logind.conf and your laptop won't suspend > after closing the lid, but the screen _won't_ lock either!!! > > > > So, either you have to suspend or your screen doesn't lock. Any way > to fix this? logind.conf needs a "lockscreen" option, or a > "don't-ignore-but-pass-to-desktop-to-handle" option... > > Normally your DE will take a lock that disables handling of the lid > switch as long as the DE is up. How many DE actually to this? GNOME does, not sure about KDE, Sugar or Mate, but inhibit support seems to be the exception and not the rule Xfce and LXDE do not yet support it, so power management on these DEs is broken by default. A change that affects all desktops really should have been handled as a feature with approval from FESCo. Did you ever contact the relevant package maintainers? Did you at least bother to properly announce your changes? What do you suggest maintainers and users of other desktops should do now? Kind regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature (exception): Kolab 3
Am Montag, den 11.02.2013, 13:38 + schrieb Jaroslav Reznik: > This Feature has been submitted *after* Feature Submission Deadline and > requires exception from FESCo to be accepted as Fedora 19 Feature. > > Owner(s), please, provide motivation why do you think the exception should be > granted. 1. We can make it. We have all packages ready, they are even in production, we just need package reviews. 2. Even if we don't make it, there is absolutely zero impact on the release. 3. The feature submission deadline was poorly communicated. First the schedule was only preliminary, then it was finalized, but this changed not announced. The announcement about the final feature submission freeze was only one day before the actual freeze. To avoid feature exceptions, please make sure to announce changes to the schedule as they happen and not a day before the next milestone. Thanks, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature (exception): Kolab 3
Am Montag, den 11.02.2013, 12:42 -0800 schrieb Toshio Kuratomi: > On Mon, Feb 11, 2013 at 04:24:11PM +0100, Christoph Wickert wrote: > > Am Montag, den 11.02.2013, 13:38 + schrieb Jaroslav Reznik: > > 2. Even if we don't make it, there is absolutely zero impact on the > > release. > > based on this, seems like just a set of new packages. I'd be willing to +1 > based on this. > > I do see that there are some packages already in the distro that are being > used by kolab, for instance roundcubemail. Are those simply dependencies? > They don't need any modification in order to work with kolab? Kolab doesn't require any changes in other packages. roundcube needed a couple of modifications, but these have been happening upstream. Kolab Systems is the driving force behind the roundcube development. A lot of work has gone into the address book and the plugin interface, but this is not Kolab-specific and already included in the Fedora packages. Same goes for other cyrus and others. We've upstreamed *all* our patches. The days where we had to patch php are over. That was a no-go for Fedora and now that this blocker is gone, I'd like to see Kolab in Fedora ASAP. Kind regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: retiring epdfview
Am Donnerstag, den 14.02.2013, 11:59 +0100 schrieb Michal Schmidt: > Hello, > > epdfview, a light-weight PDF viewer, is not maintained upstream anymore. > The upstream developer recommends to switch to evince-gtk (a build of > evince with minimal dependencies, requested in BZ#906121) or zathura. I > am going to retire epdfview from Fedora. > > epdfview is used in Xfce and LXDE spins. The maintainers need to decide > what to do. My suggestion is to use evince-gtk once/if it becomes available. Hi Michal, thanks for the heads-up. I fully agree to your suggestion. I already packaged zathura, but it's too minimalistic (zero mouse control, only vim keybindings) for me and probably most other people and I decided to not submit it for review. Kind regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Mass closing EOL bugs should not close bugs with pending updates
Hi there, I found that a couple of F16 bugs were closed by endoflife@fp.o even though there were pending updates for F17 and F18 to fix them. As a result, the bugs are now closed WONTFIX even they were or are going to be fixed. Should we expect the bugzappers to not mass-close bugs that are in MODIFIED or ON_QA state or require maintainers to upgrade the bugs to a supported release even though they were originally filed in against an older version? Best regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass closing EOL bugs should not close bugs with pending updates
Am Sonntag, den 17.02.2013, 14:46 +0100 schrieb Tadej Janež: > On Sun, 2013-02-17 at 12:02 +0100, Christoph Wickert wrote: > > > > I found that a couple of F16 bugs were closed by endoflife@fp.o even > > though there were pending updates for F17 and F18 to fix them. As a > > result, the bugs are now closed WONTFIX even they were or are going to > > be fixed. > > What you describe is another example of strange behavior of the Fedora > EOL Closure script. > I discovered two related problems that I described three days ago: > http://lists.fedoraproject.org/pipermail/devel/2013-February/178649.html > > Since then I found a page that describes the Fedora 16 EOL Closure > procedure: > https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora18#Fedora_16_EOL_Closure > > It says that the bugs with "version == Fedora 16" and "status != CLOSED" > are subject to automatic closure. Could you give an example of a bug > that you described? https://admin.fedoraproject.org/updates/FEDORA-2013-2359/lxpanel-0.5.12-1.fc18 and https://admin.fedoraproject.org/updates/FEDORA-2013-2359/lxpanel-0.5.12-1.fc17 fix several bugs, among them two very old and annoying ones: https://bugzilla.redhat.com/show_bug.cgi?id=782431 and https://bugzilla.redhat.com/show_bug.cgi?id=785906 As you can see the bugs were already ON_QA before they were closed WONTFIX. Kind regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass closing EOL bugs should not close bugs with pending updates
Am Sonntag, den 17.02.2013, 16:12 -0500 schrieb Orcan Ogetbil: > On Sun, Feb 17, 2013 at 3:26 PM, Christoph Wickert wrote: > > Am Sonntag, den 17.02.2013, 14:46 +0100 schrieb Tadej Janež: > >> On Sun, 2013-02-17 at 12:02 +0100, Christoph Wickert wrote: > >> > > >> > I found that a couple of F16 bugs were closed by endoflife@fp.o even > >> > though there were pending updates for F17 and F18 to fix them. As a > >> > result, the bugs are now closed WONTFIX even they were or are going to > >> > be fixed. > >> > >> What you describe is another example of strange behavior of the Fedora > >> EOL Closure script. > >> I discovered two related problems that I described three days ago: > >> http://lists.fedoraproject.org/pipermail/devel/2013-February/178649.html > >> > >> Since then I found a page that describes the Fedora 16 EOL Closure > >> procedure: > >> https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora18#Fedora_16_EOL_Closure > >> > >> It says that the bugs with "version == Fedora 16" and "status != CLOSED" > >> are subject to automatic closure. Could you give an example of a bug > >> that you described? > > > > https://admin.fedoraproject.org/updates/FEDORA-2013-2359/lxpanel-0.5.12-1.fc18 > > and > > https://admin.fedoraproject.org/updates/FEDORA-2013-2359/lxpanel-0.5.12-1.fc17 > > fix several bugs, among them two very old and annoying ones: > > https://bugzilla.redhat.com/show_bug.cgi?id=782431 and > > https://bugzilla.redhat.com/show_bug.cgi?id=785906 > > > > As you can see the bugs were already ON_QA before they were closed > > WONTFIX. > > > > But those are bugs filed against Fedora 16. Will Fedora 16 receive the > fix at this point? No. Hence WONTFIX is correct. No it's not. The bug is resolved in a later release of Fedora, thus CURRENTRELEASE or NEXTRELEASE are correct. WONTFIX implies it was not fixed it all. > Either the person who filed the bug, or the assignee could have bumped > the bug's Fedora version in the given timeframe, but they did not. I > think the 28 day period was sufficient amount of time to react. I agree, but I don't think we can rely on the bug reporters, nor on the maintainers. Therefor I suggest to not mass close bugs which are already ON_QA, in fact, that's what the bugzappers documentation says, too. Best regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass closing EOL bugs should not close bugs with pending updates
Am Montag, den 18.02.2013, 07:12 -0500 schrieb Jaroslav Reznik: > - Original Message - > > Am Sonntag, den 17.02.2013, 14:46 +0100 schrieb Tadej Janež: > > > On Sun, 2013-02-17 at 12:02 +0100, Christoph Wickert wrote: > > > > > > > > I found that a couple of F16 bugs were closed by endoflife@fp.o > > > > even > > > > though there were pending updates for F17 and F18 to fix them. As > > > > a > > > > result, the bugs are now closed WONTFIX even they were or are > > > > going to > > > > be fixed. > > > > > > What you describe is another example of strange behavior of the > > > Fedora > > > EOL Closure script. > > > I discovered two related problems that I described three days ago: > > > http://lists.fedoraproject.org/pipermail/devel/2013-February/178649.html > > > > > > Since then I found a page that describes the Fedora 16 EOL Closure > > > procedure: > > > https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora18#Fedora_16_EOL_Closure > > > > > > It says that the bugs with "version == Fedora 16" and "status != > > > CLOSED" > > > are subject to automatic closure. Could you give an example of a > > > bug > > > that you described? > > > > https://admin.fedoraproject.org/updates/FEDORA-2013-2359/lxpanel-0.5.12-1.fc18 > > and > > https://admin.fedoraproject.org/updates/FEDORA-2013-2359/lxpanel-0.5.12-1.fc17 > > fix several bugs, among them two very old and annoying ones: > > https://bugzilla.redhat.com/show_bug.cgi?id=782431 and > > https://bugzilla.redhat.com/show_bug.cgi?id=785906 > > > > As you can see the bugs were already ON_QA before they were closed > > WONTFIX. > > But for F16 - it's true - the fix is not going to be available in F16, > thus WONTFIX. I disagree. We have CURRENTRELEASE and NEXTRELEASE and they are exactly for this purpose. A bug appeared in an older version, it was filed against this version and as the bug affects that version, it should remain assigned to it. If it however gets fixed later, we should let our users know, thus we have the update fix that bug, so there is a link in bugzilla and the resolution becomes CURRENTRELEASE or NEXTRELEASE. > Correct resolution is to bump version to F17/F18 or clone bugs. Despite of the question whether it's right or wrong it's a manual process and we cannot rely it really happens. On the other hand changing the script to not close any bugs which are ON_QA is easy. So what is so bad about ignoring bugs MODIFIED and/or ON_QA bugs? Kind regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass closing EOL bugs should not close bugs with pending updates
Am Montag, den 18.02.2013, 23:34 + schrieb John5342: > On Mon, Feb 18, 2013 at 10:52 PM, Christoph Wickert > wrote: > > Despite of the question whether it's right or wrong it's a manual > > process and we cannot rely it really happens. On the other hand changing > > the script to not close any bugs which are ON_QA is easy. > > > > So what is so bad about ignoring bugs MODIFIED and/or ON_QA bugs? > > This is a corner case perhaps, but those bugs still need closing at > some point. If an updates-testing package gets un-pushed or never gets > sent to stable the bug will never be closed. Maybe it is a corner case, but what you describe is a corner case of the corner case. How many updates get actually withdrawn? 1%, 2%, 5%? > That means that the > script would need another rule that it _also_ closes bugs for the > release before regardless of MODIFIED/ON_QA. That's what it does already, no further rule needed. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [emelfm2] remove vendor tag from desktop file. https://fedorahosted.org/fpc/ticket/247
Am Dienstag, den 05.03.2013, 03:56 + schrieb Rahul Sundaram:
> commit 0ed4b2cddfa74be4b66b3646aee4c5d0e3fe756f
> Author: Rahul Sundaram
> Date: Mon Mar 4 22:55:58 2013 -0500
>
> remove vendor tag from desktop file.
> https://fedorahosted.org/fpc/ticket/247
>
> - drop obsolete conditionals and version requirements
> - drop INSTALL file
> - clean up spec to follow current guidelines
Hi Rahul,
if you want to help out in the effort to remove the vendor tags, please
do it *right*. That means:
* use conditionals, so maintainers can continue to use one spec
for F19 and other releases. Toshio provided examples at
https://fedoraproject.org/wiki/User:Toshio/Devendorize_desktop_files
* Don't rewrite spec files for no reason. There was no reason to
break compatibility with older releases such as el5.
* Don't use "current guidelines" to justify our changes.
Everything you changed were "may" or "should" items, but our
guidelines nowhere say that one *must not* have backwards
compatibility.
While I appreciate your efforts to help out in the de-vendorization, I
think the way *how* you did it is counterproductive and causes more work
for maintainers.
As I am currently very busy with my dayjob, I'd like to ask you to
please fix all of my packages you changed to use conditionals, so I can
continue to use one spec at least for all supported Fedora releases.
Kind regards,
Christoph
>
> emelfm2.spec | 64 ++---
> 1 files changed, 16 insertions(+), 48 deletions(-)
> ---
> diff --git a/emelfm2.spec b/emelfm2.spec
> index d0898ec..39a3a9c 100644
> --- a/emelfm2.spec
> +++ b/emelfm2.spec
> @@ -1,11 +1,6 @@
> -## Rebuild options:
> -# --with hal : Build with hal support (default: without)
> -# use bcond_without to change the default
> -%bcond_with hal
> -
> Name: emelfm2
> Version:0.8.2
> -Release:2%{?dist}
> +Release:3%{?dist}
> Summary:File manager that implements the popular two-pane design
>
> Group: Applications/File
> @@ -14,36 +9,18 @@ URL:http://emelfm2.net/
> Source0:http://emelfm2.net/rel/%{name}-%{version}.tar.bz2
> #VCS svn:http://svn.emelfm2.net/trunk/
> Patch0: emelfm2-0.7.1-dsofix.patch
> -BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u}
> -n)
>
> BuildRequires: dbus-glib-devel
> BuildRequires: file-devel
> -BuildRequires: gtk2-devel >= 2.6.0
> +BuildRequires: gtk2-devel
> BuildRequires: libacl-devel
> BuildRequires: gettext
> BuildRequires: desktop-file-utils
> Requires: findutils >= 4.2, grep, sed, bzip2
> -%if %{with hal}
> -BuildRequires: hal-devel, dbus-glib-devel
> -Requires: hal
> -%endif
> -
> -# only available in Fedora >= 11
> -%if 0%{?fedora} > 10
> -BuildRequires: gtkspell-devel >= 2.0.14
> -%endif
> -
> -# Fedora 13 uses udisks
> -%if 0%{?fedora} > 12 || 0%{?rhel} > 6
> +BuildRequires: gtkspell-devel
> BuildRequires: udisks-devel
> Requires: udisks
> -%else
> -# Fedora 11 uses DeviceKit
> -%if 0%{?fedora} > 10
> -BuildRequires: DeviceKit-disks-devel
> -Requires: DeviceKit-disks
> -%endif
> -%endif
> +
>
> %description
> emelFM2 is the GTK+2 port of emelFM. emelFM2 is a file manager that
> implements
> @@ -76,24 +53,15 @@ make %{?_smp_mflags} \
> WITH_TRANSPARENCY=1 \
> WITH_KERNELFAM=1 \
> USE_INOTIFY=1 \
> -%if 0%{?fedora} > 10 || 0%{?rhel} > 6
> - EDITOR_SPELLCHECK=1 \
> -%endif
> +EDITOR_SPELLCHECK=1 \
> WITH_OUTPUTSTYLES=1 \
> WITH_CUSTOMMOUSE=1 \
> WITH_GTK2=1 \
> NEW_COMMAND=1 \
> -%if 0%{?fedora} > 11 || 0%{?rhel} > 6
> - WITH_UDISKS=1 \
> -%endif
> -%if %{with hal}
> - WITH_HAL=1 \
> -%endif
> +WITH_UDISKS=1 \
> WITH_TRACKER=1 \
> WITH_ACL=1 \
> -%if 0%{?fedora} > 11 || 0%{?rhel} > 6
> - WITH_POLKIT=1 \
> -%endif
> +WITH_POLKIT=1 \
> PREFIX=%{_prefix} \
> BIN_DIR=%{_bindir} \
> LIB_DIR=%{_libdir} \
> @@ -106,7 +74,6 @@ make %{?_smp_mflags} \
>
>
> %install
> -rm -rf %{buildroot}
> make install install_i18n \
> DOCS_VERSION=1 \
> PREFIX=%{buildroot}%{_prefix} \
> @@ -119,30 +86,31 @@ make install install_i18n \
>
> %find_lang %{name}
>
> -desktop-file-install --vendor fedora\
> +desktop-file-install \
> --dir ${RPM_BUILD_ROOT}%{_datadir}/applications \
> ---delete-original \
> ${RPM_BUILD_ROOT}%{_datadir}/applications/%{name}.desktop
>
> -
> -%clean
> -rm -rf %{buildroot}
> -
> +rm -f ${RPM_BUILD_ROOT}%{_docdir}/%{name}-%{version}/INSTALL
>
> %files -f %{name}.lang
> -%defattr(-,root,root,-)
> %doc docs/ACTIONS docs/CONFIGURATION docs/CREDITS docs/HACKING
> %doc docs/NEWS docs/README docs/TODO docs/USAGE docs/WARNING
Re: Fedora 18 and new version of Gnome (3.7.x)
Am Dienstag, den 05.03.2013, 13:23 +0100 schrieb Dario Lesca: > Il giorno mar, 05/03/2013 alle 19.33 +0800, Liang Suilong ha scritto: > > Please upgrade to Fedora 19. > > Thank Liang, someone can tell to me what is the best way to upgrade my > Fedora 18 x86_64 to F19? If you don't know how to do this, you probably shouldn't do it. Both Fedora 19 and GNOME 3.7 are development releases. Better wait for the final release which will then be called GNOME 3.8. and be available with Fedora 19. Kind regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Receiving bugs from "Crash Catcher" with [faf] in the subject line
Am Montag, den 22.04.2013, 16:05 +0200 schrieb Richard Marko: > More feedback is welcome. 1. Announce changes like this one in advance on devel-announce. 2. Provide some documentation about FAF. What do these bugs mean to developers and package maintainers. "hat are we supposed to do? Kind regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning gtkglextmm
Hi, I'm going to orphan gtkglextmm. I took over maintainership because it was a requirement of beldi, which is officially dead for a while now. gtkglextmm itself FTBFS since Fedora 19 [1], but I think Debian has a fix for this [2]. There also is a request for aarch64 support [3]. The only packages in rawhide that depend on gtkglextmm are python-visual and repsnapper. I don't see where python-visual is being used, but repsnapper is part of the 3D printing feature for F19 [4] and therefor we need to keep it. If you are familiar with C++, gtkmm or even gtkglext, please be so kind as to take over maintainership or lend Miro and the other maintainers a helping hand. Thanks, Christoph [1] https://bugzilla.redhat.com/show_bug.cgi?id=914062 [2] http://patch-tracker.debian.org/package/gtkglextmm/1.2.0-6 [3] https://bugzilla.redhat.com/show_bug.cgi?id=925513 [4] http://fedoraproject.org/wiki/Features/3D_Printing -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Obsoleting ConsoleKit once and for all
Am Sonntag, den 28.07.2013, 04:03 -0700 schrieb Dan Mashal: > Hi, > > After discussion on #fedora-devel, my MATE co-maintainer raveit65, > Kalev, Misc, and previous conversations with Rex, I am ready to retire > ConsoleKit. Others are not. I am pretty sure ConsoleKit is still needed by LXDM and slim as they don't support systemd-logind and by pcmamfm and thunar for handling permissions of removable devices. > LightDM seems to fully support systemd-logind. > > > However I have no rights to commit to systemd. > > Lennart or any proven packager please add the following obsoletes tag > to systemd: > > obsoletes: ConsoleKit > obsoletes: ConsoleKit-x11 > obsoletes: ConsoleKit-libs I don't see why we need to obsolete it at this point. Sure, at some point it needs to die, but your approach doesn't seem well thought through. > I will take care of testing, retiring and blocking the package. Are you planning other desktops, too? And what about window-managers? Best regards, Christoph -- 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: Obsoleting ConsoleKit once and for all
Am Montag, den 29.07.2013, 16:37 +0200 schrieb Lennart Poettering: > On Sun, 28.07.13 13:24, Christoph Wickert (christoph.wick...@gmail.com) wrote: > > > and by pcmamfm and thunar for > > handling permissions of removable devices. > > I don't know what "pcmamfm" and "thunar" are, but why would they use > ConsoleKit for that? Can you elaborate? thunar and pcmanfm are file managers and require ConsoleKit for handling removable storage. Kind regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
ConsoleKit documentation needed
Hi there, is there any documentation on ConsoleKit available? ATM the package only includes a README which refers to http://www.freedesktop.org/software/ConsoleKit/doc/ConsoleKit.html which is mainly an API documentation. What I need is a user documentation about the binaries installed by ConsoleKit. None of the programs supports --help or has a manpage. What are they doing and how is ck-launch-session different from ck-xinit-session? The background of this question is that there are problems accessing removable media in LXDE and Xfce when logging in in runlevel 3 and then using startx. I know I can fix these problems by executing startlxde or startxfce4 through ck-launch-session, but honestly I have no idea what I'm doing. What is the recommended way to open and close a ConsoleKit session when logging in in runlevel 3? Should this be done in the scripts that strart the desktop environment? Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Tsclient
Am Samstag, den 04.09.2010, 13:27 +0100 schrieb Christopher Brown: > The new tsclient 2.0 GUI is terrible and these days there are far > superior alternatives in the form of gnome-rdp and remmina which I > happily use and provide a better end-user experience. BTW: gnome-rdp is no more, remmina is it's successor. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Tsclient
Am Dienstag, den 07.09.2010, 10:24 +1000 schrieb Chris Jones: > > Christoph, what on earth makes you think that gnome-rdp is obsolete and > has been replaced? I confused gnome-rdp with grdp, the ancestor of remmina. My bad, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
Am Dienstag, den 14.09.2010, 16:01 -0600 schrieb Kevin Fenzi: > Meeting summary > --- > * init process (nirik, 19:30:01) > * pjones and ajax are traveling today, will not be able to attend. > (nirik, 19:30:30) So am I, sorry i didn't make note earlier. I will be back next Tuesday and should be able to attend the meeting. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: update-mime-database errors: /usr/share/mime/packages/openoffice.org.xml:749: parser error - when updating Fedora 14 packages
Am Montag, den 04.10.2010, 11:58 +0100 schrieb Richard W.M. Jones: > The errors below happen several times during the yum update. > > Assuming that they must be generated by RPM %post scripts, I had a > look at the affected packages (control-center, evolution-data-server, > cheese, seahorse) and I suspect it's a problem with the > update-mime-database command. The affected file is /usr/share/mime/packages/openoffice.org.xml, so please file a bug against OpenOffice.org. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[License change] xfce4-cpugraph-plugin
xfce4-cpugraph-plugin has a new upstream now. He fixed some bugs, bumped the version from 0.4.1 to 1.0.0 and changed the license from BSD to GPLv2+. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
Am Donnerstag, den 04.11.2010, 02:15 -0400 schrieb Orcan Ogetbil: > The question is > Am I using the time efficiently? OR > Are the these tools actually preventing me to be efficient during my > available time? How would they? You can ignore all bug reports, you can even set up a mail filter to not see them. Costs no time, so it is very efficient. IMHO ABRT is just an offer. It depends on you what you make of it. I can only encourage maintainers to care about ABRT bugs and push everything upstream, even if it might be frustrating due to the lack of feedback from both the developers and the reporters. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
ABRT opt-out? (Re: bugzilla bugzappers?)
Am Donnerstag, den 04.11.2010, 12:18 +0100 schrieb Sven Lankes: > On Thu, Nov 04, 2010 at 02:15:30AM -0400, Orcan Ogetbil wrote: > > > The question is Am I using the time efficiently? OR Are the these > > tools actually preventing me to be efficient during my available time? > > Wasn't there some way for a maintainer to opt out of abrt? > > I remember seeing this being discussed but cannot find how to do it on > the abrt trac or in the man-pages. > > Was it just a plan? Is it not wanted? How would you do that? A popup in ABRT that reads "Sorry, but the maintainer of this package has decided to not accept any bug reports." I think this would be a *really* bad user experience. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
Am Donnerstag, den 04.11.2010, 13:28 +0100 schrieb Michael Schwendt: > On Wed, 3 Nov 2010 21:41:22 +0100, Bert wrote: > > > > So can someone please explain my why I should continue to try to > > improve Fedora by reporting bugs ? > > Glad you ask this. The bugzapping script is stupid. It asks the reporter > for NEEDINFO when in fact it ought to ask WTF has the packager not > responded since Fedora 12? + 100! Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: coming libnotify bump
Am Montag, den 01.11.2010, 21:12 -0400 schrieb Matthias Clasen: > I am planning to push libnotify 0.7.0 into rawhide by the end of this > week; Next time you are making an update that affects a large number of packages, please use devel-announce. TIA, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101110 changes
Am Mittwoch, den 10.11.2010, 10:34 + schrieb Rawhide Report: > Compose started at Wed Nov 10 08:15:17 UTC 2010 > > Broken deps for x86_64 > -- [...] > gwget-1.0.4-4.fc14.x86_64 requires libnotify.so.1()(64bit) Fixed in GIT but cannot be built because of > 1:epiphany-2.31.5-2.fc15.x86_64 requires libnotify.so.1()(64bit) I created a patch for the libnotify thing, but I epiphany FTBFS. > lxmusic-0.4.4-1.fc14.x86_64 requires libnotify.so.1()(64bit) Fixed in GIT but depends on > xmms2-0.7-6.fc15.i686 requires libecore-ver-svn-06.so.0 > xmms2-0.7-6.fc15.x86_64 requires libecore-ver-svn-06.so.0()(64bit) Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gnome-guitar in f14?
Am Sonntag, den 28.11.2010, 18:27 +0530 schrieb lakshminaras2...@gmail.com: > I would like to take up gnome-guitar package. > The last update happened in October 2009. According to the wiki, it > would be necessary to submit the package for re-review. Please > confirm whether my understanding is correct. This is correct. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Rework package groups (was: Summary & minutes for today's FESCo meeting...)
Am Montag, den 19.03.2012, 14:46 -0500 schrieb Jon Ciesla: > * #824 F18 Feature: Rework Package Groups -- > https://fedoraproject.org/wiki/Features/ReworkPackageGroups > (limburgher, 18:10:57) > * AGREED: F18 Rework Package Groups is passed (+6,-:0,0:2) > (limburgher, 18:12:42) Did FESCO really know what they were voting about? Can any of the FESCo members actually explain the feature? I'm afraid the feature page is so vague that nobody has a clue what we are talking about here. Does anybody - except Notting and David Lehman actually know what this feature is and how it impacts package maintainers or the spins SIG? Will groups still be consistent between yum and anaconda? Will a user who runs 'yum install @foo' get the same packages hat he had gotten wheh he selected the 'foo' group in anaconda? Please don't get me wrong: I am very much looking forward to this feature, but I am afraid nobody has an idea what is going on here. Kind regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Broken dependencies: parcellite
Am Mittwoch, den 21.03.2012, 12:52 + schrieb build...@fedoraproject.org: > > parcellite has broken dependencies in the rawhide tree: > On i386: > parcellite-1.0.2-0.1.rc5.fc17.i686 requires libpango-1.0.so.0()(64bit) > parcellite-1.0.2-0.1.rc5.fc17.i686 requires libgtk-x11-2.0.so.0()(64bit) > parcellite-1.0.2-0.1.rc5.fc17.i686 requires libgobject-2.0.so.0()(64bit) > parcellite-1.0.2-0.1.rc5.fc17.i686 requires libglib-2.0.so.0()(64bit) > parcellite-1.0.2-0.1.rc5.fc17.i686 requires libgdk-x11-2.0.so.0()(64bit) > parcellite-1.0.2-0.1.rc5.fc17.i686 requires > libc.so.6(GLIBC_2.3.4)(64bit) > parcellite-1.0.2-0.1.rc5.fc17.i686 requires libX11.so.6()(64bit) > Please resolve this as soon as possible. I resolved this on March 10th with 1.0.2-0.2.rc5 http://koji.fedoraproject.org/koji/buildinfo?buildID=306351 but still I keep getting these mails. Why? And why is the script complaining about the F17 package when there is a F18 one in rawhide? Kind regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Broken dependencies: parcellite
Am Mittwoch, den 21.03.2012, 18:30 +0100 schrieb Thomas Spura: > On Wed, Mar 21, 2012 at 6:02 PM, Christoph Wickert > wrote: > > Am Mittwoch, den 21.03.2012, 12:52 + schrieb > > build...@fedoraproject.org: > >> > >> parcellite has broken dependencies in the rawhide tree: > >> On i386: > >> parcellite-1.0.2-0.1.rc5.fc17.i686 requires > >> libpango-1.0.so.0()(64bit) > >> parcellite-1.0.2-0.1.rc5.fc17.i686 requires > >> libgtk-x11-2.0.so.0()(64bit) > >> parcellite-1.0.2-0.1.rc5.fc17.i686 requires > >> libgobject-2.0.so.0()(64bit) > >> parcellite-1.0.2-0.1.rc5.fc17.i686 requires libglib-2.0.so.0()(64bit) > >> parcellite-1.0.2-0.1.rc5.fc17.i686 requires > >> libgdk-x11-2.0.so.0()(64bit) > >> parcellite-1.0.2-0.1.rc5.fc17.i686 requires > >> libc.so.6(GLIBC_2.3.4)(64bit) > >> parcellite-1.0.2-0.1.rc5.fc17.i686 requires libX11.so.6()(64bit) > >> Please resolve this as soon as possible. > > > > I resolved this on March 10th with 1.0.2-0.2.rc5 > > http://koji.fedoraproject.org/koji/buildinfo?buildID=306351 > > but still I keep getting these mails. Why? And why is the script > > complaining about the F17 package when there is a F18 one in rawhide? > > Looks like the script looks for fc17, but says it's rawhide... Yeah, except that I get another mail for F17. > (There are still broken deps in fc17, because your update is not yet stable: > https://admin.fedoraproject.org/updates/FEDORA-2012-3933/parcellite-1.0.2-0.2.rc5.fc17 > ) I was aware of the F17 update not yet being pushed. The funny (?) thing is that the F17 mails stopped after the update was in testing, only rawhide continues and I have no idea why. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Broken dependencies: parcellite
Am Donnerstag, den 22.03.2012, 14:53 +0100 schrieb Michael Schwendt: > On Thu, 22 Mar 2012 13:41:37 +0100, CW (Christoph) wrote: > > > Am Mittwoch, den 21.03.2012, 18:30 +0100 schrieb Thomas Spura: > > > On Wed, Mar 21, 2012 at 6:02 PM, Christoph Wickert > > > wrote: > > > > Am Mittwoch, den 21.03.2012, 12:52 + schrieb buildsys: > > > >> > > > >> parcellite has broken dependencies in the rawhide tree: > > > >> On i386: > > > >> parcellite-1.0.2-0.1.rc5.fc17.i686 requires > > > >> libpango-1.0.so.0()(64bit) > > > >> parcellite-1.0.2-0.1.rc5.fc17.i686 requires > > > >> libgtk-x11-2.0.so.0()(64bit) > > > >> parcellite-1.0.2-0.1.rc5.fc17.i686 requires > > > >> libgobject-2.0.so.0()(64bit) > > > >> parcellite-1.0.2-0.1.rc5.fc17.i686 requires > > > >> libglib-2.0.so.0()(64bit) > > > >> parcellite-1.0.2-0.1.rc5.fc17.i686 requires > > > >> libgdk-x11-2.0.so.0()(64bit) > > > >> parcellite-1.0.2-0.1.rc5.fc17.i686 requires > > > >> libc.so.6(GLIBC_2.3.4)(64bit) > > > >> parcellite-1.0.2-0.1.rc5.fc17.i686 requires libX11.so.6()(64bit) > > > >> Please resolve this as soon as possible. > > > > > > > > I resolved this on March 10th with 1.0.2-0.2.rc5 > > > > http://koji.fedoraproject.org/koji/buildinfo?buildID=306351 > > > > but still I keep getting these mails. Why? And why is the script > > > > complaining about the F17 package when there is a F18 one in rawhide? > > > > > > Looks like the script looks for fc17, but says it's rawhide... > > > > Yeah, except that I get another mail for F17. > > > > > (There are still broken deps in fc17, because your update is not yet > > > stable: > > > https://admin.fedoraproject.org/updates/FEDORA-2012-3933/parcellite-1.0.2-0.2.rc5.fc17 > > > ) > > > > I was aware of the F17 update not yet being pushed. The funny (?) thing > > is that the F17 mails stopped after the update was in testing, only > > rawhide continues and I have no idea why. > > Are you sure about that? > > parcellite is still listed in the "F-17 Branched report" broken deps, > but not in the "rawhide report". > > The Branched report covers F17 + updates, but not updates-testing. Last mail I got for rawhide was Wed, 21 Mar 2012 12:52:55 + (UTC) Last mail for F17 is date Mon, 19 Mar 2012 11:00:01. Kind regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Size of official media handouts (was Re: Proposed F18 feature: MiniDebugInfo)
Am Mittwoch, den 09.05.2012, 11:57 -0400 schrieb Adam Jackson: > On Wed, 2012-05-09 at 11:45 -0400, Matthias Clasen wrote: > > On Wed, 2012-05-09 at 13:35 +0200, Kevin Kofler wrote: > > > Alexander Larsson wrote: > > > > The feature page lists some of the background and statistics. It also > > > > lists some options in how to implement this, which all have various > > > > different pros and cons. I'd like to hear what peoples opinions on these > > > > are. > > > > > > There is no room left on the KDE live image for installing any sort of > > > debugging information by default. > > > > We could easily drop some of less-than-half-complete translations to > > make room for a bit of minidebuginfo. Last time I looked, translations, > > fonts, etc made up upwards of 25% of the livecd. Or we could just drop > > the obsolescent cdrom size limitation... > > I know I've said this before, but: we should break the CD size barrier > precisely so people can't burn things to CDs. If you must burn to > optical media, do yourself a favor and burn a DVD, the reduced seek time > is entirely worth it. > > 1G fits on both the smallest MiniDVD format and most extant USB sticks. > Let's do it already. As an ambassador and former EMEA media wrangler I tend to agree. Currently both EMEA and NA only do dual layer DVDs, both for live and the installer. EMEA did separate installer vor i386 and x86_64, but after NA had no problems with exclusively providing dual layer, we decided to do the same. This being said I don't care how big we grow as long as we can still fit all 4 desktops (GNOME, KDE, Xfce, LXDE) in 2 arches each on one multi desktop live image. A dual layer DVD has a maximum capacity of 8.5 GB, so fitting 8 x 1 GB is not a problem. We might have to drop Sugar, but if only GNOME and KDE go for 1 GB and Xfce and LXDE still target 700 MB or less, we should even be able to keep it. This being said I am +1 for 1 GB, but please note that I only speak for myself or the NA and EMEA ambassadors. Kind regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Please use the announce list (was Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for F-18)
Something with "[ACTION REQUIRED] [FINAL NOTICE]" in the subject line should probably go to devel-announce list. Best regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Confusing tracker bug naming
Currently Blocker bugs are named "F": * FXXAlpha * FXXBeta * FXXBlocker To indicate whether something was accepted as a blocker or not the whiteboard is used: AcceptedBlocker or RejectedBlocker Nice-to-have bugs are named "F-accepted": * FXXAlpha-accepted * FXXBeta-accepted * FXX-accepted To indicate whether something was accepted as a nice-to-have or not again the whiteboard is used: AcceptedNTH or RejectedNTH. This is inconsistent and confusing: 1. Blocker bugs for alpha and beta don't have "blocker" in their name but the final has. 2. Naming the NTH bugs "-accepted" can be easily confused with the whiteboard status and sounds like an accepted blocker, but not like only nice-to-have. Therefor I propose: * FBlocker, that is FXXAlphaBlocker, FXXBetaBlocker, FXXBlocker. * FNTH, that is FXXAlphaNTH, FXXBetaNTH, FXXNTH * Whiteboard remains unchanged. Questions, feedback, thoughts or rants anybody? Kind regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Xfce tracker bug
Hi there, if you find any bugs in Xfce or the Xfce spin, please let them block the 'F18Xfce' tracker bug [1] so we can look into them ASAP. Kind regards, Christoph [1] https://bugzilla.redhat.com/show_bug.cgi?id=863722 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Xfce tracker bug
Am Sonntag, den 07.10.2012, 02:10 +0200 schrieb Christoph Wickert: > Hi there, > > if you find any bugs in Xfce or the Xfce spin, please let them block the > 'F18Xfce' tracker bug [1] so we can look into them ASAP. Sorry, I forgot to mention that this bug is *only* for Xfce on F18 or F19, maybe even to Xfce 4.10 on F17 (from Kevin's repo), but not for Xfce 4.8 or anything on F16. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Confusing tracker bug naming
Am Samstag, den 06.10.2012, 23:47 + schrieb Andre Robatino: > Here was my proposal: > > https://fedoraproject.org/wiki/Talk:BugZappers/HouseKeeping/Trackers For the list: Robin's proposal is * 15Alpha, 15Beta and 15Final (or alternatively 15) * 15AlphaNTH, 15BetaNTH and 15FinalNTH (or alternatively 15NTH) So we agree that having two different labels for one thing (NTH and accepted) is confusing and that 'accepted' is even worse because it can be confused with the whiteboard statuses. I think just a number (like 15) is not enough. The advantage I see for my proposal is that the it is consistent not only throughout the names of the tracker bugs but throughout both bug names and whiteboard statuses: Blocker in the whiteboard can only exist in a Blocker bug. But this is only a minor difference that I don't really care about as long as we get change the current 'accepted' names. :) Best regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Questions about the new comps
In order to reduce the size of the F18 Xfce spin, I wanted to edit comps - but decided to not do so until I fully understand what is going on. I seem to have missed a lot since since last our discussion at Blacksburg, so have a lot of questions. Here we go: 1. How can a package maintainer define a default, but not mandatory package? Example: The Xfce SIG decided to no longer install xfce4-icon-theme by default. It just takes space and we don't use it. Nevertheless we want to enable users to install it easily. How would we do that? Define an extra group with only xfce4-icon-theme and make it an option of the Xfce environment? 2. Even if I cannot do it in anacoda any longer, how would I do it in PackageKit? How can I make something show up in a group there without making it mandatory? 3. How do the new groups translate into PackageKit groups? Will all options be listed in the side pane of gpk-applications? Will they dynamically change? Will all packages of a group be selected? 4. How to define conditionals? 5. Is there more documentation than just https://fedoraproject.org/w/index.php?title=How_to_use_and_edit_comps.xml_for_package_groups&diff=298968&oldid=193124 Best regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Questions about the new comps
Hi there, one more question: How can one install something that is neither an 'environment' nor a minimal install install? Say I want openbox as window manager, how would I do that? openbox is in the group 'window-managers', but that group is not shown in anaconda. I guess we need to creae a group for each and every window manager and then make these groups options of either 'window-managers' or 'basic-x-windows' (the latter is shown in anaconda). Is this really the only way?! Best regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Last call for F19 naming proposals (deadline today 23:59 UTC!)
Hi everybody, this is the final reminder that the Fedora 19 naming collection ends today at 23:59 UTC. That means you have 5 hours left to propose a name at http://fedoraproject.org/wiki/Name_suggestions_for_Fedora_19 Before proposing a name, please read the guidelines at http://fedoraproject.org/wiki/Guidelines_for_release_names Kind regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Default grou membership for new users
Hi there, I am looking for a way how to add new users to a certain group upon creation. Do we have such a mechanism? /etc/default/useradd only is for useradd and can set a default group, but no additional default groups. Background: The 'Fedora Jam' spin [1] requires users to be in the groups 'audio' and 'jackuser'. This can be hacked for the liveuser in the livesys initscript, but what about other users, e.g. the one that gets created with firstboot. The spin owner had a dirty hack that modified /usr/share/firstboot/modules/create_user.py, but as the spins wrangler I told him this is a no-go. Kind regards, Christoph [1] https://fedoraproject.org/wiki/Fedora_jam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Installing bash-completion by default in F-16
Am Donnerstag, den 02.06.2011, 16:02 +0200 schrieb Reindl Harald: > Am 01.06.2011 22:54, schrieb Ville Skyttä: > > https://bugzilla.redhat.com/show_bug.cgi?id=709647 > > > > I'd like to have bash-completion included in F-16's default install. In > > my opinion it's in a good enough shape for that already now, and with my > > upstream hat on I expect things to further improve before F-16 is out. > > > > Why I'm writing here is that I'd like to hear opinions to which > > default-installed comps group should it be added (and set as default > > there) - in my opinion the serious candidates are admin-tools and base. > > admin-tools doesn't sound right because bash-completion is not really > > an admin tool (unless one considers interactive shell usage as admin > > activity in general), so I'm inclined to add it to base. > > > > Thoughts? > > PLEASE do not make a basic-install larger with [...] Default and basic install are two different things. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [OT] Xfce/LXDE wiki page seems outdated
Am Sonntag, den 05.06.2011, 23:39 -0100 schrieb Athmane Madjoudj: > Hello, > > Sorry for posting this here, I'm not subscribed to Xfce and LXDE lists. > > As of Fedora 15, Xfce/LXDE are included in DVD (I checked on x86_64 > DVD), but wiki pages [1] and [2] still mention about not being available > in DVD and the requirement of Internet connection. Thanks for the heads-up. It's a wiki and you have a Fedora account, so you can easily fix it yourself. ;) Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Provenpackager help for razertool removal
Am Sonntag, den 05.06.2011, 13:19 +0200 schrieb Nicola Soranzo: > razertool package is dead upstream razercfg [1] it the successor of razertool. If somebody packages it up, it would be nice to have the package properly obsolete razertool. Regards, Christoph [1] http://bues.ch/cms/hacking/razercfg.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Slim
Am Donnerstag, den 09.06.2011, 13:40 +0400 schrieb Lucas: > What kind of relation between Xfce maintainers and SLIM. The Fedora Xfce SIG considered SLIM but we didn't use it because (at least at that time) it had some problems with ConsoleKit. We are still trying to get rid of GDM but we are more after LightDM now. I have packaged it and it basically works on F >= 15, but the package and LightDM requires some more work. I don't think that Xfce upstream has a relationship to SLIM in particular because the project seems pretty much dead. > I always thought SLIM is just display manager, which can start > whatever I want. That is correct, but you either need to configure the default desktop or use the sylm-dynwm script. For more info have a look at https://fedoraproject.org/wiki/LXDE#SLiM Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OT: Fedora MulitiLiveCD, Current Status?
Am Sonntag, den 12.06.2011, 10:57 +0100 schrieb Frank Murphy: > What is the status of the MultiLiveCD, that was being mooted last > year. It is available for download at http://alt.fedoraproject.org/pub/alt/releases/15/Multi/ AFAIK the NA ambassadors have received their media already while EMEA is waiting for the shipment from the company. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OT: Fedora MulitiLiveCD, Current Status?
Am Sonntag, den 12.06.2011, 13:55 +0200 schrieb Jan Kratochvil: > I was trying to push it since 2009: > [Fedora-livecd-list] auto-biarch (x86_64 + i686) LiveDVD patch + ISO > > https://www.redhat.com/archives/fedora-livecd-list/2009-June/msg00018.html > http://fedoraproject.org/wiki/Biarch_Spin And we are very grateful for your work. > so when there exists now a releng-approved biarch spin why isn't the default > "Download" button on http://fedoraproject.org finally the biarch-autodetecting > spin? For various reasons: * It is still a new technology and only got a very limited amount of testing [1]. It was not tested during the release cycle at all but only last minute. Making it default would IMHO be to risky. * Your biarch spin is a spin of it's own and was never approved by the spins SIG. We said we would rather like to see a good tool coming out of this than a spin of it's own. If something should become default, it should be a biarch version of the desktop live CD. * Currently we don't have that, we only have a biarch installeation DVD and the multi desktop spin. A biarch desktop live media was not requested, produced or tested. If you want biarch as the default, please 1. make it a F16 feature 2. get in touch with the different SIGs to discuss the size limit and application selection. If we target a biarch desktop live, we need to at least have the desktop SIG involved. 3. make sure it is available for all milestones, this means alpha, beta and rc so it gets proper testing. 4. have a test day for it. I really like to see wider testing of the images with bare metal hardware and not only virtualization. > A biarch single-desktop download would be enough with under 2GB size. There were various attempts to change the limit of the default download, but there never was agreement. If we target 2 GB, we should change the application selection to come close to the limit but not only double 2 700 MB media. If we target 2 GB, people want to see e.g. LibreOffice on the media. IHMO biarch is nice for physical media but not for downloads: As an ambassador I don't need to worry about the arch and only take the biarch spin to an event. If I am to make media for production, say for a media in a computer magazine, it is a clear benefit because I can server all users. But as a user I usually know what I want and only want to download what I need. Ja, I really think you have done an awesome job and I appreciate your work helped me with the multi desktop spin. However I am not sure if it is already mature enough to become the default download or if this is a good thing. But if you decide to make a feature of it for F16 I promise to support you. Regards, Christoph [1] https://fedoraproject.org/wiki/Test_Results:Fedora_15_Final_Multi_Boot_DVD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SYSTEMD: Give us a option for upstart
Am Sonntag, den 12.06.2011, 23:23 +0200 schrieb Reindl Harald: > PLEASE give us a option for systems upgraded with yum > NOT USING "systemd" and force "upstart" as before systems upgraded with yum still have upstart installed (I did it myself) and you can select the init as a kernel parameter, so obviously nobody is forced. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SYSTEMD: Give us a option for upstart
Am Montag, den 13.06.2011, 01:47 +0200 schrieb Reindl Harald: > > Am 13.06.2011 00:54, schrieb Christoph Wickert: > > Am Sonntag, den 12.06.2011, 23:23 +0200 schrieb Reindl Harald: > >> PLEASE give us a option for systems upgraded with yum > >> NOT USING "systemd" and force "upstart" as before > > > > systems upgraded with yum still have upstart installed (I did it myself) > > and you can select the init as a kernel parameter, so obviously nobody > > is forced. > > my first test-setup had no upstart after upgrade You did read the instructions about upgrading with yum and ran 'yum distrosync', right? > this is a bad user experience and shows my that "systemd" had been better > delayed again for Fedora 16 to not repeat the bad things happended with > the way too early incldunfig of "pulseaudio" and "KDE4.0" AND we are > speaking here about the absolutely core-system and not a sound-daemon > or a desktop environment Please keep in mind that that one of Fedora's foundation is to be first. Please read https://fedoraproject.org/wiki/Foundations Both KDE 4 and pulseaudio were ready for inclusion when we first had them in our distribution. Software is always changing, development never stops. If you want to move on, you need to draw a line at some point and put it into production in order to get wider feedback. Without this feedback neither pulseaudio nor KDE would be where they are right now. Fedora is a distribution for early adopters. If you really need the latest kernel for your new hardware but also long term stability please get an enterprise distribution. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages that will be orphaned
Am Montag, den 20.06.2011, 10:34 -0700 schrieb Toshio Kuratomi: > Due to the requirement for contributors to sign the FPCA by Thursday of last > week, certain package owners who haven't yet signed will be removed from the > packager group soon. Have these packager been contacted directly in time, so all of them are basically MIA? > leafpad I'll take leafpad, it's the default editor in LXDE and I kind of maintained in the past (only with my proven packager powers, I never was co-maintainer). Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security updates for Firefox 4 in F-15
Am Sonntag, den 26.06.2011, 17:08 +0200 schrieb Kevin Kofler: > Felix Miata wrote: > > FF5 is the security update to FF4.0.1, which incorporates an upstream > > versioning policy change. > > The funny thing is that Firefox is going exactly the opposite way of us with > their update policies, They didn't change their update policy but their release/development model. FF 5 is an update to FF 4, but 3.6 got an update to 3.6.18, too. This means that Mozilla's update policy hasn't changed. > and that as a result, that Firefox security update is > not compliant with our update policies At what point exactly? Basically all that has changed is the version, IHMO FF 5 can better be described as FF 4.1. The user experience hasn't changed and the update meets all requirements of the update policy, so I really don't see a problem here. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security updates for Firefox 4 in F-15
Am Sonntag, den 26.06.2011, 13:25 -0300 schrieb Evandro Giovanini: > On Sun, Jun 26, 2011 at 1:01 PM, Christoph Wickert > wrote: > > Am Sonntag, den 26.06.2011, 17:08 +0200 schrieb Kevin Kofler: > >> Felix Miata wrote: > >> > FF5 is the security update to FF4.0.1, which incorporates an upstream > >> > versioning policy change. > >> > >> The funny thing is that Firefox is going exactly the opposite way of us > >> with > >> their update policies, > > > > They didn't change their update policy but their release/development > > model. FF 5 is an update to FF 4, but 3.6 got an update to 3.6.18, too. > > This means that Mozilla's update policy hasn't changed. > > > >> and that as a result, that Firefox security update is > >> not compliant with our update policies > > > > At what point exactly? Basically all that has changed is the version, > > IHMO FF 5 can better be described as FF 4.1. The user experience hasn't > > changed and the update meets all requirements of the update policy, so I > > really don't see a problem here. > > > > Firefox 5 is not stable because it introduces new features. New features don't have anything to do with stability. It's the AI/ABI and AFAIK nothing has changed in xulrunnner. All dependent packages required a simple rebuild. We had these rebuilds with every single FF update. > The most > visible example of this is users who had extensions stop working with > Firefox 5. This is most likely because the extensions expect a certain version string but not because of API/ABI changes. > Firefox's policy has changed. In the past they supported a stable > version for more than one day after the new release was out. What policy? The security policy? Firefox 3.6 is considered the previous stable version and it is still supported. > They're > not doing that anymore with Firefox 4, so users are forced to use the > new features (and bugs) of a new release. It's a great policy if > you're in a race to not lose mindshare from Chrome, it's not so great > for the people who have Firefox deployed in stable environments. Look, I never said I like the new version scheme. In fact I said that I dislike it. The major version shouldn't have been bumped because is a stable update, this means there are no API/ABI changes and no change in configuration formats either. There are merely no changes and there is a clean upgrade path, so I have no idea what problems in a stable environment you are expecting. And I have no idea what part of our update policy should be violated by this update. Please somebody enlighten me. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unresponsive Package Maintainer - Jeroen van Meeuwen
Am Freitag, den 17.06.2011, 14:37 +0200 schrieb Farkas Levente: > On 06/17/2011 02:01 PM, Vít Ondruch wrote: > > I'm following the procedure at: > > > > http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers > > > > Does anyone know how to contact Jeroen van Meeuwen? He is not answering > > e-mails at his listed address or the following Bugzilla reports: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=707934 > > https://bugzilla.redhat.com/show_bug.cgi?id=707937 > > > > There is also many other Jeroen's packages which would need some > > maintenance. > > there're dozen of reports about revisor too which is not working on any > current fedora and epel either. Correct me if I'm wrong, but there are workarounds described in the bug reports. The best way to move things forward is to submit patches. I'll ping Jeroen in the meantime, but we are both very busy with out dayjob. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pyxfce package
On Wed, 2011-07-06 at 21:16 +0200, Raphael Groner wrote: > FYI, since nobody seems to show any interest at Xfce upstream > > http://lists.fedoraproject.org/pipermail/xfce/2011-July/000630.html I don't think it should be in Fedora then. We should focus on well maintained software. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v2] Retiring packages in F-16
Am Dienstag, den 12.07.2011, 17:10 -0400 schrieb Bill Nottingham: > Orphan tango-icon-theme > Orphan tango-icon-theme-extras I have taken these. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: nonresponsive package maintainer (gget)
Am Samstag, den 09.07.2011, 08:29 + schrieb Andre Robatino: > Does anyone know how to contact the maintainer (Ant Bryan)? > > https://bugzilla.redhat.com/show_bug.cgi?id=711629 Did you try to contact Anthony directly or just through bugzilla? Anthony, please let us know if you are around or need help with any of ths bugs. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: nonresponsive package maintainer (gget)
Am Sonntag, den 17.07.2011, 12:38 + schrieb Andre Robatino: > Christoph Wickert googlemail.com> writes: > > > Am Samstag, den 09.07.2011, 08:29 + schrieb Andre Robatino: > > > Does anyone know how to contact the maintainer (Ant Bryan)? > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=711629 > > > > Did you try to contact Anthony directly or just through bugzilla? > > Just through Bugzilla. I don't know any other way to contact him except his > FAS > email address, which he used for Bugzilla. I am Anthony's sponsor and even I don't have another address either. Nevertheless I'd encourage everyone to write a *direct* mail instead of just bug reports. I know of many people who are filtering their mail and have hundreds of bug reports, so they could easily miss the one with the AWOL procedure. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
FUDCon EMEA travel subsidies are open
(I just sent the following mail to the ambassadors list and then figured out, that we may want to have developers at Milan, so I think it's a good idea to send this to this list, too) Hi there, if you are planing to attend FUDCon Milan 2011 and need travel subsidies, the ticket system is now open. If you need sponsoring, please 1. register at https://fedoraproject.org/wiki/FUDCon:Milan_2011#Pre-registration 2. put an X in the $$$ column 3. make a funding request in the the FUDCon ticket tracker at https://fedorahosted.org/fudcon-planning/wiki/FundingRequest 4. General instructions about sponsoring can be found at http://fedoraproject.org/wiki/Sponsoring_event_attendees Funding requests without a ticket will not be considered. We have a limited budget and will work hard to fund as many people as possible. We'll use these answers to help figure out budgeting for the event. We are making arrangements for attendees from other geographic regions to encourage specific initiatives such as future FUDCon events, but preference may otherwise be given to people in EMEA. The next subsidy meeting will be held on Tuesday, August 16th at 15:00 UTC in #fudcon-planning. Please show up in case the event organizers have questions about your request. Regards, Christoph ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Testing Xfce 4.8 pre 2 packages available
Hi there, I have packaged Xfce 4-8 pre 2 for Fedora 14 and Rawhide. You can find the packages at http://repos.fedorapeople.org/repos/cwickert/xfce-4.8/ The repo is far from complete. ATM it is still rsyncing and Fedora 13 is still building. Also a couple of applications that need a rebuild (e.g. xfce4-mixer) are missing and so are most of the goodies. I will continue to work on this. For more information on Xfce 4.8 in Fedora, please take a look at the feature page at https://fedoraproject.org/wiki/Features/Xfce48 Feedback welcome! Regards, Christoph P.S.: The old repo at http://cwickert.fedorapeople.org/repo is gone. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Testing Xfce 4.8 pre 2 packages available
Am Montag, den 06.12.2010, 14:42 +0200 schrieb Gilboa Davara: > On Mon, 2010-12-06 at 00:01 +0100, Christoph Wickert wrote: > > Hi there, > > > > I have packaged Xfce 4-8 pre 2 for Fedora 14 and Rawhide. You can find > > the packages at > > > > http://repos.fedorapeople.org/repos/cwickert/xfce-4.8/ > > > > > The repo is far from complete. ATM it is still rsyncing and Fedora 13 is > > still building. Also a couple of applications that need a rebuild (e.g. > > xfce4-mixer) are missing and so are most of the goodies. I will continue > > to work on this. > > Thanks! > > Should I report missing deps? Not necessary, I am aware of it, that's why it is not in rawhide yet. If somebody has the time to go through all the panel plugins and see if they still build, a list of the failed ones is appreciated. Thanks, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: firewalld - A firewall daemon with D-BUS interface providing a dynamic firewall (test version)
Am Montag, den 27.12.2010, 14:42 +0100 schrieb Thomas Woerner: > On 12/24/2010 11:45 PM, Colin Walters wrote: > > On Thu, Dec 23, 2010 at 11:03 AM, Thomas Woerner > > wrote: > >> > >> - A simple tray applet (firewall-applet) > > > > Actively deprecated; please consider other interfaces. In this case, > > I think a control panel module is just fine. > > Is there an interface to use control panel modules with other desktop > environments and also window managers? > > An applet for a component like a firewall should be usable with more > than one desktop environment. No matter what GNOME will do KDE, Xfce, LXDE, Fluxbox and many more will continue to use the system tray. It is sad to see that GNOME is abandoning a well established freedesktop.org standard. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: taking over maintenance of broken/abandoned packages
Am Freitag, den 07.01.2011, 23:56 -0700 schrieb Kurt Seifried: > What is the process for taking over packages that haven't been > maintained in a long time? https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass Rebuild and Mass branching status update
Am Donnerstag, den 10.02.2011, 15:01 -0600 schrieb Dennis Gilmore: > The first pass though the mass rebuild has been completed > > failures can be found at http://ausil.fedorapeople.org/failed.html and the > list of all things not built yet at > http://ausil.fedorapeople.org/rebuild.html This list doesn't seem correct: In my case it lists gtkhash, lilyterm and ristretto, but all of them have been fixed and built: http://koji.fedoraproject.org/koji/buildinfo?buildID=224779 http://koji.fedoraproject.org/koji/buildinfo?buildID=220183 http://koji.fedoraproject.org/koji/buildinfo?buildID=224953 On IRC you said it is ok to just push a build. Do I now need to submit them through bodhi? Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass Rebuild and Mass branching status update
Am Freitag, den 11.02.2011, 11:14 +0100 schrieb Michael Schwendt: > On Thu, 10 Feb 2011 15:01:28 -0600, Dennis wrote: > > > The first pass though the mass rebuild has been completed > > > > failures can be found at http://ausil.fedorapeople.org/failed.html and the > > list of all things not built yet at > > http://ausil.fedorapeople.org/rebuild.html > > there is ~400 packages that rpm-4.9.0 failed to parse the spec files. > > > > the couple ive looked at so far are due to unsupported macro use. > > Don't rebuild "mcs". It's a dead.package since three weeks: > https://fedorahosted.org/rel-eng/ticket/4352 Same for gnome-applet-remmina and xfce4-remmina-plugin, see https://fedorahosted.org/rel-eng/ticket/4357 This makes me wonder: Why are rel-eng tickets processed so slow recently? Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass Rebuild and Mass branching status update
Am Freitag, den 11.02.2011, 10:34 -0600 schrieb Dennis Gilmore: > On Friday, February 11, 2011 04:16:44 am Christoph Wickert wrote: > > Am Donnerstag, den 10.02.2011, 15:01 -0600 schrieb Dennis Gilmore: > > > The first pass though the mass rebuild has been completed > > > > > > failures can be found at http://ausil.fedorapeople.org/failed.html and > > > the list of all things not built yet at > > > http://ausil.fedorapeople.org/rebuild.html > > > > This list doesn't seem correct: In my case it lists gtkhash, lilyterm > > and ristretto, but all of them have been fixed and built: > > http://koji.fedoraproject.org/koji/buildinfo?buildID=224779 > > http://koji.fedoraproject.org/koji/buildinfo?buildID=220183 > > http://koji.fedoraproject.org/koji/buildinfo?buildID=224953 > > > > On IRC you said it is ok to just push a build. Do I now need to submit > > them through bodhi? > > yes you need to push them though bodhi. But I can't because they are already in dist-f15: $ koji latest-pkg dist-f15 gtkhash lilyterm ristretto Build Tag Built by - - gtkhash-0.3.0-3.fc15 dist-f15 cwickert lilyterm-0.9.9-0.2.rc8.fc15dist-f15 cwickert ristretto-0.0.91-2.fc15dist-f15 cwickert Nevertheless they are still listed at http://ausil.fedorapeople.org/rebuild.html Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PolicyKit authentication agent changes
Am Mittwoch, den 23.02.2011, 15:55 -0500 schrieb Matthias Clasen: > As of version 0.100 (which will land in F15 as a post-alpha update), the > polkit-gnome package will no longer install an autostart file for > polkit-gnome-authentication-agent-1. Instead, each desktop environment > is reponsible for making sure that an authentication agent is running. > > For GNOME, this is done by gnome-session installing an autostart file > with OnlyShowIn=GNOME;. Other desktop environments that rely on > polkit-gnome need to do something similar. Adding "OnlyShowIn" is certainly a step in the right direction but I'm afraid it will break many desktops out there, namely all window manager such as openbox, fluxbox, icewm etc. Adding a desktop file there doesn't make much sense as these WMs don't "rely" on an authentication agent. It's the applications that rely on it, but we don't have control over what software people install. I made a different proposal last year, please refer to http://lists.fedoraproject.org/pipermail/devel/2010-April/134578.html IMHO my approach has the advantage that it works for all DEs/WMs: Install a program that needs an authentication agent, it will pull in one of them through the virtual provides and the agent will be started on the next time you log in. We achieve this by making one agent the default. The default agent will have "NotShowIn=" to exclude the DEs that have an agent of their own while the others will have "OnlyShowIn=" to limit them to their desktop. I don't care which one is default is as long as it has only a small dependency footprint (kdebase-runtime for example has not). I only suggested lypolkit because it will be chosen by yum in most situations anyway. Can you explain what the advantage of your approach is? From a packaging point it looks broken: One the one hand we package a authentication agent that cannot run by itself, on the other we package an autostart file for something that is not necessarily installed. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PolicyKit authentication agent changes
Hi Matthias, thanks for your quick response. I was busy, that's why I'm not so quick. Am Mittwoch, den 23.02.2011, 20:08 -0500 schrieb Matthias Clasen: > On Thu, 2011-02-24 at 00:14 +0100, Christoph Wickert wrote: > > > Can you explain what the advantage of your approach is? From a packaging > > point it looks broken: One the one hand we package a authentication > > agent that cannot run by itself, on the other we package an autostart > > file for something that is not necessarily installed. > > Not sure what you mean with 'not installed'. > gnome-session requires polkit-gnome, so it better be installed. Thanks for the pointer, you didn't mention that in your mail. > Not sure what you mean by 'cannot run by itself' either. The > authentication agent in polkit-gnome is perfectly capable of running all > by itself. The package just doesn't inject itself in random desktop > environments anymore by installing an autostart file. It cannot run because it is not started. It is not about random desktops but about a defined list of desktops. We need all maintainers of a DE work together on this list, therefor I made my proposal one year ago. > I don't mind if you add a provides to your polkit agent implementation > that wms can depend on. There is nothing to add, the virtual provides "PolicyKit-authentication-agent" is already in place for all packages. > Thats between you and the window managers... but > as far as gnome is concerned, we don't want to depend on anything > virtual, but control which agent is running. I can understand this very well, but I never said the DE should depend on the virtual provides, the applications should. A DE should depend on the agent of the desktop, the apps should depend on a generic agent and use the virtual provides. Imagine you install gnome-packagekit in Xfce: It will pull in say polkit-gnome but still not work. Summing it all up: I still don't see the benefit of the new packaging. polkit-gnome-authentication-agent-1 doesn't start on any 'random' desktop. Indeed this is a step in the right direction and I appreciate it because I'm on the receiving side of bugs [1]. But wether or not polkit-gnome-authentication-agent-1 starts on any 'random' desktop has nothing to do with your new packaging but with the fact that you have switched from "NotShoIn" to "OnlyShowIn". The exactly same effect could be achieved without changing the packaging, so there is no benefit, but on the other hand it breaks many DEs / WMs that you might not care about. Regards, Christoph [1] https://bugzilla.redhat.com/show_bug.cgi?id=657006 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PolicyKit authentication agent changes
Am Samstag, den 26.02.2011, 11:58 +0100 schrieb Kevin Kofler: > Christoph Wickert wrote: > > > Am Mittwoch, den 23.02.2011, 20:08 -0500 schrieb Matthias Clasen: > >> Thats between you and the window managers... but > >> as far as gnome is concerned, we don't want to depend on anything > >> virtual, but control which agent is running. > > > > I can understand this very well, but I never said the DE should depend > > on the virtual provides, the applications should. A DE should depend on > > the agent of the desktop, the apps should depend on a generic agent and > > use the virtual provides. > > Well, having the apps depend on the virtual Provides is only of limited use > because what yum picks if you're lacking an agent is not necessary the > correct agent for your desktop. yum should pick the correct agent in most cases because it has a provider to only install as little packages as necessary. If you have GTK+ apps installed it wont install polkit-kde because of the whole QT / KDE dependencies. > The app cannot really know what agent is the > correct one, so there's no good way to put the dependency in the app. (We > can only have the app depend on "any PolicyKit authentication agent", which > is what the virtual Provides does, but this still doesn't ensure that the > correct one for your desktop is present.) > > Therefore, the dependency really needs to be carried by the desktop > environment, I fully agree to what you wrote and I never said something different. A desktop can depend on an agent - given that if it includes one. > at which point there's no point in having the apps Require > anything at all. Please try to look beyond the rim of your KDE teacup for a moment. What about the DEs / WMs that do not provide a polkit agent? Shouldn't we make things like virt-manager just work in *every* environment? > IMHO, PolicyKit authentication should just be considered a > basic desktop service which is present in ANY GUI desktop, it's up to the > desktop environment to Require the proper agent (and up to there, I > definitely agree with Matthias). In fact, kdebase-workspace already > Requires: polkit-kde. Again you are arguing from the POV of a full featured DE. Take Xfce for example: It is a very complete environment but still lacks a polkit agent. We could even go one step further and question your approach: I need to use some KDE applications and due to the monolithic packaging I also need to install kdebase-workspace. But I never start KDE, so why am I forced to install a second polkit agent then? I have to admit that I don't know the answer to this question and requiring polkit-kde looks like the best solution because my situation is a corner case. > Once we're there, Matthias is saying that we can just as well have the > desktop also START the authentication agent. I'm not entirely sure that this > is the best approach, but at that point, this isn't really THAT important. It is because it breaks other desktops. > You have to put in a Requires for the authentication agent anyway, s/the/an. 'The' agent can only be used if there is one. > so at that point you can just as well drop in an autostart file, too. Sure we can, but where is the advantage? If the package is required anyway we could just leave the file where it is and belongs - with the benefit that it can be used in other desktops, too. > (And in > fact, don't some of the desktops/WMs you have in mind require their own non- > XDG autostart setup anyway?) Yes, this is something we should try to cover too, but for a start I suggest to solve the situation for the XDG compliant ones. > > Imagine you install gnome-packagekit in Xfce: It will pull in say > > polkit-gnome but still not work. > > That's exactly why it's not the app's job to pull in an authentication > agent. Which basically means that you don't care about all DEs / WMs in Fedora being (more or less) broken because we cannot run many of our system-config-* tools there. > (Any application (as opposed to desktop environment / workspace) > package with an explicit Requires on a specific agent is broken and needs to > be fixed.) Yes, an application with an explicit requires for a *specific* agent is broken (and I'm filing bugs like #668156 in this case) but that doesn't mean that it should not depend on a *generic* agent. If the app cannot run without the agent, it needs this requirement. > > Summing it all up: I still don't see the benefit of the new packaging. > > polkit-gnome-authentication-agent-1 doesn't start on any 'random' > > desktop. Indeed this is a step in the right direction and I appreciate > >
gnome-disk-utility default in admin-tools
Am Montag, den 07.02.2011, 19:49 + schrieb Bill Nottingham: > commit f2cb3971ffb2a53b9f0fdc536cdcc4f9c3a87876 > Author: Bill Nottingham > Date: Fri Jan 28 16:24:54 2011 -0500 > > Move system-config-* tools from base-x to appropriate desktops. > > In Admin tools, make s-c-network optional, and swap gnome-disk-utility > for s-c-lvm. > > diff --git a/comps-f15.xml.in b/comps-f15.xml.in > index ff1fd16..f2c92a8 100644 > --- a/comps-f15.xml.in > +++ b/comps-f15.xml.in > @@ -9,14 +9,13 @@ > true > >authconfig-gtk > + gnome-disk-utility >gnome-packagekit >system-config-boot Next time you a change like this one, please announce it to the lists because it has a large impact on the spins. Even better: Ask *before* making this change. While we are at it: I'd like to suggest that non-desktop groups like 'admin-tools' should be desktop-agnostic. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gnome-disk-utility default in admin-tools
Am Montag, den 28.02.2011, 15:59 -0500 schrieb Bill Nottingham: > Christoph Wickert (christoph.wick...@googlemail.com) said: > > While we are at it: I'd like to suggest that non-desktop groups like > > 'admin-tools' should be desktop-agnostic. > > g-d-u is the maintained replacement for s-c-lvm. It doesn't do resizing, snapshots, or mirroring of LVM, so how can it replace s-c-lvm? > If you'd prefer to > use s-c-lvm, I'd suggest working with the upstream maintainer to make > it more useful. I think it is already useful, but first of all I prefer to not have any of them installed by default. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gnome-disk-utility default in admin-tools
Am Montag, den 28.02.2011, 15:56 -0500 schrieb Bill Nottingham: > Christoph Wickert (christoph.wick...@googlemail.com) said: > > Next time you a change like this one, please announce it to the lists > > because it has a large impact on the spins. Even better: Ask *before* > > making this change. > > I did. To the list and directly to your @fedoraproject.org inbox. Indeed, I got a mail, but you didn't mention admin-tools and claimed to "remove this cruft from the base-x group, and place it, where relevant, in the appropriate desktop groups." In fact what you did is quite the opposite, at least for gnome-disk-utility: You moved it into a common group and made it default. You should have mentioned that explicitly because it is not obvious from the patches as they don't give enough context. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Boards trac now open for ticket submissions
Hi, there is a new way to contact the board now: Recently the board's trac instance was opened for ticket submissions by all FAS account holders. In order to bring something to the board's attention, just file a ticket at https://fedorahosted.org/board/newticket You'll need to login with your FAS credentials. If you add the keyword "meeting", the ticket will automatically be added to the board's agenda and discussed in the next board meeting. For privacy reasons, you can only see your own tickets or tickets where you are in CC. Please forward this info to all relevant lists if you think I have missed one. Regards, Christoph P.S.: I wonder why the board didn't announce this. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gnome-disk-utility default in admin-tools
Am Dienstag, den 01.03.2011, 18:25 +0100 schrieb Kevin Kofler: > Christoph Wickert wrote: > > Next time you a change like this one, please announce it to the lists > > because it has a large impact on the spins. Even better: Ask *before* > > making this change. > > FYI, if your complaint is about Nautilus getting dragged in, this is being > addressed already, see https://bugzilla.redhat.com/show_bug.cgi?id=678909 > (on which I CCed you already). I know, but it's not only nautilus but also other GNOME deps. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning some GNOME packages
(CC'ing desktop list, perhaps somebody is interested in these packages) I am orphaning all my GNOME panel applets because I don't use GNOME any longer and I doubt that panel applets will have a future after GNOME 3.0 is released. * gnome-netstatus: Doesn't build with latest gnome-panel and has 3 open abrt bugs (#606827, #630167, #642911) * gnome-applet-cpufire: Doesn't build with latest gnome-panel, no open bugs, co-maintained by edwintb * gnome-applet-remmina: Replaced by a trayicon in F15 and rawhide, so maintenance is only needed for F13 and F14. No bugs ever. * gnome-applet-timer: Still maintained, still builds and works, co-maintained by tomspur. One abrt bug that was forwarded to the developer (#669519) Please pick them up in packagedb if you are interested. If there are no new owners within two weeks, I will retire the packages. Kind regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning some packages
Am Sonntag, den 13.03.2011, 16:41 +0100 schrieb Dominic Hopf: > Am Sonntag, den 13.03.2011, 11:04 -0400 schrieb Brian Pepple: > > * meld I have already applied for commit access. > > * tagtool Seems to be dead, at least the homepage disappeared. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning some packages
Am Montag, den 14.03.2011, 01:10 +0530 schrieb Ankur Sinha: > On Sun, 2011-03-13 at 20:15 +0100, Dominic Hopf wrote: > > Anyway, I still find it the best tool for editing MP3 tags around, so, > > is there any reason to not maintain it anymore from Fedora's point of > > view? > > Nope. None that I can see. It really is an amazing tool and should be > available in the repos until something better comes up as a replacement > IMO. easytag? Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning some packages
Am Sonntag, den 13.03.2011, 23:13 +0100 schrieb Matej Cepl: > Dne 13.3.2011 20:39, Christoph Wickert napsal(a): > > easytag? > > Unfortunately, it is not a separate package. $ rpm -qi easytag Name: easytag Relocations: (not relocatable) Version : 2.1.6 Vendor: Fedora Project Release : 5.fc14Build Date: Fr 20 Aug 2010 16:32:22 CEST Install Date: Fr 26 Nov 2010 00:43:29 CET Build Host: x86-19.phx2.fedoraproject.org Group : Applications/Multimedia Source RPM: easytag-2.1.6-5.fc14.src.rpm Size: 2841577 License: GPLv2+ and LGPLv2+ Signature : RSA/SHA256, Fr 20 Aug 2010 19:32:49 CEST, Key ID 421caddb97a1071f Packager: Fedora Project URL : http://easytag.sourceforge.net/ Summary : Tag editor for mp3, ogg, flac and other music files Description : EasyTAG is a utility for viewing, editing and writing the tags of MP3, MP2, FLAC, Ogg Vorbis, MusePack and Monkey's Audio files. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 for f14?
Am Mittwoch, den 23.03.2011, 22:46 +0100 schrieb Jochen Schmitt: > Perhaps, we have luck and get a so-called 'Feature Repository'. I'm working on that... > If you want to get firefox4 on Fedora 14 now, the only way is to use > the private firefox4 repository on > > http://repos.fedorapeople.org/repos/spot/firefox4 > > For KDE-4.6 we have the same situation. Not quite, KDE 4.6 will hit F14 soon: https://fedorahosted.org/fesco/ticket/571 Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 for f14?
Am Donnerstag, den 24.03.2011, 14:48 -0700 schrieb Henrique Junior: > It may sound a little off-topic to this thread, but since we are > talking about bring new stuff into F14 I would like to know the > opinion of you, guys, about the new openSUSE's tumbleweed [1] [2] > repo, that tries to bring to openSUSE some "rolling release" > behaviour. We do have a rolling release, it's called rawhide. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaned packages by leigh123linux
Am Freitag, den 01.04.2011, 16:14 +0530 schrieb Rahul Sundaram: > The following have been orphaned by leigh123linux. Sending on his > behalf since his is not subscribed to this list > > libdesktop-agnostic, avant-window-navigator, awn-applets-extras, > gmixer, torium and html2text gmixer should die I think. It has a lot of bugs and upstream is unresponsive. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swap request: dexter and postler
Am Mittwoch, den 06.04.2011, 02:11 +0200 schrieb Michel Alexandre Salim: > These are part of the Elementary OS project, and were recently > featured in OMG Ubuntu: > Dexter -- > http://www.omgubuntu.co.uk/2010/12/meet-dexter-elementarys-new-address-book-app/ > https://bugzilla.redhat.com/show_bug.cgi?id=693921 Already reviewed at https://bugzilla.redhat.com/show_bug.cgi?id=690953 > Postler -- > http://www.omgubuntu.co.uk/2011/03/postler-update-adds-docky-badge-port-options-and-more/ > https://bugzilla.redhat.com/show_bug.cgi?id=693931 Already reviewed at https://bugzilla.redhat.com/show_bug.cgi?id=690954 If you like, apply for co-maintainership. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: critpath approval process seems rather broken
Am Samstag, den 09.04.2011, 05:32 +0200 schrieb Kevin Kofler: > Will Woods wrote: > > The solution is simple: ASK FOR HELP. > > The solution is simple: The red tape on update pushing needs to be repealed. As someone who is still suffering from the KDE 4.6.1 update and who has not received notable support from your or the KDE SIG I object to lowering the test requirements for updates. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: critpath approval process seems rather broken
Am Sonntag, den 10.04.2011, 23:12 +0200 schrieb Kevin Kofler: > Christoph Wickert wrote: > > As someone who is still suffering from the KDE 4.6.1 update and who has > > not received notable support from your or the KDE SIG I object to > > lowering the test requirements for updates. > > Uh, we're doing what we can about the Akonadi issues. The thing is, we > cannot reproduce them, But I can and I haven't seen any instructions what I should do. I am willing to try broken update again in order to provide more info, but I can only provide the info I am asked for. > nor could the users who tested 4.6 before we pushed > it. (We've had even prereleases available in the kde-unstable repository, > then 4.6.0 and 4.6.1 in kde-testing. Several users tested those. kde- > unstable also had kdepim 4.6, but several people excluded it specifically. > kde-testing shipped 4.6.0 with kdepim 4.4.10, exactly the combination we > pushed to F14. This is the problem: It was one huge update, so when a person gives +1, you have no idea what he actually tested. We don't know if the people tested kontact at all, they just approved the huge update and might not even have kdepim installed. > The update was also in updates-testing for 11 days total and > had a karma of +2, with 2 -1 comments about regressions which were both > fixed in the version we pushed to stable, and 4 +1 comments. One of the +1 > votes was from a proventester, so this update would have fulfilled even the > stricter requirements for critical path packages.) It's hard to fix an issue > we cannot reproduce. This means we need more testing rather than less, so your suggestion to remove "red tape" is counterproductive. > We tried a fix from upstream to solve Akonadi-related problems, which wasn't > developed for your exact issue, but which we thought might have helped too. > It turns out it didn't help. (It does fix an annoyance other users were > encountering though.) > > We cannot do all that much more on our end. Have you talked to kdepim > upstream? As far as I know, you actually know the kdepim developers better > than we do… The upstream developers are the people most likely to be able to > do anything about your problem. It's hard to fix an issue in code we didn't > develop. I don't expect you to know the code but as the maintainers I expect you to be able to give me some debugging instructions that you would then use to get in touch with the developers. I haven't met them again because I only see them once a week and when I do, I will try to get some help there. As a matter of fact you pushed a very hairy update to a stable release and it broke for some people, so you are not in the position to demand less testing. > And aren't you the one who wanted us to ship F15 with kdepim 4.6 beta? (Yes, > it's still in beta, even now, and I doubt it will be out of beta when F15 > releases. F15 will ship with kdepim 4.4.x.) No, I wanted to ship the final, not the beta because I relied on my colleagues. > Yet when I suggested trying that to see whether it works any better, you > dismissed > my suggestion as an insane one. Trying what? Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: A new comps group for fedora medical
Am Mittwoch, den 04.05.2011, 00:11 +0530 schrieb Ankur Sinha: > Hello, > > Just a heads up to the list. I'm going to be adding a fedora-medical[1] > group to comps in the coming few days. Please follow the instructions from http://fedoraproject.org/wiki/Comps.xml#New_groups and submit a patch to this list so we can have a look at it. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
ABRT frustrating for users and developers
I know that APRT is still very young technology, but after 2 months it's time for a interim conclusion. For me the conclusions are: Pro: * abrt is a help for developers: I received one positive feedback from a developer: The backtrace looks "interesting" but cannot be fixed without a major rewrite of the app. * abrt helps to fix bugs sometimes: So far abrt helped me to fix three crashes in two apps (in Fedora and upstream). Con: * Unfortunately 3 out of ~ 40 reports is not a good percentage. * As already pointed out by Michael Schwendt some time ago, there were some good traces in the beginning but then they became unusable. Starting with abrt 1.0.2 it got better again but I still get bogus reports sometimes. * As a maintainer abrt causes a lot of work. You have to respond to the tickets, ask for details, explain how to install debuginfo manually and tell people that their * abrt is frustrating for maintainers: Upstream refuses to accept the backtraces generated by abrt. Happened to me three times. * abrt is frustrating for users: Today I received my first "No need for a reply...I will stop submitting tickets." Can somebody confirm my observations? Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ABRT frustrating for users and developers
Am Samstag, den 16.01.2010, 22:25 +0100 schrieb Ola Thoresen: > Have a look at this bug for instance: > > https://bugzilla.redhat.com/show_activity.cgi?id=531343 > It was closed two months ago as "WORKSFORME", still ABRT adds more and > more users to the Cc-list. > > Obviously something is not working for someone, but ABRT seems to ignore > the fact that the bug is closed when adding Cc-s. I already bugzilla'd this a while ago: https://bugzilla.redhat.com/show_bug.cgi?id=538783 Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ABRT frustrating for users and developers
Am Sonntag, den 17.01.2010, 12:36 +0100 schrieb Nicolas Mailhot: > IMHO the big plus of abrt is it triggers even when the user is not > giving his full attention to the app and not checking what it does > exactly when it crashes (typical example is multitasking and doing stuff > in 3-4 apps when one dies). There is a huge class of crashes that were > not reported before because the user had no idea what the app was doing > exactly when it crashed and could not reproduce it with debuginfo later. I doubt this very much. Many people don't report the bugs when the app crashes but later, many reports in a row. Most of my reports read "I have no idea what I was doing when foo crashed", even if they submitted it straight after the crash. Only 2 out of ~40 contained the information I needed to reproduce the crash reliably (as a site note: both are fixed, so the number of crashes fixed it 4 but not 3 as I wrote in my initial mail. 4/40 is still a bad percentage) Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ABRT frustrating for users and developers
Am Sonntag, den 17.01.2010, 15:53 +0100 schrieb Jiri Moskovcak: > On 01/16/2010 04:01 PM, Christoph Wickert wrote: > > I know that APRT is still very young technology, but after 2 months it's > > time for a interim conclusion. For me the conclusions are: > > > > Pro: > > > >* abrt is a help for developers: I received one positive feedback > > from a developer: The backtrace looks "interesting" but cannot > > be fixed without a major rewrite of the app. > > > >* abrt helps to fix bugs sometimes: So far abrt helped me to fix > > three crashes in two apps (in Fedora and upstream). > > > > Con: > > > >* Unfortunately 3 out of ~ 40 reports is not a good percentage. > > > > I'm open to any ideas how to improve this. Sorry, I have no idea, except: 1. Don't accept incomplete backtraces. 2. Make a comment and the description how to reproduce the bug mandatory. 3. Add a timestamp to the backtrace because many people submit their bugs later and they don't recall when it happened. This is important for me, I need to know it it happened before or after a certain update. 4. Add n-v-r of the affected packages, so it is obvious if people submit old bugs. 5. Instead of hashes the missing debuginfo packages should be listed with n-v-r, so people can install them manually. > >* As already pointed out by Michael Schwendt some time ago, there > > were some good traces in the beginning but then they became > > unusable. Starting with abrt 1.0.2 it got better again but I > > still get bogus reports sometimes. > > > >* As a maintainer abrt causes a lot of work. You have to respond > > to the tickets, ask for details, explain how to install > > debuginfo manually and tell people that their > > > > How this differ from any other bugs? ABRT just helps users to report > bugs so we get reports even from users who wouldn't bother otherwise. The difference is that most of these users don't bother to write a simple comment, to install debuginfo or respond to the bugs they filed with ABRT at all. Another huge difference is the workload for me. > >* abrt is frustrating for maintainers: Upstream refuses to accept > > the backtraces generated by abrt. Happened to me three times. > > > > If the backtrace is complete then there is no reason why upstream > shouldn't accept it, but if there is a problem with installing debuginfo > then there is nothing ABRT can do (except to prevent user to send a > report, but what's the threshold here?). Does ABRT prefent them from sending these reports? I don't think so because I'm still getting bogus reports with ABRT 1.0.3. > >* abrt is frustrating for users: Today I received my first "No > > need for a reply...I will stop submitting tickets." > > > > They can always remove it and go back to previous reporting mechanism > using bugzilla web form. Most of them wouldn't do that, but people who submit something with ABRT are disappointed that their bugs are getting closed. If you don't do something, you cannot be disappointed. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libxklavier bump
Am Samstag, den 16.01.2010, 22:11 -0500 schrieb Matthias Clasen: > I am going to build libxklavier 5.0 in rawhide, which bumps the soname, > and also contains a small api change. The following packages will have > to be rebuilt: > > gnome-settings-daemon > gdm > control-center > kdebase-workspace > libgnomekbd > gnome-applets > xfce4-xkb-plugin > gnome-screensaver > python-xklavier > xfce4-settings > cairo-dock-plug-ins Would you mind using fedora-devel-announce or contacting the maintainers of these packages directly next time? TIA, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mumble's package owner is non-responsive, I wish to take over the package
Am Freitag, den 22.01.2010, 14:52 +0100 schrieb Andreas Osowski: > Hello, > I do herewith request to take over the package "mumble", currently owned by > igjurisk. > The maintainer seems to be unresponsive and all previous attempts of contact > have failed. > > According to the policy for non-responsive package maintainers, this request > has to be approved > by at least one FESco member. > > Cheers, > Andreas > > Bug 552351 - Non-responsive package maintainer of Mumble > https://bugzilla.redhat.com/show_bug.cgi?id=552351 Your bug was opened on January 1st, so the 3 weeks required by the policy for non-responsive maintainers[1] have not yet passed. Regards, Christoph [1] https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mumble's package owner is non-responsive, I wish to take over the package
Am Freitag, den 22.01.2010, 17:28 +0100 schrieb Christoph Wickert: > Am Freitag, den 22.01.2010, 14:52 +0100 schrieb Andreas Osowski: > > Hello, > > I do herewith request to take over the package "mumble", currently owned by > > igjurisk. > > The maintainer seems to be unresponsive and all previous attempts of > > contact have failed. > > > > According to the policy for non-responsive package maintainers, this > > request has to be approved > > by at least one FESco member. > > > > Cheers, > > Andreas > > > > Bug 552351 - Non-responsive package maintainer of Mumble > > https://bugzilla.redhat.com/show_bug.cgi?id=552351 > > Your bug was opened on January 1st, Sorry, should be January 4th. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
AWOL Maintainer: John T. Guthrie III
Seems like Fred Guthrie is AWOL. He did not respond to bugs since 2009-07-20: https://bugzilla.redhat.com/show_bug.cgi?id=512660 I started the AWOL procedure already back in October, but it slipped of my radar: https://bugzilla.redhat.com/show_bug.cgi?id=514882 John owns 18 packages in total: https://admin.fedoraproject.org/pkgdb/users/packages/guthrie If anybody knows what's up with John or how to contact him, please let us know. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: AWOL Maintainer: John T. Guthrie III
Am Samstag, den 30.01.2010, 18:25 +0100 schrieb Christoph Wickert: > Seems like Fred Guthrie is AWOL. Of course this should read "John". Sorry Fred! Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Sindre Pedersen Bjørdal is AWOL, 25 packages looking for new owners
Sindre Pedersen Bjørdal was declared to be MIA in a fast track nonresponsive maintainer procedure [1, 2]. This means that we had to orphan all his packages, 25 in total: * DMitry -- Deepmagic Information Gathering Tool * arp-scan -- Scanning and fingerprinting tool * avant-window-navigator -- Fully customisable dock-like window navigator for GNOME * bottlerocket -- Utilities to use the FireCracker X10 kit * clearlooks-compact-gnome-theme -- GNOME Desktop theme optimized for small displays * cowbell -- Music organazier * firewalk -- Active reconnaissance network security tool * flac123 -- Command-line program for playing FLAC audio files * gdevilspie -- A user friendly interface to the devilspie window matching daemon * gnome-do -- Quick launch and search * gtk-recordmydesktop -- GUI Desktop session recorder with audio and video * gtranslator -- Gettext po file editor for GNOME * halberd -- Tool to discover HTTP load balancers * httptunnel -- Tunnels a data stream in HTTP requests * ike-scan -- IKE protocol tool to discover, fingerprint and test IPsec VPN servers * muine -- Music Player for GNOME * muine-scrobbler -- Audioscrobbler plugin for Muine * nbtscan -- Tool to gather NetBIOS info from Windows networks * nikto -- Web server scanner * notify-sharp -- A C# implementation for Desktop Notifications * nrg2iso -- Convert Nero Burning Rom image files into ISO * onesixtyone -- An efficient SNMP scanner * perl-Class-Gomor -- Another class and object builder * perl-DBIx-SQLite-Simple -- Easy access to SQLite databases using objects * perl-Math-Base85 -- Perl extension for base 85 numbers, as referenced by RFC 1924 * perl-Net-IPv4Addr -- Perl extension for manipulating IPv4 addresses * perl-Net-IPv6Addr -- Perl module to check validity of IPv6 addresses * perl-Net-Libdnet -- Perl interface to libdnet * perl-Net-Packet -- A framework to easily send and receive frames from layer 2 to layer 7 * perl-Net-Packet-Target -- An object for all network related stuff * perl-Net-Pcap -- Interface to pcap(3) LBL packet capture library * perl-Net-Write -- A portable interface to open and send raw data to network * perl-Nmap-Parser -- Parse nmap scan data with perl * perl-SQLite-Simple -- Easy Access to SQLite databases using objects * perl-libwhisker2 -- Perl module geared specificly for HTTP testing * pisg -- IRC Statistics generator * pychess -- Chess game for GNOME * python-imdb -- Retrieve and manage the data of the IMDb movie database * python-virtkey -- Python extension for emulating keypresses and getting current keyboard layout * qt-recordmydesktop -- KDE Desktop session recorder with audio and video * recordmydesktop -- Desktop session recorder with audio and video * rubyripper -- Open-source secure ripper for Linux * scratchpad -- Spatial text editor for the GNOME desktop * serpentine -- Audio CD Burner * solfege -- Music education software * tcptraceroute -- A traceroute implementation using TCP packets * telepathy-mission-control -- Central control for Telepathy connection manager * txt2man -- Convert flat ASCII text to man page format * vttest -- Test the compatibility of so-called "VT100-compatible" terminals * xdotool -- Fake keyboard/mouse input If you are interested in maintaining one of these packages, please pick them up in packagedb at https://admin.fedoraproject.org/pkgdb/users/packages/sindrepb?acls=owner Regards, Christoph [1] https://fedorahosted.org/fesco/ticket/325 [2] http://meetbot.fedoraproject.org/fedora-meeting/2010-02-02/fesco.2010-02-02-20.01.log.html#l-150 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mumble's package owner is non-responsive, I wish to take over the package
Am Freitag, den 22.01.2010, 14:52 +0100 schrieb Andreas Osowski: > Hello, > I do herewith request to take over the package "mumble", currently owned by > igjurisk. > The maintainer seems to be unresponsive and all previous attempts of contact > have failed. > > According to the policy for non-responsive package maintainers, this request > has to be approved > by at least one FESco member. Enough time has passed now. Igor is now officially considered missing in action. As a FESCO member I hereby approve Andreas' request to take over maintainership of mumble. The package needs to be reviewed again, please open a new review request for this. > Cheers, > Andreas Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Sindre Pedersen Bjørdal is AWOL, 25 packages looking for new owners
Am Dienstag, den 02.02.2010, 23:45 + schrieb Peter Robinson: > On Tue, Feb 2, 2010 at 11:15 PM, Christoph Wickert > > If you are interested in maintaining one of these packages, > please pick > them up in packagedb at > > https://admin.fedoraproject.org/pkgdb/users/packages/sindrepb?acls=owner > > > > Looks like they are still to be orphaned? Done. > Peter Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Sindre Pedersen Bjørdal is AWOL, 25 packages looking for new owners
Am Mittwoch, den 03.02.2010, 00:47 +0100 schrieb Michael Schwendt: > On Wed, 03 Feb 2010 00:15:41 +0100, Christoph wrote: > > > Sindre Pedersen Bjørdal was declared to be MIA in a fast track > > nonresponsive maintainer procedure [1, 2]. This means that we had to > > orphan all his packages, 25 in total: > > Pkg db says: 50 packages Huh? the list I posted was from packagedb and both seth and me counted 25 packages: http://fpaste.org/NpTL/ Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Sindre Pedersen Bjørdal is AWOL, 25 packages looking for new owners
Am Dienstag, den 02.02.2010, 18:59 -0500 schrieb Toshio Kuratomi: > On Tue, Feb 02, 2010 at 11:45:30PM +, Peter Robinson wrote: > > On Tue, Feb 2, 2010 at 11:15 PM, Christoph Wickert < > > christoph.wick...@googlemail.com> wrote: > > > > Sindre Pedersen Bj rdal was declared to be MIA in a fast track > > nonresponsive maintainer procedure [1, 2]. This means that we had to > > orphan all his packages, 25 in total: > > > Actually the list is 50 (but you did list them all) Now, my list was complete, I just counted incorrect. ;) Thanks for taking care! Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Sindre Pedersen Bjørdal is AWOL, 25 packages looking for new owners
Am Dienstag, den 02.02.2010, 19:16 -0500 schrieb Seth Vidal: > > On Wed, 3 Feb 2010, Christoph Wickert wrote: > > > Huh? the list I posted was from packagedb and both seth and me counted > > 25 packages: http://fpaste.org/NpTL/ > > no, that list is from the potentially-unmaintained pkg list. Sorry for the > confusion, my bad. If Sindre owned 50 packages and 25 were on your list, then your potentially-unmaintained metric is better than I thought at the beginning! > -sv Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
