Re: Join to Mozilla Location Service in Fedora
On 11/06/2014 03:18 PM, Bastien Nocera wrote: Geoclue2*is* ready. Ehmm. When I google GeoClue2 only relevant link is: https://developer.gnome.org/platform-overview/stable/tech-geoclue2.html.en No documentation. No mobile app for gathering data. No public API. I would not call this "ready". -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Join to Mozilla Location Service in Fedora
On November 7, 2014 12:00:12 AM PST, "Miroslav Suchý" wrote: >On 11/06/2014 03:18 PM, Bastien Nocera wrote: >> Geoclue2*is* ready. > >Ehmm. When I google GeoClue2 only relevant link is: >https://developer.gnome.org/platform-overview/stable/tech-geoclue2.html.en > >No documentation. No mobile app for gathering data. No public API. I >would not call this "ready". You may find this link to the project website has some of the things you are looking for: http://www.freedesktop.org/wiki/Software/GeoClue/ Zach Ploskey -- 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: PROPOSAL: Make AppData files mandatory for applications shown in the software center
On 7 November 2014 02:15, Zbigniew Jędrzejewski-Szmek wrote: > We would. My point is that we should we should make a list of > applications which are not allowed to fall by the wayside I think that list would be very different for each person you ask; the easiest thing to do is to just create the AppData file for the few applications you are passionate about keeping and build a new package for rawhide. I don't think making a list is going to be a productive use of time, and would possibly take more time writing emails than just writing the few AppData files we need. I also think there's a distinction between "I think this package is good" and "I care enough about this package to actually fix it". Normally I'd argue "patches welcome" is a harmful thing to say, but given how easy it is to write an AppData file and how many provenpackagers there are in this case I think it's justified. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: downgrade version of gthumb in fedora 21 final?
Hi, On Fri, Nov 7, 2014 at 1:31 AM, Michael Catanzaro wrote: > On Thu, 2014-11-06 at 13:13 -0800, James Patterson wrote: >> >> Is it too late to downgrade gthumb in Fedora 21 to 3.2.x? >> >> The version in Fedora is really slow. I posted a bug with more info: >> https://bugzilla.redhat.com/show_bug.cgi?id=1161052 > > I agree that should be downgraded in F21 and possibly in rawhide as > well. Since gthumb does not follow the GNOME release schedule, we > shouldn't push unstable versions of gthumb to rawhide. I suspect it's > being picked up by mclazy I fully agree. I'll double-check, that the problem is caused by the unstable version of gthumb (and not some other updated library in F21). I guess it was updated in the hope that the next stable version will be released before F21. If appropriate, I'll downgrade gthumb. Best regards, Christian -- 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: downgrade version of gthumb in fedora 21 final?
On 7 November 2014 00:31, Michael Catanzaro wrote: > Since gthumb does not follow the GNOME release schedule, we > shouldn't push unstable versions of gthumb to rawhide. No? We push unstable GNOME to rawhide all the time; or is this more of a case where we're worrying that a stable gthumb won't be available before F22 is due? Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Virtual network interface
Hi everybody, Is there way how to setup some virtual network inteface, which would always work, no matter if I use ethernet, wireles, VPN or whatever else network connection on background? * It is pretty annoying that every time I change my location, I have to change configuration of my virtual machines, just because now I am not connected via ethernet, but via WiFi. * I don't understand why my Xchat should loose connection, when I am switching from ethernet to WiFi (and they are both available during interim period). The type of network connection is just implementation detail, so why this does not work? If there is possible to create some virtual network interface, which would take all the real network connection under one umbrella, this should be default for Fedora Workstation. Additional feature could be that WiFi goes down when Ethernet is available etc. This functionality has been available in Lenovo's Access Connection tools at least 8 years ago as far as I remember and I greatly missing it. Vít -- 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: LLVM 3.5 rebase
On Fri, Nov 7, 2014 at 2:51 AM, Jens Petersen wrote: >> That's only going to work if llvm34 renames all of its binaries, and ghc >> is changed to invoke the renamed ones, right? Otherwise the 3.4 and 3.5 >> versions of /usr/bin/llc will conflict. > > Hmm yes I guess I should go the whole way... > > My initial lazy plan was just that ghc-compiler.armv7hl > should require and BR llvm34 instead of llvm (and make llvm34 > Conflicts with llvm and llvm34-devel conflicts with llvm-devel...). > > Not sure how many people really need both (on arm), > but I suppose it is better to avoid conflict where possible. Well mesa depends on llvm so that sounds like not really practical. -- 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: Virtual network interface
On Fri, Nov 07, 2014 at 10:56:19AM +0100, Vít Ondruch wrote: > Hi everybody, > > Is there way how to setup some virtual network inteface, which would > always work, no matter if I use ethernet, wireles, VPN or whatever else > network connection on background? > > * It is pretty annoying that every time I change my location, I have to > change configuration of my virtual machines, just because now I am not > connected via ethernet, but via WiFi. > * I don't understand why my Xchat should loose connection, when I am > switching from ethernet to WiFi (and they are both available during > interim period). > > The type of network connection is just implementation detail, so why > this does not work? If there is possible to create some virtual network > interface, which would take all the real network connection under one > umbrella, this should be default for Fedora Workstation. I think bridged networking should just be the default. In this day and age, multiple processes inside the OS should be able to acquire an IP address from the ethernet interface (whether wired or wireless). http://wiki.libvirt.org/page/Networking#Bridged_networking_.28aka_.22shared_physical_device.22.29 Note not just VMs: There's a lot of theoretical work around having ordinary processes have their own IPv6 address. > Additional feature could be that WiFi goes down when Ethernet is > available etc. This functionality has been available in Lenovo's Access > Connection tools at least 8 years ago as far as I remember and I greatly > missing it. Agreed. This is particularly annoying when I use my laptop docking station (which has wired gigE) but basically am forced to stick with slow wifi because otherwise everything breaks. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide report: 20141107 changes
Compose started at Fri Nov 7 05:15:04 UTC 2014 Broken deps for i386 -- [3Depict] 3Depict-0.0.16-3.fc22.i686 requires libmgl.so.7.2.0 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [audtty] audtty-0.1.12-9.fc20.i686 requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.i686 requires libjson.so.0 [cab] cab-0.1.9-12.fc22.i686 requires cabal-dev [condor] condor-plumage-8.1.4-7.a1a7df5.fc22.i686 requires libmongoclient.so [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [django-recaptcha] django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14 [dnssec-check] dnssec-check-1.14.0.1-4.fc20.i686 requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.i686 requires libsres.so.14 [dragonegg] dragonegg-3.4-0.3.rc0.fc21.i686 requires libLLVM-3.4.so dragonegg-3.4-0.3.rc0.fc21.i686 requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc22.i686 requires libedelib.so edelib-devel-2.1-5.fc22.i686 requires libedelib.so [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc22.i686 requires libtorrent-rasterbar.so.7 [flush] flush-0.9.12-10.fc22.i686 requires libtorrent-rasterbar.so.7 [gdesklet-SlideShow] gdesklet-SlideShow-0.9-16.fc21.noarch requires gdesklets [gdesklets-citation] gdesklets-citation-2.0-3.20120702git355e2ee.fc19.noarch requires gdesklets [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.i686 requires libvala-0.24.so.0 [ghc-hjsmin] ghc-hjsmin-0.1.4.7-3.fc22.i686 requires libHSoptparse-applicative-0.9.0-ghc7.6.3.so [glances] glances-2.1.2-2.fc22.noarch requires python-psutil >= 0:2.0.0 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0 [iwhd] iwhd-1.6-11.fc22.i686 requires libmongoclient.so [juffed] juffed-plugin-terminal-0.10-10.fc22.i686 requires libqtermwidget.so.0 [kmid2] kmid2-2.4.0-7.fc22.i686 requires libdrumstick-file.so.0 kmid2-2.4.0-7.fc22.i686 requires libdrumstick-alsa.so.0 [leiningen] leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks leiningen-1.7.1-7.fc20.noarch requires classworlds [libghemical] libghemical-2.99.1-24.fc20.i686 requires libf77blas.so.3 libghemical-2.99.1-24.fc20.i686 requires libatlas.so.3 [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.i686 requires libopenobex.so.1 [ltsp] ltsp-client-5.4.5-8.fc21.i686 requires fuse-unionfs ltsp-server-5.4.5-8.fc21.i686 requires cdialog [meshmagick] meshmagick-0.6.0-20.svn2898.fc21.i686 requires libOgreMain.so.1.8.1 meshmagick-libs-0.6.0-20.svn2898.fc21.i686 requires libOgreMain.so.1.8.1 [monodevelop-vala] monodevelop-vala-2.8.8.1-6.fc21.i686 requires vala < 0:0.25.0 [netdisco] netdisco-1.1-7.fc21.noarch requires perl(SNMP::Info::Layer2::Bay) [nwchem] nwchem-openmpi-6.3.2-11.fc21.i686 requires libmpi_usempi.so.1 [odb] odb-2.3.0-6.fc22.i686 requires gcc = 0:4.9.1 [openshift-origin-msg-node-mcollective] openshift-origin-msg-node-mcollective-1.18.0.1-2.fc21.noarch requires openshift-origin-msg-common [openslides] openslides-1.3.1-3.fc21.noarch requires python-django < 0:1.5 [openvas-client] openvas-client-3.0.3-8.fc20.i686 requires libopenvas_omp.so.6 openvas-client-3.0.3-8.fc20.i686 requires libopenvas_nasl.so.6 openvas-client-3.0.3-8.fc20.i686 requires libopenvas_misc.so.6 openvas-client-3.0.3-8.fc20.i686 requires libopenvas_hg.so.6 openvas-client-3.0.3-8.fc20.i686 requires libopenvas_base.so.6 [perl-RT-Authen-ExternalAuth] perl-RT-Authen-ExternalAuth-0.11-5.fc21.noarch requires rt3 perl-RT-Authen-ExternalAuth-0.11-5.fc21.noarch requires perl(:MODULE_COMPAT_5.18.2) [perl-RT-Extension-CommandByMail] perl-RT-Extension-CommandByMail-0.07-10.fc21.noarch requires perl(RT::Interface::Email) perl-RT-Extension-CommandByMail-0.07-10.fc21.noarch requires perl(:MODULE_COMPAT_5.18.2) [pipelight-selinux] pipelight-selinux-0.2.1-2.fc22.noarch requires pipelight-common pipelight-selinux-0.2.1-2.fc22.noarch requires pipelight-common pipelight-selinux-0.2.1-2.fc22.noarch requires pipelight pipelight-selinux-0.2.1-2.fc22.noarch requires pipelight [pootle] pootle-2.1.6-8.fc21.noarch requires python-django14 [python-askbot-fedmsg] python-askbot-fedmsg-0.1.0-2.fc21.noarch requires askbot [python-coffin] python-coffin-0.3.7-3.fc21.noarch requires python-django14 [python-django-addons] python-django-addons-0.6.6-2.fc21.noarch requires python-django14 [python-django-longerusername] python-django-longerusername-0.4-5.20130204gite4
Re: PROPOSAL: Make AppData files mandatory for applications shown in the software center
2014-11-06 12:03 GMT+02:00 Richard Hughes : > I've attached a list of all the applications that would be affected by > this change. It's a long list, but a *lot* of the applications are > kinda dubious (lshw-gui anyone?). > I read your blog posts on AppStream/AppData and I found some Workstation/AppDataImprovement pages on the wiki, but I could not find the list you provided in your original message. I want to take on some of the scientific packages, but I don't know if someone has already filed requests with upstream or if they are working on any of them. Is there such a page somewhere? Please go easy on me, new guy learning the ropes here. -- 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: PROPOSAL: Make AppData files mandatory for applications shown in the software center
On Thu, Nov 6, 2014 at 4:05 PM, Richard Hughes wrote: > On 6 November 2014 14:49, Josh Boyer wrote: >> Why wouldn't we (Fedora) add an AppData file to the package ourselves >> for such exceptions? > > We can, and should. I'd argue it's one of the most useful thing a > Fedora packager can do: > > * Spend the 5 minutes writing the AppData file > * Spend 5 minutes taking some up to date 16:9 screenshots > * Validate the file with "appstream-util validate" > * Send these upstream > * Patch the Fedora package to include the AppData file while waiting > for an upstream tarball. Can't we include that in the package guidelines? -- 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: PROPOSAL: Make AppData files mandatory for applications shown in the software center
- Original Message - > On Thu, Nov 6, 2014 at 4:05 PM, Richard Hughes wrote: > > On 6 November 2014 14:49, Josh Boyer wrote: > >> Why wouldn't we (Fedora) add an AppData file to the package ourselves > >> for such exceptions? > > > > We can, and should. I'd argue it's one of the most useful thing a > > Fedora packager can do: > > > > * Spend the 5 minutes writing the AppData file > > * Spend 5 minutes taking some up to date 16:9 screenshots > > * Validate the file with "appstream-util validate" > > * Send these upstream > > * Patch the Fedora package to include the AppData file while waiting > > for an upstream tarball. > > Can't we include that in the package guidelines? This is a very good idea, if we want to enforce it, packaging guidelines are good place to start with for new applications. Jaroslav > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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: PROPOSAL: Make AppData files mandatory for applications shown in the software center
- Original Message - > Hi all, > > It will come as no surprise to many of you, but I'm going to propose > that we only show applications in the software center in F22 when they > have an AppData file. At the moment nearly 50% of applications in > Fedora 21 ship AppData files, and the ones left over are not exactly > the award winning ones, if you know what I mean. We want the software > center to be a showcase of all the awesome applications available on > Fedora, not just a wrapper around a package installer. > > I've attached a list of all the applications that would be affected by > this change. It's a long list, but a *lot* of the applications are > kinda dubious (lshw-gui anyone?). > > Important points: > * Applications without appdata would still be installable on the > command line using dnf. > * Applications without appdata would still show up in the "Installed" > tab in the software center and be visible in the shell like normal > when installed. > > If you see an application on the list that really shouldn't be there > as you know it ships an AppData file (e.g. subsurface ships one > upstream, but the package doesn't install it) then please let me know > and we can fix things up. Remember, this is just a proposal. I've > burnt holes in my flame-proof suit already. Comments welcome. Could you please write F22 Change proposal - I can see it could be a bit controversial as removing half of applications could be considered like quite a lot. On the other hand it would allow us to track where we are and in the end, if it would be reasonable amount, I don't see any problem with it. Link the wiki to change proposal or it could be used instead of the wiki page you mentioned to have it on one place. Even I don't use Gnome Software, it's really very useful thing to have high quality app data for other uses, so thank you! Jaroslav > Richard > > --- > > accerciser > akonadiconsole > akregator > alltray > alsa-tools > amarok > ansifilter-gui > antimicro > antlrworks > apcupsd-gui > aqemu > aqsis > ardour3 > arora > arpage > artha > ascend > asunder > atril > audex > autokey-gtk > autokey-qt > avahi-ui-tools > avogadro > ax25-tools-x > ayttm > backintime-kde > bacula-console-bat > bacula-traymonitor > ballerburg > balsa > batti > bibletime > bibus > bkchem > bleachbit > bluedevil > bmpanel2-cfg > boinc-manager > boswars > bristol > budgie > byobu > caja > calf > calligra-author > cardpeek > cellwriter > chatzilla > chemtool > chirp > chkrootkit > clamtk > clementine > code-editor > coriander > covered > cqrlog > cutecw > datovka > decibel-audio-player > deluge-gtk > denemo > dexter > diffpdf > dillo > din > DivFix++ > dnssec-check > dnssec-nodes > dogtail > dosbox > drumkv1 > drumstick-drumgrid > drumstick-guiplayer > drumstick-vpiano > dssi-calf-plugins > dvdisaster > dwb > easystroke > ebumeter > ecl > eekboard > EekBoek-gui > emacs > emacs-terminal > emelfm2 > engrampa > engrid > enlightenment-data > equalx > eterm > etherape > exaile > exo > extrema > fatrat > fbreader > fcitx > fedora-gooey-karma > ffgtk > fgrun > filelight > fityk > florence > fltk-fluid > flumotion > flush > fmtools-tkradio > fourterm > foxtrotgps > freemind > frescobaldi > fritzing > fvkbd > fwbackups > fwfstab > gajim > galculator > gambas3-runtime > gausssum > gazebo > gchem3d > gchemcalc > gchempaint > gchemtable > gconf-editor > gcrystal > gcstar > geda-gattrib > geda-gschem > gentoo > gerbv > gimmix > gipfel > git-cola > gitso > gjots2 > gkrellm > glabels > glogg > gloobus-preview > gmsh-common > gnaural > gnomad2 > gnome-activity-journal > gnome-do > gnome-genius > gnome-gmail > gnome-pie > gnome-schedule > gnomint > gnumed > gnurobbo > gnu-smalltalk > gphotoframe > gpredict > gpsbabel-gui > gpscorrelate > gpsdrive > gpsman > gpx-viewer > graphem > grig > grisbi > grsync > gscribble > gsmartcontrol > gspectrum > gst-inspector > gtick > gtk-gnutella > gtkpod > gtkterm > gtk-v4l > gtkwave > guake > guayadeque > guitarix > gummi > gwenview > gxneur > harmonyseq > hatari-ui > hdfview > homebank > htmldoc > httrack > hydra-frontend > hydrogen > icedtea-web, jmol > icegrid-gui > idjc > ignuit > ike > imagej > insight > iok > IQmol > ircp-tray > isomaster > jaaa > jabref > jack_capture > jam-control > jamin > japa > java-1.8.0-openjdk > java-1.8.0-openjdk-devel > jd > jflex > jkmeter > josm > juffed > kamoso > kaudiocreator > kbackup > kcachegrind > kchmviewer > kchmviewer-qt > kcm-fcitx > kdbg > kdepim-common > kdesvn > kde-workspace > kdiff3 > keepassx > kernelshark > kflickr > kgeography > kicad > kile > kipi-plugins > kismon > klatexformula > klog > kmail > kmess > kmetronome > kmldonkey > kmousetool > kmplayer > kopete > korganizer > kover > kradio4 > krecipes > krename > krusader > kshutdown > ksshaskpass > ktikz > ktorrent > ktp-contact-list > ktp-text-ui > kvirc > l3afpad > laditools > launchy > lazarus > leafpad > lekhonee-gnome > leksah > libsvm-svm-toy-gtk > libsvm-svm-toy-qt > lilyterm > links > linphone >
F-21 Branched report: 20141107 changes
Compose started at Fri Nov 7 07:45:03 UTC 2014 Broken deps for armhfp -- [PyQuante] PyQuante-libint-1.6.4-11.fc21.1.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [audtty] audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0 [avro] avro-mapred-1.7.5-9.fc21.noarch requires hadoop-mapreduce avro-mapred-1.7.5-9.fc21.noarch requires hadoop-client [blender] 1:blender-2.72b-1.fc21.armv7hl requires libOpenCOLLADAStreamWriter.so.0.1 1:blender-2.72b-1.fc21.armv7hl requires libOpenCOLLADASaxFrameworkLoader.so.0.1 1:blender-2.72b-1.fc21.armv7hl requires libOpenCOLLADAFramework.so.0.1 1:blender-2.72b-1.fc21.armv7hl requires libOpenCOLLADABaseUtils.so.0.1 1:blender-2.72b-1.fc21.armv7hl requires libMathMLSolver.so.0.1 1:blender-2.72b-1.fc21.armv7hl requires libGeneratedSaxParser.so.0.1 1:blenderplayer-2.72b-1.fc21.armv7hl requires libOpenCOLLADAStreamWriter.so.0.1 1:blenderplayer-2.72b-1.fc21.armv7hl requires libOpenCOLLADASaxFrameworkLoader.so.0.1 1:blenderplayer-2.72b-1.fc21.armv7hl requires libOpenCOLLADAFramework.so.0.1 1:blenderplayer-2.72b-1.fc21.armv7hl requires libOpenCOLLADABaseUtils.so.0.1 1:blenderplayer-2.72b-1.fc21.armv7hl requires libMathMLSolver.so.0.1 1:blenderplayer-2.72b-1.fc21.armv7hl requires libGeneratedSaxParser.so.0.1 [cduce] cduce-0.5.5-9.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [django-recaptcha] django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14 [dragonegg] dragonegg-3.4-0.3.rc0.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc21.armv7hl requires libedelib.so edelib-devel-2.1-5.fc21.armv7hl requires libedelib.so [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc21.armv7hl requires libtorrent-rasterbar.so.7 [flush] flush-0.9.12-10.fc21.armv7hl requires libtorrent-rasterbar.so.7 [gdesklet-SlideShow] gdesklet-SlideShow-0.9-16.fc21.noarch requires gdesklets [gdesklets-citation] gdesklets-citation-2.0-3.20120702git355e2ee.fc19.noarch requires gdesklets [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires libvala-0.24.so.0 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0 [golang-github-influxdb-influxdb] golang-github-influxdb-influxdb-datastore-0.8.0-0.3.rc4.git67f9869.fc21.noarch requires golang(github.com/jmhodges/levigo) golang-github-influxdb-influxdb-datastore-0.8.0-0.3.rc4.git67f9869.fc21.noarch requires golang(code.google.com/p/log4go) golang-github-influxdb-influxdb-devel-0.8.0-0.3.rc4.git67f9869.fc21.noarch requires golang(github.com/jmhodges/levigo) golang-github-influxdb-influxdb-devel-0.8.0-0.3.rc4.git67f9869.fc21.noarch requires golang(github.com/influxdb/go-cache) golang-github-influxdb-influxdb-devel-0.8.0-0.3.rc4.git67f9869.fc21.noarch requires golang(github.com/bmizerany/pat) golang-github-influxdb-influxdb-devel-0.8.0-0.3.rc4.git67f9869.fc21.noarch requires golang(code.google.com/p/log4go) [gorm] gorm-1.2.18-5.fc20.armv7hl requires libgnustep-gui.so.0.23 [leiningen] leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks leiningen-1.7.1-7.fc20.noarch requires classworlds [libghemical] libghemical-2.99.1-24.fc20.armv7hl requires libf77blas.so.3 libghemical-2.99.1-24.fc20.armv7hl requires libatlas.so.3 [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.armv7hl requires libopenobex.so.1 [ltsp] ltsp-client-5.4.5-8.fc21.armv7hl requires fuse-unionfs ltsp-server-5.4.5-8.fc21.armv7hl requires cdialog [meshmagick] meshmagick-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 meshmagick-libs-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 [monodevelop-vala] monodevelop-vala-2.8.8.1-6.fc21.armv7hl requires vala < 0:0.25.0 [netdisco] netdisco-1.1-7.fc21.noarch requires perl(SNMP::Info::Layer2::Bay) [ocaml-pa-do] ocaml-pa-do-0.8.16-3.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [openslides] openslides-1.3.1-3.fc21.noarch requires python-django < 0:1.5 [openstack-nova] openstack-nova-compute-2014.1.2-1.fc21.noarch requires libvirt-daemon-xen [openvas-client] openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_omp.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_nasl.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_misc.so.6 openvas-client-3.0.3
Re: Join to Mozilla Location Service in Fedora
On Thursday, November 06, 2014 08:10:19 PM Jiri Eischmann wrote: > It's usually opt-in, so you don't have to use it and don't use it by > default. This is at least designed as anonymous while Google tracks all > Android users and saves their personal location data by default. I don't mind sharing data as long as the data is shared back in some interesting form. I think it's a misconception that Google saves personal location data by default. When you setup your device for the first time it will ask you to enable location reporting. You can disable location reporting and delete location history on your Android devices using this link [1]. You will also lose access to all the value that location aware apps provide. [1] https://support.google.com/gmm/answer/3118687?hl=en -- Regards, Sudhir Khanger, sudhirkhanger.com, github.com/donniezazen, 5577 8CDB A059 085D 1D60 807F 8C00 45D9 F5EF C394. signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: PROPOSAL: Make AppData files mandatory for applications shown in the software center
On 7 November 2014 11:04, Alexander Ploumistos wrote: > I read your blog posts on AppStream/AppData and I found some > Workstation/AppDataImprovement pages on the wiki, but I could not find the > list you provided in your original message. https://lists.fedoraproject.org/pipermail/devel/2014-November/204026.html > I want to take on some of the > scientific packages, but I don't know if someone has already filed requests > with upstream or if they are working on any of them. Is there such a page > somewhere? I've already created bugs for at least any upstream that used launchpad, sourceforge, gnome bugzilla, fedora trac, RH bugzilla, Freedesktop bugzilla, or had an easy way to report bugs that didn't require signing up to a random forum. I've even reported some bugs that *did* require signing up to random php trackers. The best way of finding the upstream bug is google, e.g. https://www.google.co.uk/search?q=appdata+subsurface > Please go easy on me, new guy learning the ropes here. Please yell if anything doesn't make sense; I'm also on IRC with a nick of "hughsie" if you want any more help. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: PROPOSAL: Make AppData files mandatory for applications shown in the software center
On 7 November 2014 11:24, Jaroslav Reznik wrote: > This is a very good idea, if we want to enforce it, packaging guidelines > are good place to start with for new applications. Approved, but ignored: https://fedorahosted.org/fpc/ticket/414 Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: PROPOSAL: Make AppData files mandatory for applications shown in the software center
- Original Message - > On 7 November 2014 11:24, Jaroslav Reznik wrote: > > This is a very good idea, if we want to enforce it, packaging guidelines > > are good place to start with for new applications. > > Approved, but ignored: https://fedorahosted.org/fpc/ticket/414 Based on the last comment, it's not yet in guidelines :(. mattdm: *ping* FPC. Looks like this still isn't in the guidelines? And other thing is, it should be in review checklist [1] and fedora-review tool. [1] http://fedoraproject.org/wiki/Packaging:ReviewGuidelines Jaroslav > Richard. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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: Virtual network interface
On 2014-11-07, Vít Ondruch wrote: > Is there way how to setup some virtual network inteface, which would > always work, no matter if I use ethernet, wireles, VPN or whatever else > network connection on background? > Your question contains the answer: You need to create a tunnel to an always reachable node and use the tunneled IP address. This way you will have always a static IP address on your mobile host. There are other posibilities like mobile IP extension or multipath TCP or even some experiments splitting node's IP address into location and identifier halves. (In order of number of deployments :) > * It is pretty annoying that every time I change my location, I have to > change configuration of my virtual machines, just because now I am not > connected via ethernet, but via WiFi. You assign your own private addresses to them and use them in scope of your host and virtual machines running in it. > * I don't understand why my Xchat should loose connection, when I am > switching from ethernet to WiFi (and they are both available during > interim period). > The reason is that processes usually work with transport adresses (e.g. a TCP) and these include network address (e.g. an IP). And network addresses in the current Internet are used as locators, thus they depend on the network topology. > The type of network connection is just implementation detail, so why > this does not work? If there is possible to create some virtual network > interface, which would take all the real network connection under one > umbrella, this should be default for Fedora Workstation. > Well, it is possible. But any site operator would shot you because you would break his precious one-way firewall. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: downgrade version of gthumb in fedora 21 final?
On Fri, 2014-11-07 at 08:52 +, Richard Hughes wrote: > On 7 November 2014 00:31, Michael Catanzaro wrote: > > Since gthumb does not follow the GNOME release schedule, we > > shouldn't push unstable versions of gthumb to rawhide. > > No? We push unstable GNOME to rawhide all the time; or is this more of > a case where we're worrying that a stable gthumb won't be available > before F22 is due? The original email was talking about F21. Seems pretty unlikely that it will happen in time, so we need a downgrade (and epoch bump) signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: downgrade version of gthumb in fedora 21 final?
On Fri, 2014-11-07 at 08:52 +, Richard Hughes wrote: > No? We push unstable GNOME to rawhide all the time; or is this more of > a case where we're worrying that a stable gthumb won't be available > before F22 is due? Exactly; since that's what happened for F21, there's a reasonable chance it will happen in the future as well, if not for F22 (which seems quite possible), maybe F23. With most of GNOME, we know when the next stable release will be, and there's no harm in pushing unstable versions so that they get testing. That's not the case with gthumb. I'm confused why they're not following the GNOME release cycle, but that's their choice, and the reasonable consequence is that they get less testing in rawhide so we don't have to gamble on whether or not we'll need to do a downgrade and +epoch or choose to leave it unstable. (In this case, the revert is clearly the correct choice as upstream has said we should not ship 3.3. Anyway, this vindicates the WG's choice to stick with Shotwell for the time being, as gthumb 3.2 really is a huge downgrade) signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: PROPOSAL: Make AppData files mandatory for applications shown in the software center
You can scratch nut-monitor off, it already has appdata: https://github.com/networkupstools/nut/blob/master/scripts/python/app/nut-monitor.appdata.xml -- 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: PROPOSAL: Make AppData files mandatory for applications shown in the software center
On 7 November 2014 15:01, Alexander Ploumistos wrote: > You can scratch nut-monitor off, it already has appdata: Is it in a tarball that's been built for F22? What some upstreams do is commit the file upstream but either forget to dist the file in the tarball, or forget to install the file at install time. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: PROPOSAL: Make AppData files mandatory for applications shown in the software center
2014-11-07 17:28 GMT+02:00 Richard Hughes : > Is it in a tarball that's been built for F22? > Version 2.7.2 was released in April and it doesn't have it, it's in their development tree. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[PkgDB] pingou:perl-multidimensional set point of contact to: orphan
user: pingou changed point of contact of package: perl-multidimensional from: iarnell to: orphan on branch: master To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-multidimensional -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[PkgDB] pingou:perl-Data-Visitor set point of contact to: orphan
user: pingou changed point of contact of package: perl-Data-Visitor from: iarnell to: orphan on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Data-Visitor -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[PkgDB] pingou:perl-Catalyst-View-Mason set point of contact to: orphan
user: pingou changed point of contact of package: perl-Catalyst-View-Mason from: iarnell to: orphan on branch: f19 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Catalyst-View-Mason -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: iccjpeg.h errors
Hi, On Thu, Nov 06, 2014 at 06:16:33PM +0100, Antonio Trande wrote: > Hi David. > > On 11/06/2014 01:03 PM, David Tardon wrote: > > Hi, > > > > On Wed, Nov 05, 2014 at 06:17:27PM +0100, Antonio Trande wrote: > >> Hi all. > >> > >> I don't know how to fix these errors during IceCat compilation. Lately I > >> tried to adapt Fedora compilations flags but there is wrong something. > >> > >> Here the log: > >> http://koji.fedoraproject.org/koji/getfile?taskID=8044663&name=build.log&offset=-4000 > > > > The JPP macro is no longer defined in libjpeg-turbo-devel-1.3.90. You > > can either replace all JPP(arglist) uses by arglist, > > ... > > (By coincidence, I did the same replacement in libreoffice's jpeg > > filter just a few hours ago...) > > Can you show me the patch that you used ? https://gerrit.libreoffice.org/gitweb?p=core.git;a=commitdiff;h=4d687aec3c5ea0f18ab3f01f827cc544e677bae3;hp=c838ce2f2fd7bfe168f610f5a6de426ba48aa68d D. -- 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: LLVM 3.5 rebase
On Thu, 2014-11-06 at 20:51 -0500, Jens Petersen wrote: > > That's only going to work if llvm34 renames all of its binaries, and ghc > > is changed to invoke the renamed ones, right? Otherwise the 3.4 and 3.5 > > versions of /usr/bin/llc will conflict. > > Hmm yes I guess I should go the whole way... > > My initial lazy plan was just that ghc-compiler.armv7hl > should require and BR llvm34 instead of llvm (and make llvm34 > Conflicts with llvm and llvm34-devel conflicts with llvm-devel...). Seems like a lot of work on your part to avoid doing any work on the arm maintainers' parts. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: No more deltarpms by default
Hi On Fri, Nov 7, 2014 at 1:19 AM, Dennis Gilmore wrote: > > /etc/yum.repos.d/fedora-updates.repo on f21 has > metadata_expire=6h > I was looking at dnf since the discussion is about dnf > and the metadata right now for f21 updates is an empty repo with no > packages in it f20 updates repo > http://dl.fedoraproject.org/pub/fedora/linux/updates/20/x86_64/repodata/ > right now has primary.sqllite of 12M and filelists.sqlite of 19M not > sure how you got 32K Not sure. Probably misread something Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[PkgDB] averi:perl-POE-Component-SSLify commit set to
user: averi set for averi acl: commit of package: perl-POE-Component-SSLify from: Obsolete to: on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-POE-Component-SSLify -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[PkgDB] averi:perl-POE-Component-SSLify watchcommits set to
user: averi set for averi acl: watchcommits of package: perl-POE-Component-SSLify from: Approved to: on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-POE-Component-SSLify -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: PROPOSAL: Make AppData files mandatory for applications shown in the software center
I will take care of the MATE packages and coordinate with upstream. I will also deal with the following: easystroke qbittorrent x11vnc krename avogadro bkchem chemtool gausssum IQmol openbabel-gui pybliographer If someone has already contacted upstream or if you have created appdata files about any of them, please let me know. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[PkgDB] averi:perl-MooseX-POE approveacls set to Approved
user: averi set for averi acl: approveacls of package: perl-MooseX-POE from: Obsolete to: Approved on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-MooseX-POE -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Join to Mozilla Location Service in Fedora
On Fri, 07 Nov 2014 18:03:06 +0530 Sudhir Khanger wrote: > On Thursday, November 06, 2014 08:10:19 PM Jiri Eischmann wrote: > > It's usually opt-in, so you don't have to use it and don't use it by > > default. This is at least designed as anonymous while Google tracks > > all Android users and saves their personal location data by default. > > I don't mind sharing data as long as the data is shared back in some > interesting form. > > I think it's a misconception that Google saves personal location data > by default. When you setup your device for the first time it will ask > you to enable location reporting. You can disable location reporting > and delete location history on your Android devices using this link > [1]. You will also lose access to all the value that location aware > apps provide. And you do realize this is just a subtle punishment for not surrendering to them your location data ? They could simply offer you a middle ground, (say store just one day or one week of data), but nope, it's either all or nothing, and if you choose nothing, we'll cripple your service, KTHXBYE. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
libcdio-0.93 license changed to GPLv3+
Hi, libcdio license changed to GPLv3+ in version 0.93. Cdrkit (GPLv2) in Fedora reverted to use old cdda-paranoia instead of libcdio-paranoia. I am not aware of any other legal issues. Dependent packages will need a rebuild after the rebase. Fero -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[PkgDB] pghmcfc:perl-PadWalker approveacls set to Approved
user: pghmcfc set for pghmcfc acl: approveacls of package: perl-PadWalker from: Approved to: Approved on branch: el5 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-PadWalker -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[PkgDB] pghmcfc:perl-PadWalker watchbugzilla set to Approved
user: pghmcfc set for pghmcfc acl: watchbugzilla of package: perl-PadWalker from: Approved to: Approved on branch: el5 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-PadWalker -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: No more deltarpms by default
Am 07.11.2014 um 17:53 schrieb Rahul Sundaram: On Fri, Nov 7, 2014 at 1:19 AM, Dennis Gilmore wrote: /etc/yum.repos.d/fedora-updates.repo on f21 has metadata_expire=6h I was looking at dnf since the discussion is about dnf where do you see DNF using other than "/etc/yum.repos.d/" DNF is using the same directory and repo configs that's part of the fedora release package and the metadata right now for f21 updates is an empty repo with no packages in it f20 updates repo http://dl.fedoraproject.org/pub/fedora/linux/updates/20/x86_64/repodata/ right now has primary.sqllite of 12M and filelists.sqlite of 19M not sure how you got 32K Not sure. Probably misread something the meta-data are fat look below [root@rawhide ~]# rm -rf /var/cache/dnf/* [root@rawhide ~]# df DateisystemTyp Größe Benutzt Verf. Verw% Eingehängt auf /dev/sdb1 ext4 12G598M 11G6% / /dev/sda1 ext4 487M 35M 448M8% /boot [root@rawhide ~]# dnf --disablerepo=koji info kernel 2> /dev/null > /dev/null [root@rawhide ~]# df DateisystemTyp Größe Benutzt Verf. Verw% Eingehängt auf /dev/sdb1 ext4 12G713M 11G7% / /dev/sda1 ext4 487M 35M 448M8% /boot [root@rawhide ~]# rm -rf /var/cache/dnf/* [root@rawhide ~]# df DateisystemTyp Größe Benutzt Verf. Verw% Eingehängt auf /dev/sdb1 ext4 12G598M 11G6% / /dev/sda1 ext4 487M 35M 448M8% /boot signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Virtual network interface
Vít Ondruch wrote: > * I don't understand why my Xchat should loose connection, when I am > switching from ethernet to WiFi (and they are both available during > interim period). For this use case you want to run IRC over SCTP, so that you can keep the connection open when you change IP addresses. The best that can be done with TCP is to automatically reconnect from the new IP address when the old TCP connection breaks. Using SCTP requires of course that the IRC server listens for SCTP connections. There must also not be any overzealous firewalls that block SCTP just because they don't know what it is. Björn Persson signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Mass orphan: iarnell
Hi all, Following ticket: https://fedorahosted.org/fesco/ticket/1360 I have just orphaned all the packages from iarnell on all branches. During the mass-orphaned we found out a bug in pkgdb making it orphaned all the branches of the package, not just the ones for which the user is POC. Unfortunately, this means we have orphaned branches that were maintained by someone else than Iarnell. If you are in this situation, sorry about that, feel free to just re-take the branches. Feel free to visit pkgdb to pick the package(s) you may be interested in. Best regards, Pierre clc-intercal -- Compiler for the INTERCAL language ( master f21 f20 f19 ) mojomojo -- A Wiki with a tree ( master f21 f20 f19 ) perl-Algorithm-IncludeExclude -- Build and evaluate include/exclude lists ( master f21 f20 f19 ) perl-Algorithm-Merge -- Three-way merge and diff ( master f21 f20 f19 ) perl-Any-Moose -- Use Moose or Mouse automagically (DEPRECATED) ( master f21 f20 f19 ) perl-App-Daemon -- Start an Application as a Daemon ( master f21 f20 f19 el6 el5 ) perl-App-Nopaste -- Easy access to any pastebin ( master f21 f20 f19 epel7 ) perl-B-Compiling -- Expose PL_compiling to perl ( master f21 f20 f19 ) perl-B-Generate -- Create your own op trees ( master f21 f20 f19 ) perl-B-Hooks-OP-Annotation -- Annotate and delegate hooked OPs ( master f21 f20 f19 epel7 ) perl-B-Hooks-OP-Check -- Wrap OP check callbacks ( master f21 f20 f19 ) perl-B-Hooks-OP-Check-EntersubForCV -- Invoke callbacks on construction of entersub OPs for certain CVs ( master f21 f20 f19 ) perl-B-Utils -- Helper functions for op tree manipulation ( master f21 f20 f19 epel7 el6 el5 ) perl-BackPAN-Index -- Interface to the BackPAN index ( master f21 f20 f19 ) perl-Bencode -- BitTorrent serialization format ( master f21 f20 f19 ) perl-Browser-Open -- Open a browser in a given URL ( master f21 f20 f19 ) perl-CPAN-Meta -- Distribution metadata for a CPAN dist ( master f21 f20 f19 ) perl-CPAN-Meta-Requirements -- Set of version requirements for a CPAN dist ( master f21 f20 f19 ) perl-CPAN-Perl-Releases -- Mapping Perl releases on CPAN to the location of the tarballs ( master f21 f20 f19 ) perl-CPAN-Uploader -- Upload things to the CPAN ( master f21 f20 f19 ) perl-Cache-FastMmap -- Uses an mmap'ed file to act as a shared memory interprocess cache ( master f21 f20 f19 el6 el5 ) perl-Captcha-reCAPTCHA -- Perl implementation of the reCAPTCHA API ( master f21 f20 f19 ) perl-Carp-Clan-Share -- Share your Carp::Clan settings with your whole Clan ( master f21 f20 f19 ) perl-Carp-REPL -- Read-eval-print-loop on die and/or warn ( master f21 f20 f19 ) perl-Catalyst-Action-REST -- Automated REST Method Dispatching ( master f21 f20 f19 ) perl-Catalyst-Action-RenderView -- Sensible default end action for view rendering ( master f21 f20 f19 el6 ) perl-Catalyst-ActionRole-ACL -- User role-based authorization action class ( master f21 f20 f19 ) perl-Catalyst-Authentication-Credential-HTTP -- HTTP Basic and Digest authentication for Catalyst ( master f21 f20 f19 ) perl-Catalyst-Component-InstancePerContext -- Return a new instance a component on each request ( master f21 f20 f19 ) perl-Catalyst-Controller-ActionRole -- Apply roles to action instances ( master f21 f20 f19 ) perl-Catalyst-Controller-FormBuilder -- Catalyst FormBuilder Base Controller ( master f21 f20 f19 ) perl-Catalyst-Controller-HTML-FormFu -- HTML::FormFu controller for Catalyst ( master f21 f20 f19 ) perl-Catalyst-Devel -- Catalyst Development Tools ( master f21 f20 f19 el6 ) perl-Catalyst-Engine-Apache -- Catalyst Apache Engines ( master f21 f20 f19 ) perl-Catalyst-Helper-FastCGI-ExternalServer -- FastCGI daemon start/stop script for using FastCgiExternalServer ( master f21 f20 f19 ) perl-Catalyst-Manual -- Catalyst web framework manual ( master f21 f20 f19 ) perl-Catalyst-Model-Adaptor -- Use a plain class as a Catalyst model ( master f21 f20 f19 ) perl-Catalyst-Model-DBIC-Schema -- DBIx::Class::Schema Model Class ( master f21 f20 f19 el6 ) perl-Catalyst-Model-XMLRPC -- XMLRPC model class for Catalyst ( master f21 f20 f19 ) perl-Catalyst-Plugin-Authentication -- Infrastructure plugin for the Catalyst authentication framework ( master f21 f20 f19 ) perl-Catalyst-Plugin-Authorization-Roles -- Role based authorization for Catalyst based on Catalyst::Plugin::Authentication ( master f21 f20 f19 ) perl-Catalyst-Plugin-CGI-Untaint -- CGI::Untaint Plugin for Catalyst ( master f21 f20 f19 ) perl-Catalyst-Plugin-Cache -- Flexible caching support for Catalyst ( master f21 f20 f19 ) perl-Catalyst-Plugin-ConfigLoader -- Load config files of various types ( master f21 f20 f19 el6 ) perl-Catalyst-Plugin-Email -- Send emails with Catalyst ( master f21 f20 f19 ) perl-Catalyst-Plugin-I18N -- I18N for Catalyst ( master f21 f20 f19 el6 ) perl-Catalyst-Plugin-PageCache -- Cache the output of entire pages ( master f21 f20 f19 ) perl-Catalyst-Plugin-Session -- Catalyst generic session plugin ( master f21 f20 f19 el
Re: Mass orphan: iarnell
On 11/07/2014 05:18 PM, Pierre-Yves Chibon wrote: Hi all, Following ticket: https://fedorahosted.org/fesco/ticket/1360 I have just orphaned all the packages from iarnell on all branches. Would it be possible to somehow accumulate/bundle related PkgDB-change mails and not to send individual mails for each DB-transaction? I guess, you are aware, you had triggered sending 4000-5000 PkgDB-change mails, this time - You can imagine what I did with them ;) Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
