Re: Mass closing EOL bugs should not close bugs with pending updates
Il giorno dom, 17/02/2013 alle 17.32 -0500, Orcan Ogetbil ha scritto: On Sun, Feb 17, 2013 at 4:53 PM, Christoph Wickert christoph.wick...@gmail.com wrote: 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ž: 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. Hmm, I always interpreted that the RELEASE in CURRENTRELEASE or NEXTRELEASE refers to the Release tag of the corresponding package, and not to the Fedora release version. The bug header looks like this Product: Fedora Component:lxpanel Version(s): 16 Platform: x86_64 In my interpretation, I would _not_ close this bug if I fix it only - for another product than Fedora , e.g. for RHEL. RHEL might suffer from the same bug as well, but this complaint was for Fedora. We cannot ignore Fedora. - for another component. It does not make sense to fix a kernel bug and close this bug report, does it? - for another platform. If the bug is filed for i686 and my fix only fixes x86_64, my fix is not related to this bug report. (Of course the fix might fix both i686 and x86_64, in which case the bug can be closed.) - for another Fedora version. I believe the bug is Fedora version specific (else why do we have a Version tag?). If a bug is filed for version 16, it is for version 16. Other versions might also have the same bug, but this is irrelevant from the bug report's perspective. Your interpretation treats everything the same but the Version part differently. Any particular reason? http://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#CLOSED Best, Nicola -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why is not enabled TapButton of touchpad on Fedora by default?
Il giorno ven, 14/12/2012 alle 09.28 +1000, Peter Hutterer ha scritto: On Tue, Dec 11, 2012 at 11:26:14PM +, Sérgio Basto wrote: On Sex, 2012-09-21 at 01:14 +1000, Peter Hutterer wrote: On Fri, Sep 21, 2012 at 12:48:34AM +1000, Peter Hutterer wrote: On Wed, Sep 12, 2012 at 04:44:48PM +1000, Ankur Sinha wrote: On Tue, 2012-09-11 at 23:16 -0700, Adam Williamson wrote: So instead of /usr/share/X11/xorg.conf.d/50-synaptics.conf you should create /etc/X11/xorg.conf.d/50-synaptics.conf . Other than that, I think the advice is good. Hi, Thanks Adam, Onuralp, Alvaro. I've created a page here[1]. Please review it and correct it if required. [1] https://fedoraproject.org/wiki/How_to_enable_touchpad_click For xorg.conf.d snippets, use this section instead: Section InputClass Identifier Enable touchpad tapping MatchDriver synaptics Option TapButton 1 EndSection I forgot, this is also described here: https://fedoraproject.org/wiki/Input_device_configuration#Example:_Tap-to-click Seeing cat /etc/X11/xorg.conf.d/00-system-setup-keyboard.conf # This file is autogenerated by system-setup-keyboard. Any # modifications will be lost. this file is deprecated and should've been removed in the F17 cycle by systemd-localed. if it's still there, you can remove it. /etc/X11/xorg.conf.d/00-system-setup-keyboard.conf is still present in F17, in fact: $ rpm -qf /etc/X11/xorg.conf.d/00-system-setup-keyboard.conf system-setup-keyboard-0.8.8-2.fc17.x86_64 $ rpm -qf /usr/lib/systemd/system/systemd-localed.service systemd-44-21.fc17.x86_64 Nicola -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: I want upgrade my computer
Il giorno ven, 30/11/2012 alle 06.16 +, Sérgio Basto ha scritto: On Qui, 2012-11-29 at 12:28 -0700, Tim Flink wrote: Sounds like a plan, hopefully it won't be too difficult to figure out. I was just out of space in Hard Disk, correctly writes package foo needs 100M etc But should end with a nice message saying you need free space of your disk before upgrade Hi Sérgio, filing a bug report for this problem may be a good idea! Thanks, Nicola -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: akonadi-googledata retire
Il giorno dom, 11/11/2012 alle 11.04 +0100, Mario Santagiuliana ha scritto: I follow the step to retire akonadi-googledata package. The upstream project is no longer maintain and in kdepim-runtime there is already a new akonadi resource for google services. On fedora git web interface I don't see my the last commit with dead.package file... http://pkgs.fedoraproject.org/cgit/akonadi-googledata.git/ Is it correct? Maybe I do something wrong? Ciao Mario, did you follow the steps of https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life in the right order? If you completed step 5) before step 2) and 3), then you need the help of a provenpackager to fix that. Nicola -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why is not enabled TapButton of touchpad on Fedora by default?
Il giorno mar, 18/09/2012 alle 08.35 -0400, john.flor...@dart.biz ha scritto: From: Adam Williamson awill...@redhat.com Oh, I should also note that, IIRC, the intent is that the driver should detect if there are no physical buttons and enable tap-to-click in this case. So touchpads which have no buttons and are only supposed to work with tap-to-click should be OK. Where does my notebook's touchpad fall in this continuum? At the bottom corners of the touch-sensitive area are two buttons which click with tactile feedback, but yet are still part of the touch-sensitive surface. In other words, the bottom corners can actually be deformed/depressed. FWIW, I enabled tap-to-click -- did I just answer my own question? -- simply because my wife and I both found the mouse to be moving off target too often when tried using these buttons. It's called a ClickPad, it's supported in X.org released with F17. Nicola -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What happend with SystemConfigCleanup?
Il giorno mar, 18/09/2012 alle 20.11 +0100, Álvaro Castillo ha scritto: What happend with SCC? https://fedoraproject.org/wiki/Features/SystemConfigCleanup Current status Targeted release: Fedora 18 Last updated: 2009-05-19 Percentage of completion: 25% Is not updated from 2009, have worked only 25% but will be included on F18? How is possible? You missed Category: FeaturePageIncomplete at the end of the page, i.e. it is a feature being investigated by the Fedora community that have not been Proposed or Accepted for a particular Fedora release. More info at https://fedoraproject.org/wiki/Features/Policy Nicola -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: redhat-lsb-desktop versus transition to current libpng
Il giorno mer, 01/08/2012 alle 09.51 -0400, Adam Jackson ha scritto: Fedora is not LSB compatible. Is it? Why do we even care about this at all? It is if you install redhat-lsb. The only intrinsic reason to care about LSB support is binary compatibility; Fedora broadly doesn't, but that doesn't mean it's not a useful end. Personally I've definitely had occasion to need older builds of things like boost and openssl on newer Fedora releases. repoquery is also telling me there are things in Fedora that _do_ require redhat-lsb, at least in F16. I can't speak to the particulars there, you'd need to look into that per-package. In rawhide, the packages requiring redhat-lsb are: bcfg2-server rear tomcat6 HTH, Nicola -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning buoh, libsoup22
Il giorno ven, 02/03/2012 alle 14.41 +0200, Jonathan Dieter ha scritto: I've orphaned buoh and libsoup22 in all active branches of Fedora. Buoh is a GTK online comics reader that I haven't used in forever and libsoup22 is a compat version of libsoup required for buoh. I don't think any packages other than buoh require libsoup22, but I could be wrong. libsoup22 is also required by libsyncml . Nicola -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Close duplicated review request package
Il giorno mar, 10/01/2012 alle 12.20 +0100, Mario Santagiuliana ha scritto: Hi to all! I am learning how to help in review process of new package. I navigate on new package review tickets and I see this Review request: https://bugzilla.redhat.com/show_bug.cgi?id=639323 The telepathy-qt4 is already included in fedora repository. Can I close this bug? How can I do it? Ciao Mario! You should close it as duplicate of the succeeded Review, which is in this case was bug 723123. To do this, you need some Bugzilla powers, i.e. you should be in the Fedora Bugs Group in https://admin.fedoraproject.org/accounts/ , if I remember well. In the meantime, I already did the closing. Nicola -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F16 release to Rawhide upgrade failure
Il giorno ven, 16/12/2011 alle 16.42 +0100, Michael Schwendt ha scritto: A fresh install of Fedora 16 x86_64 DVD, then enabled fedora-release-rawhide and disabled updates and updates-testing. It wants to pull in i686 packages, and the full output with --skip-broken is this: http://mschwendt.fedorapeople.org/tmp/yum-f16-to-rawhide.log https://bugzilla.redhat.com/show_bug.cgi?id=761270 Nicola -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unresponsive Package Maintainer - Štěpán Kasal
Alle mercoledì 14 settembre 2011, Kevin Fenzi ha scritto: On Wed, 14 Sep 2011 08:58:11 +0200 Stepan Kasal ka...@ucw.cz wrote: Hello all, Therefore I'd like to ask FESCo to mass-orphan all packages owned by him. Should I open a ticket? yes, it is true that I'm not able to find any time to do my duties as a package maintainer. I agree that mass orphaning of the packages is a reasonable solution. I would be grateful if you could help me with that. Could one of you file a ticket for this? I guess in infrastructure trac and we will get it taken care of. Thanks Štěpán and Kevin, I created the Fedora Infrastructure ticket: https://fedorahosted.org/fedora-infrastructure/ticket/2950 Nicola -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unresponsive Package Maintainer - Štěpán Kasal
Alle martedì 6 settembre 2011, Nicola Soranzo ha scritto: I'm following the procedure at: http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers Does anyone know how to contact Štěpán Kasal (user kasal)? He is not answering e-mails at his listed address (I've written directly to ka...@ucw.cz on 2011/07/27 regarding bug 700405) or the following Bugzilla reports: https://bugzilla.redhat.com/show_bug.cgi?id=700405 (pinged twice) https://bugzilla.redhat.com/show_bug.cgi?id=716023 https://bugzilla.redhat.com/show_bug.cgi?id=705103 (low security impact) https://bugzilla.redhat.com/show_bug.cgi?id=661005 https://bugzilla.redhat.com/show_bug.cgi?id=528219 https://bugzilla.redhat.com/show_bug.cgi?id=495750 And probably many others... Please note that Štěpán owns 40 packages https://admin.fedoraproject.org/pkgdb/users/packages/kasal?acls=owner I'm not a packager and I'm not interested in taking them over, but if some of them are not maintained, then they should be orphaned. Another week has passed without any response or action from Štěpán. I'd like to add that the last koji build from him was on 2010-07-05: http://koji.fedoraproject.org/koji/userinfo?userID=394 Also, according to Patrice Dumas, it seems that Štěpán is not willing to continue maintaining his packages. Therefore I'd like to ask FESCo to mass-orphan all packages owned by him. Should I open a ticket? I'm particularly interested in package halevt, which is the last package depending on deprecated hal, and should be retired as well for Fedora 16/rawhide: https://bugzilla.redhat.com/show_bug.cgi?id=700405 I'm not a packager, so I cannot become owner and retire it. Opening a Review Request doesn't seem very useful... Patrice, you are co-maintainer of halevt, can you help me? Thanks, Nicola -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to remotely download a package from koji?
Alle martedì 12 luglio 2011, Richard Shaw ha scritto: On Tue, Jul 12, 2011 at 8:34 AM, Jan Kratochvil jan.kratoch...@redhat.com wrote: On Tue, 12 Jul 2011 15:22:53 +0200, Richard Shaw wrote: I'm trying to remotely download a package from a koji scratch build but it doesn't work. # curl -L -O http://koji.fedoraproject.org/koji/getfile?taskID=3192896name=BackupPC -3.2.1-1.fc14.src.rpm Scratch download links should be direct https://fedorahosted.org/koji/ticket/80 That would be nice... since even with the quotes I had to rename the file after downloading (or use -o to do it on the front end). What about the -J option? WFM curl -O -J 'http://koji.fedoraproject.org/koji/getfile?taskID=3192896name=BackupPC-3.2.1-1.fc14.src.rpm' Nicola -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Provenpackager help for razertool removal
razertool package is dead upstream and has been deprecated by its maintainer Andreas Osowski (th0br0). Unfortunately he didn't complete all the steps to correctly remove a package: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life I reported the problem at https://bugzilla.redhat.com/show_bug.cgi?id=700756 but there was no progress. So, I asked to block razertool from future composes (step 6 of the mentioned procedure): https://fedorahosted.org/rel-eng/ticket/4766 Only steps 2 and 3 remain, for which I am asking the help of a provenpackager: 2) Run fedpkg retire. This will add a dead.package file to git. Do it for all affected foo branches (usually master only, but also the branched release if it has not yet released). The contents of this file should briefly explain where this package went: 'Obsolete package.', 'Renamed to bar' or the like. 3) git rm all the other files in the foo branches that you added dead.package to. This should help make it clearly obvious what's going on here. It's not necessary to remove the files in other branches, unless there are other factors at work. (e.g., licensing issue, package being removed completely from Fedora.) Thanks in advance! Nicola -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Request for removal of package from Fedora repositories: dasher.x86_64
Alle giovedì 2 giugno 2011, Michael Wiktowy ha scritto: On Thu, Jun 2, 2011 at 3:00 PM, nodata l...@nodata.co.uk wrote: Hello, dasher in Fedora has been broken for me since Fedora 12. The bug I entered has recently been automatically closed. dasher doesn't work in 64-bit and can be crashed by asking it to go fullscreen. What's the procedure to get the package removed? Thanks. Ref: https://bugzilla.redhat.com/show_bug.cgi?id=538336 Dasher works fine on a 64 bit system on F15 here. My version = dasher-4.10.1-2.fc12.x86_64 It looks like it hasn't been touched in some time though. There is a newer version out (4.11) available here: http://www.inference.phy.cam.ac.uk/dasher/Download.html Which I have in fact reported 4 months ago, without any response: https://bugzilla.redhat.com/show_bug.cgi?id=675740 Nicola -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning and retiring HAL
Alle giovedì 17 marzo 2011, Richard Hughes ha scritto: On 16 March 2011 17:16, Michel Alexandre Salim sali...@fedoraproject.org wrote: I wonder why gimp depends on hal directly. For scanner, perhaps? It was for tablet support, but the code could never have worked. We've dropped the hal and gnome-vfs2 deps from gimp in rawhide now. Unfortunately it looks like that the koji build failed: http://koji.fedoraproject.org/koji/buildinfo?buildID=233923 Best, Nicola -- Nicola Soranzo, Ph.D. My PGP key: http://nsoranzo.altervista.org/key.asc signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning and retiring HAL
Richard Hughes wrote: I'm planning to orphan the hal and hal-info packages in F15 and and retire them in rawhide. HAL has been dead upstream for 3 years now, and all development has moved into udev, and the u* daemons like upower, udisks and urfkill. The original maintainer and most of the original team want HAL dead. The things that depend on HAL in F15 seem to be: beldi-0:0.9.25-3.fc15.x86_64 blueman-0:1.21-7.fc15.x86_64 exaile-0:0.3.2.1-1.fc15.noarch gnome-device-manager-libs-0:0.2-6.fc15.i686 libconcord-0:0.23-2.fc15.i686 lxsession-0:0.4.5-2.fc15.x86_64 matahari-0:0.4.0-0.1.8003b6c.git.fc15.1.x86_64 nut-0:2.6.0-3.fc15.x86_64 ovirt-server-installer-0:0.100-6.fc15.noarch razertool-0:0.0.7-8.fc15.x86_64 xfce4-cddrive-plugin-0:0.0.1-4.fc15.x86_64 See also the Feature page: https://fedoraproject.org/wiki/Features/HalRemoval I have been updating the dependency list there for almost a year. Nicola -- Nicola Soranzo, Ph.D. My PGP key: http://nsoranzo.altervista.org/key.asc -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning and retiring HAL
Alle mercoledì 16 marzo 2011, Matthias Clasen ha scritto: On Wed, 2011-03-16 at 15:50 +0100, Nicola Soranzo wrote: See also the Feature page: https://fedoraproject.org/wiki/Features/HalRemoval I have been updating the dependency list there for almost a year. Wow, you've done a nice job there, thanks for keeping that uptodate. Thanks! I think for F16, we should probably open a feature page for the goal of getting gnome-vfs2 off the live cd. Since gnome-vfs2 requires hal-libs, this is the same goal! Otherwise, as mentioned in the Feature page, we can disable HAL support in gnome-vfs2, like Debian is doing. In this case, gnome-vfs2 should fall back to /etc/mtab, but probably the functionalities of some programs may be affected (e.g. in Inkscape the Import from Open Clip Art Library). Nicola -- Nicola Soranzo, Ph.D. My PGP key: http://nsoranzo.altervista.org/key.asc signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
