undefined reference to symbol 'gdk_pixbuf_save_to_buffer'
trying to build guayadeque on Fedora 18 Alpha, but this fails with the following error message: [100%] Building C object src/CMakeFiles/guayadeque.dir/hmac/sha2.o cd /root/rpmbuild/BUILD/guayadeque-svn1830/build-guayadeque/src && /usr/lib64/ccache/gcc -DTAGLIB_WITH_MP4_COVERS=1 -DWITH_LIBGPOD_SUPPORT=1 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -isystem /usr/lib64/wx/include/gtk2-unicode-release-2.8 -isystem /usr/include/wx-2.8 -I/root/rpmbuild/BUILD/guayadeque-svn1830 -I/root/rpmbuild/BUILD/guayadeque-svn1830/src -I/usr/include/gstreamer-0.10 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/taglib -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/gpod-1.0 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng15 -I/usr/include/p11-kit-1 -I/root/rpmbuild/BUILD/guayadeque-svn1830/src/wx -I/root/rpmbuild/BUILD/guayadeque-svn1830/src/wx/curl -I/root/rpmbuild/BUILD/guayadeque-svn1830/src/wxsqlite3 -I/root/rpmbuild/BUILD/guayadeque-svn1830/src/dbus -I/root/rpmbuild/BUILD/guayadeque-svn1830/src/hmac -I/root/rpmbuild/BUILD/guayadeque-svn1830/src/execstream -I/usr/include/FLAC -Wall -O2 -o CMakeFiles/guayadeque.dir/hmac/sha2.o -c /root/rpmbuild/BUILD/guayadeque-svn1830/src/hmac/sha2.c In file included from /root/rpmbuild/BUILD/guayadeque-svn1830/src/PlayerPanel.h:28:0, from /root/rpmbuild/BUILD/guayadeque-svn1830/src/dbus/mpris2.h:25, from /root/rpmbuild/BUILD/guayadeque-svn1830/src/dbus/mpris2.cpp:21: /root/rpmbuild/BUILD/guayadeque-svn1830/src/MediaCtrl.h: In member function 'void guFaderPlayBin::EndFade()': /root/rpmbuild/BUILD/guayadeque-svn1830/src/MediaCtrl.h:287:35: warning: deleting object of polymorphic class type 'guTimeLine' which has non-virtual destructor might cause undefined behaviour [-Wdelete-non-virtual-dtor] Linking CXX executable guayadeque cd /root/rpmbuild/BUILD/guayadeque-svn1830/build-guayadeque/src && /usr/bin/cmake -E cmake_link_script CMakeFiles/guayadeque.dir/link.txt --verbose=1 /usr/lib64/ccache/c++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -pthread -Wl,-z,relro CMakeFiles/guayadeque.dir/AlListBox.o CMakeFiles/guayadeque.dir/ArListBox.o CMakeFiles/guayadeque.dir/ArrayStringArray.o CMakeFiles/guayadeque.dir/AudioScrobble.o CMakeFiles/guayadeque.dir/Config.o CMakeFiles/guayadeque.dir/ConfirmExit.o CMakeFiles/guayadeque.dir/CoverEdit.o CMakeFiles/guayadeque.dir/CoverFrame.o CMakeFiles/guayadeque.dir/Db.o CMakeFiles/guayadeque.dir/DbLibrary.o CMakeFiles/guayadeque.dir/DbRadios.o CMakeFiles/guayadeque.dir/DbCache.o CMakeFiles/guayadeque.dir/AutoPulseGauge.o CMakeFiles/guayadeque.dir/GeListBox.o CMakeFiles/guayadeque.dir/Images.o CMakeFiles/guayadeque.dir/ItemListBox.o CMakeFiles/guayadeque.dir/LabelEditor.o CMakeFiles/guayadeque.dir/LastFM.o CMakeFiles/guayadeque.dir/LastFMPanel.o CMakeFiles/guayadeque.dir/LibPanel.o CMakeFiles/guayadeque.dir/LyricsPanel.o CMakeFiles/guayadeque.dir/MainApp.o CMakeFiles/guayadeque.dir/MainFrame.o CMakeFiles/guayadeque.dir/MD5.o CMakeFiles/guayadeque.dir/MediaCtrl.o CMakeFiles/guayadeque.dir/PlayerPanel.o CMakeFiles/guayadeque.dir/PlayList.o CMakeFiles/guayadeque.dir/Preferences.o CMakeFiles/guayadeque.dir/RadioGenreEditor.o CMakeFiles/guayadeque.dir/RadioPanel.o CMakeFiles/guayadeque.dir/Shoutcast.o CMakeFiles/guayadeque.dir/SoListBox.o CMakeFiles/guayadeque.dir/SplashWin.o CMakeFiles/guayadeque.dir/StatusBar.o CMakeFiles/guayadeque.dir/TagInfo.o CMakeFiles/guayadeque.dir/TaListBox.o CMakeFiles/guayadeque.dir/TaskBar.o CMakeFiles/guayadeque.dir/TrackEdit.o CMakeFiles/guayadeque.dir/Utils.o CMakeFiles/guayadeque.dir/VolumeFrame.o CMakeFiles/guayadeque.dir/OnlineLinks.o CMakeFiles/guayadeque.dir/LibUpdate.o CMakeFiles/guayadeque.dir/CoverFetcher.o CMakeFiles/guayadeque.dir/Google.o CMakeFiles/guayadeque.dir/Amazon.o CMakeFiles/guayadeque.dir/RatingCtrl.o CMakeFiles/guayadeque.dir/PlayListPanel.o CMakeFiles/guayadeque.dir/DynamicPlayList.o CMakeFiles/guayadeque.dir/ListView.o CMakeFiles/guayadeque.dir/PLSoListBox.o CMakeFiles/guayadeque.dir/Base64.o CMakeFiles/guayadeque.dir/ApeTag.o CMakeFiles/guayadeque.dir/Discogs.o CMakeFiles/guayadeque.dir/MusicDns.o CMakeFiles/guayadeque.dir/MusicBrainz.o CMakeFiles/guayadeque.dir/Podcasts.o CMakeFiles/guayadeque.dir/PodcastsPanel.o CMakeFiles/guayadeque.dir/ChannelEditor.o CMakeFiles/guayadeque.dir/NewChannel.o CMakeFiles/guayadeque.dir/RadioEditor.o CMakeFiles/guayadeque.dir/PlayListAppend.o CMakeFiles/guayadeque.dir/TrackChangeInfo.o CMakeFiles/guayadeque.dir/Equalizer.o CMakeFiles/guayadeque.dir/ShowImage.o CMakeFiles/guayadeque.dir/StaticBitmap.o CMakeFiles/guayadeque.dir/LastFMCovers.o CMakeFiles/guayadeque.dir/PlayListFile.o CMakeFiles/guayadeque.dir/AuiNotebook.o CMakeFiles/guayadeque.
Re: FusionInventory stack need a new maintainer, or a co-maintainer, or be ORPHAN
Packages retired from fedora >= 18 > fusioninventory-agent > perl-FusionInventory-Agent-Task-Deploy > perl-FusionInventory-Agent-Task-ESX > perl-FusionInventory-Agent-Task-NetDiscovery > perl-FusionInventory-Agent-Task-NetInventory -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: undefined reference to symbol 'gdk_pixbuf_save_to_buffer'
On Fri, 7 Sep 2012 09:15:40 +0200 (CEST), Martin Gansser wrote: > > trying to build guayadeque on Fedora 18 Alpha, but this fails with the > following error message: > > Linking CXX executable guayadeque > [...] -o guayadeque -rdynamic -pthread -Wl,-z,relro -lwx_baseu-2.8 > -lwx_gtk2u_core-2.8 -lwx_gtk2u_adv-2.8 -lwx_baseu_net-2.8 -lwx_gtk2u_html-2.8 > -lwx_baseu_xml-2.8 -lwx_gtk2u_aui-2.8 -lwx_gtk2u_qa-2.8 -lgstreamer-0.10 > -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lxml2 -lglib-2.0 -lsqlite3 > -lcurl -ltag -lFLAC -lm -ldbus-1 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lgpod > -lgmodule-2.0 -lgthread-2.0 -lrt -lxml2 -lsqlite3 -lcurl -ltag -lFLAC -lm > -ldbus-1 -lgio-2.0 -lgpod > /bin/ld: CMakeFiles/guayadeque.dir/iPodMedia.o: undefined reference to symbol > 'gdk_pixbuf_save_to_buffer' > /bin/ld: note: 'gdk_pixbuf_save_to_buffer' is defined in DSO > /lib64/libgdk_pixbuf-2.0.so.0 so try adding it to the linker command line > (!) Have you tried that suggestion? -lgdk_pixbuf-2.0.so is not in the linker options above. -- Fedora release 17 (Beefy Miracle) - Linux 3.5.3-1.fc17.x86_64 loadavg: 0.12 0.35 0.18 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20120907 changes
Compose started at Fri Sep 7 08:15:05 UTC 2012 Broken deps for x86_64 -- [almanah] almanah-0.8.0-7.fc18.x86_64 requires libedataserverui-3.0.so.3()(64bit) almanah-0.8.0-7.fc18.x86_64 requires libedataserver-1.2.so.16()(64bit) almanah-0.8.0-7.fc18.x86_64 requires libecal-1.2.so.12()(64bit) almanah-0.8.0-7.fc18.x86_64 requires libebook-1.2.so.13()(64bit) [archmage] archmage-0.2.4-6.fc18.noarch requires python-chm [chm2pdf] chm2pdf-0.9.1-12.fc18.noarch requires python-chm [clutter-gtk010] clutter-gtk010-0.11.4-6.fc17.i686 requires libcogl.so.9 clutter-gtk010-0.11.4-6.fc17.x86_64 requires libcogl.so.9()(64bit) [ease] ease-0.4-18.fc17.i686 requires libcogl.so.9 ease-0.4-18.fc17.x86_64 requires libcogl.so.9()(64bit) [emacs-spice-mode] emacs-spice-mode-1.2.25-9.fc18.noarch requires gwave [eog-plugins] eog-plugins-3.4.1-2.fc18.x86_64 requires libcogl.so.9()(64bit) [evolution-couchdb] evolution-couchdb-0.5.91-10.fc18.x86_64 requires libedataserver-1.2.so.16()(64bit) evolution-couchdb-0.5.91-10.fc18.x86_64 requires libedata-cal-1.2.so.15()(64bit) evolution-couchdb-0.5.91-10.fc18.x86_64 requires libedata-book-1.2.so.13()(64bit) evolution-couchdb-0.5.91-10.fc18.x86_64 requires libecal-1.2.so.11()(64bit) evolution-couchdb-0.5.91-10.fc18.x86_64 requires libebook-1.2.so.13()(64bit) evolution-couchdb-0.5.91-10.fc18.x86_64 requires libcamel-1.2.so.33()(64bit) [evolution-exchange] evolution-exchange-3.5.2-1.fc18.x86_64 requires libedataserverui-3.0.so.3()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libedataserver-1.2.so.16()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libedata-cal-1.2.so.17()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libedata-book-1.2.so.14()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libecal-1.2.so.12()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libebook-1.2.so.13()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libebackend-1.2.so.3()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libcamel-1.2.so.36()(64bit) [fedora-ksplice] fedora-ksplice-0.5-10.fc18.x86_64 requires ksplice [flush] flush-0.9.10-7.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) flush-0.9.10-7.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) flush-0.9.10-7.fc18.x86_64 requires libboost_signals-mt.so.1.48.0()(64bit) flush-0.9.10-7.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) [fontik] fontik-0.6.1-2.20120305git5dbbc513.fc18.x86_64 requires libgee-0.8.so.0()(64bit) [gcstar] gcstar-1.7.0-1.fc19.noarch requires perl(Gtk2::Table) gcstar-1.7.0-1.fc19.noarch requires perl(Gtk2::HBox) gcstar-1.7.0-1.fc19.noarch requires perl(Gtk2::Frame) gcstar-1.7.0-1.fc19.noarch requires perl(Gtk2::EventBox) gcstar-1.7.0-1.fc19.noarch requires perl(GCItemsLists::GCListOptions) gcstar-1.7.0-1.fc19.noarch requires perl(GCItemsLists::GCImageListComponents) gcstar-1.7.0-1.fc19.noarch requires perl(GCGraphicComponents::GCDoubleLists) gcstar-1.7.0-1.fc19.noarch requires perl(GCGraphicComponents::GCBaseWidgets) [gdb-heap] gdb-heap-0.5-9.fc18.x86_64 requires glibc(x86-64) = 0:2.15 [gearmand] gearmand-0.33-2.fc18.x86_64 requires libboost_program_options-mt.so.1.48.0()(64bit) [glom] glom-1.18.6-1.fc17.x86_64 requires libboost_python.so.1.48.0()(64bit) glom-libs-1.18.6-1.fc17.i686 requires libboost_python.so.1.48.0 glom-libs-1.18.6-1.fc17.x86_64 requires libboost_python.so.1.48.0()(64bit) [gnome-applets] 1:gnome-applets-3.5.1-1.fc18.x86_64 requires libgweather-3.so.0()(64bit) [gnome-boxes] gnome-boxes-3.5.5-1.fc19.x86_64 requires libcogl.so.9()(64bit) [gnome-color-manager] gnome-color-manager-3.5.3-2.fc18.x86_64 requires libcogl.so.9()(64bit) [gnome-contacts] gnome-contacts-3.5.4.1-1.fc18.x86_64 requires libcogl.so.9()(64bit) gnome-contacts-3.5.4.1-1.fc18.x86_64 requires libcamel-1.2.so.39()(64bit) [gnome-games] 1:gnome-games-gnibbles-3.5.5-3.fc19.x86_64 requires libcogl.so.9()(64bit) 1:gnome-games-lightsoff-3.5.5-3.fc19.x86_64 requires libcogl.so.9()(64bit) 1:gnome-games-quadrapassel-3.5.5-3.fc19.x86_64 requires libcogl.so.9()(64bit) 1:gnome-games-swell-foop-3.5.5-3.fc19.x86_64 requires libcogl.so.9()(64bit) [gnome-pilot] gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libedataserverui-3.0.so.1()(64bit) gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libedataserver-1.2.so.16()(64bit) gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libecal-1.2.so.11()(64bit) gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libebook-1.2.so.1
Bluetooth causes system crash on F16
Hi, I haven't seen linux system killed so effectively for a lng time, everytime I try to use bluetooth dongle my system just crashes. Has this been reported? I searched this list and bugzilla but didn't finy anything. Kernel version: 3.4.9-2.fc16.x86_64 Is this a known issue? Here is my messages log file: http://fpaste.org/cdUz/ -- follow me - www.twitter.com/valentt & http://kernelreloaded.blog385.com linux, anime, spirituality, wireless, scuba, linuxmce smart home, zwave ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turko...@hotmail.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File CPAN-Perl-Releases-0.68.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-CPAN-Perl-Releases: db8a99fc617f83321ae7d870f5e5884b CPAN-Perl-Releases-0.68.tar.gz -- 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: Bluetooth causes system crash on F16
Found it on bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=768153 Isn't kernel supposed to be a bit more resilient, there is probably some exploit in bluetooth code just waiting to be explited... On Fri, Sep 7, 2012 at 2:56 PM, valent.turko...@gmail.com wrote: > Hi, > I haven't seen linux system killed so effectively for a lng time, > everytime I try to use bluetooth dongle my system just crashes. > Has this been reported? I searched this list and bugzilla but didn't > finy anything. > > Kernel version: 3.4.9-2.fc16.x86_64 > > Is this a known issue? > > Here is my messages log file: http://fpaste.org/cdUz/ > > -- > follow me - www.twitter.com/valentt & http://kernelreloaded.blog385.com > linux, anime, spirituality, wireless, scuba, linuxmce smart home, zwave > ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turko...@hotmail.com -- follow me - www.twitter.com/valentt & http://kernelreloaded.blog385.com linux, anime, spirituality, wireless, scuba, linuxmce smart home, zwave ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turko...@hotmail.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-CPAN-Perl-Releases] update to 0.68
commit b93194907158886d21224faeba31c334d346d2e5
Author: Iain Arnell
Date: Fri Sep 7 07:01:31 2012 -0600
update to 0.68
.gitignore |1 +
perl-CPAN-Perl-Releases.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 99036e7..fe29478 100644
--- a/.gitignore
+++ b/.gitignore
@@ -6,3 +6,4 @@
/CPAN-Perl-Releases-0.58.tar.gz
/CPAN-Perl-Releases-0.62.tar.gz
/CPAN-Perl-Releases-0.66.tar.gz
+/CPAN-Perl-Releases-0.68.tar.gz
diff --git a/perl-CPAN-Perl-Releases.spec b/perl-CPAN-Perl-Releases.spec
index eb3c6e6..9d3c3c8 100644
--- a/perl-CPAN-Perl-Releases.spec
+++ b/perl-CPAN-Perl-Releases.spec
@@ -1,5 +1,5 @@
Name: perl-CPAN-Perl-Releases
-Version:0.66
+Version:0.68
Release:1%{?dist}
Summary:Mapping Perl releases on CPAN to the location of the tarballs
License:GPL+ or Artistic
@@ -48,6 +48,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Fri Sep 07 2012 Iain Arnell 0.68-1
+- update to latest upstream version
+
* Sat Aug 18 2012 Iain Arnell 0.66-1
- update to latest upstream version
diff --git a/sources b/sources
index c1a6ba4..4479438 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-571e63c57147363a776c1c05bbbef7ed CPAN-Perl-Releases-0.66.tar.gz
+db8a99fc617f83321ae7d870f5e5884b CPAN-Perl-Releases-0.68.tar.gz
--
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
[perl-CPAN-Perl-Releases/f18] update to 0.68
Summary of changes: b931949... update to 0.68 (*) (*) This commit already existed in another branch; no separate mail sent -- 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
[perl-CPAN-Perl-Releases/f17] update to 0.68
Summary of changes: b931949... update to 0.68 (*) (*) This commit already existed in another branch; no separate mail sent -- 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
[perl-CPAN-Perl-Releases/f16] update to 0.68
Summary of changes: b931949... update to 0.68 (*) (*) This commit already existed in another branch; no separate mail sent -- 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
Aw: Re: undefined reference to symbol 'gdk_pixbuf_save_to_buffer'
Gesendet: Freitag, 07. September 2012 um 11:35 Uhr Von: "Michael Schwendt" An: devel@lists.fedoraproject.org Betreff: Re: undefined reference to symbol 'gdk_pixbuf_save_to_buffer' On Fri, 7 Sep 2012 09:15:40 +0200 (CEST), Martin Gansser wrote: >> >> trying to build guayadeque on Fedora 18 Alpha, but this fails with the >> following error message: >> >> Linking CXX executable guayadeque >> [...] -o guayadeque -rdynamic -pthread -Wl,-z,relro -lwx_baseu-2.8 >> -lwx_gtk2u_core-2.8 -lwx_gtk2u_adv-2.8 -lwx_baseu_net-2.8 > -lwx_gtk2u_html-2.8 -lwx_baseu_xml-2.8 -lwx_gtk2u_aui-2.8 -lwx_gtk2u_qa-2.8 > -lgstreamer-0.10 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 > -lrt -lxml2 > -lglib-2.0 -lsqlite3 -lcurl -ltag -lFLAC -lm -ldbus-1 -lgio-2.0 -lgobject-2.0 > -lglib-2.0 -lgpod -lgmodule-2.0 > -lgthread-2.0 -lrt -lxml2 -lsqlite3 -lcurl -ltag -lFLAC -lm -ldbus-1 > -lgio-2.0 -lgpod >> /bin/ld: CMakeFiles/guayadeque.dir/iPodMedia.o: undefined reference to >> symbol 'gdk_pixbuf_save_to_buffer' >> /bin/ld: note: 'gdk_pixbuf_save_to_buffer' is defined in DSO >> /lib64/libgdk_pixbuf-2.0.so.0 so try adding it to the linker command line >> > > (!) > > Have you tried that suggestion? -lgdk_pixbuf-2.0.so is not in the linker > options above. hmm, the question is, in which file do i add the '-lgdk_pixbuf-2.0' linker option ? thanks Martin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Aw: Re: license question for bug review
Gesendet: Mittwoch, 05. September 2012 um 12:08 Uhr Von: "Milan Bartos" An: "Development discussions related to Fedora" Betreff: Re: license question for bug review A> I'am working on a bug review of uayadeque A> https://bugzilla.redhat.com/show_bug.cgi?id=853553 >> >> can someone give me a hint how to handle license type of files in the >> spec file. >> HMAC-SHA-224/256/384/512 implementation in src/hmac/hmac_sha2.c >> FIPS 180-2 SHA-224/256/384/512 implementation in src/hmac/sha2.c > > https://fedoraproject.org/wiki/Packaging/LicensingGuidelines#Multiple_Licensing_Scenarios[https://fedoraproject.org/wiki/Packaging > /LicensingGuidelines#Multiple_Licensing_Scenarios] ? > can't find the respondig part in the document. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: undefined reference to symbol 'gdk_pixbuf_save_to_buffer'
On Fri, 7 Sep 2012 15:51:04 +0200 (CEST), Martin Gansser wrote:
> hmm, the question is, in which file do i add the '-lgdk_pixbuf-2.0' linker
> option ?
> thanks
> Martin
The one that creates/links the main executable. ;)
For a clean fix, intimate familiarity with CMake may be necessary, but
this work-around would do, too:
diff -Nurb --strip-trailing-cr guayadeque-svn1830-orig/src/CMakeLists.txt
guayadeque-svn1830/src/CMakeLists.txt
--- guayadeque-svn1830-orig/src/CMakeLists.txt 2012-04-01 12:18:27.0
+0200
+++ guayadeque-svn1830/src/CMakeLists.txt 2012-09-07 16:55:47.509756245
+0200
@@ -303,6 +303,7 @@
${LIBINDICATE06_LIBRARIES}
${LIBINDICATE07_LIBRARIES}
${LIBAPPINDICATOR_LIBRARIES}
+-lgdk_pixbuf-2.0
)
INSTALL( TARGETS guayadeque
--
Fedora release 17 (Beefy Miracle) - Linux 3.5.3-1.fc17.x86_64
loadavg: 0.70 0.89 0.89
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Wed, 29.08.12 08:44, Jim Meyering (j...@meyering.net) wrote: > Jerry James wrote: > > I've got two Rawhide VMs, one x86_64, one i686, both otherwise > > identical. I last booted them yesterday and did a yum repo-sync. > > Today, neither of them will boot. > > > > First, systemd complained about being unable to find > > systemd-journal-flush.service. Sure enough, it wasn't in the > > initramfs. So I added > > "$systemdsystemunitdir/systemd-journal-flush.service" to > > /usr/lib/dracut/modules.d/98systemd/module-setup.sh, and regenerated > > the initramfs. Now the boot gets past that point, but starts doing > > this over and over, apparently forever, even in emergency mode: > > Thank you for posting about this, and to everyone who has been > working on http://bugzilla.redhat.com/847418. I hit the same bug > when my rawhide VM updated to the latest kernel, and you've saved > me the trouble of investigating. For now, I get by using the > preceding kernel. So this happened because somebody updated the Rawhide package, which disabled package inheritance from F18. I have now untagged the package in Rawhide again, and added a notice to the .spec file so that people don't go and blindly update the package in Rawhide, but instead just let inheritance between F18 and Rawhide do its work. Honestly, I think Fedora got the branches all backwards. Instead of carrying around master all the time we should just have the version branches and whenever somebody needs a new version branch he should just branch of the most recent one. Right now "master" is for many packages mostly dead territory between the time where a version got forked off (but is not yet released) and the time where people actually start working on the next distribution version. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Fri, Sep 07, 2012 at 18:30:10 +0200, Lennart Poettering wrote: On Wed, 29.08.12 08:44, Jim Meyering (j...@meyering.net) wrote: So this happened because somebody updated the Rawhide package, which disabled package inheritance from F18. I have now untagged the package in Rawhide again, and added a notice to the .spec file so that people don't go and blindly update the package in Rawhide, but instead just let inheritance between F18 and Rawhide do its work. That won't interact well with mass rebuilds. Honestly, I think Fedora got the branches all backwards. Instead of carrying around master all the time we should just have the version branches and whenever somebody needs a new version branch he should just branch of the most recent one. Right now "master" is for many packages mostly dead territory between the time where a version got forked off (but is not yet released) and the time where people actually start working on the next distribution version. I actually wish people would stop doing updates just for branched and not doing new rawhide builds. This is especially bad during freezes (and the current one has been very long), as rawhide doesn't inherit from updates-testing, so you don't automagicly get fixes. For now I have enabled updates-testing for 18 in addition to rawhide for my rawhide machine, in order to get a lot of the gnome related stuff. I think our policy is that you should do rawhide builds, but at least some significant groups of packagers actively don't do rawhide builds. If that is going to continue, we should consider having rawhide inherit from updates-testing. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Fri, Sep 7, 2012 at 11:51 AM, Bruno Wolff III wrote: > On Fri, Sep 07, 2012 at 18:30:10 +0200, > Lennart Poettering wrote: >> >> On Wed, 29.08.12 08:44, Jim Meyering (j...@meyering.net) wrote: >> >> So this happened because somebody updated the Rawhide package, which >> disabled package inheritance from F18. I have now untagged the package >> in Rawhide again, and added a notice to the .spec file so that people >> don't go and blindly update the package in Rawhide, but instead just let >> inheritance between F18 and Rawhide do its work. > > > That won't interact well with mass rebuilds. > >> Honestly, I think Fedora got the branches all backwards. Instead of >> carrying around master all the time we should just have the version >> branches and whenever somebody needs a new version branch he should just >> branch of the most recent one. Right now "master" is for many packages >> mostly dead territory between the time where a version got forked off >> (but is not yet released) and the time where people actually start >> working on the next distribution version. > > > I actually wish people would stop doing updates just for branched and not > doing new rawhide builds. This is especially bad during freezes (and the > current one has been very long), as rawhide doesn't inherit from > updates-testing, so you don't automagicly get fixes. For now I have enabled > updates-testing for 18 in addition to rawhide for my rawhide machine, in > order to get a lot of the gnome related stuff. > > I think our policy is that you should do rawhide builds, but at least some > significant groups of packagers actively don't do rawhide builds. If that is > going to continue, we should consider having rawhide inherit from > updates-testing. I personally always do, and advise it as well. It's not like it wastes space, rawhide gets pruned pretty aggressively. And it saves so much pain later. -J > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Fri, 7 Sep 2012 11:51:57 -0500 Bruno Wolff III wrote: ...snip... > I actually wish people would stop doing updates just for branched and > not doing new rawhide builds. This is especially bad during freezes > (and the current one has been very long), as rawhide doesn't inherit > from updates-testing, so you don't automagicly get fixes. For now I > have enabled updates-testing for 18 in addition to rawhide for my > rawhide machine, in order to get a lot of the gnome related stuff. > > I think our policy is that you should do rawhide builds, but at least > some significant groups of packagers actively don't do rawhide > builds. If that is going to continue, we should consider having > rawhide inherit from updates-testing. I'd like to propose the opposite: Lets drop any inheritance between branched and rawhide. Is it really that much trouble to commit/build in rawhide first? Thats where you should be doing your development anyhow. Then, only if all looks well, should you push to branched. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Fri, 07.09.12 11:00, Kevin Fenzi (ke...@scrye.com) wrote: > > I think our policy is that you should do rawhide builds, but at least > > some significant groups of packagers actively don't do rawhide > > builds. If that is going to continue, we should consider having > > rawhide inherit from updates-testing. > > I'd like to propose the opposite: > > Lets drop any inheritance between branched and rawhide. > > Is it really that much trouble to commit/build in rawhide first? Yes, it effectively doubles my Fedora workload. > Thats where you should be doing your development anyhow. Then, only if > all looks well, should you push to branched. Dude, I already have to look afer way too many distros at the same time. I see no point at all in developing two development distros simultaneously. As long as I don want my F18 and F19 version of packages diverge I see no point in doing everything twice. It sounds really bogus to me to develop to distros at the same time rather than just focussing on stabilizing one of them and let the other just get a copy of my packages. I mean, I don't really like doing packaging work that much. I do it because it is necessary, not because it is fun. You know what is even less fun? Doing everything twice if things could just as easily be inherited automatically. I really don't intend to spend my life on cherry picking things from one brnach into the other if computers can do that for me. Being a cherry-picking monkey sounds like a fantastic job description for a computer, but not really for a human, thank you very much. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Fri, Sep 07, 2012 at 11:00:07 -0600, Kevin Fenzi wrote: On Fri, 7 Sep 2012 11:51:57 -0500 I'd like to propose the opposite: Lets drop any inheritance between branched and rawhide. Will that really work as expected? The way we do branching has builds effectively move out of the rawhide branch. So that rawhide would end up not including packages that hadn't been rebuilt since the last branch event. Maybe if we coupled this with mass rebuilds just after branch along with a good job of fixing FTBFS, this could be made to work reasonably. But that's a lot of effort (and rawhide disruption during the branch) that I think we'd have trouble doing. If we want to get draconain about forcing rawhide builds (which I don't feel strongly about), then I think a better route would be enforcing rawhide versions being after any versions accepted by bohdi for a package. (There are complications here as well, but they are probably managable.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Fri, 07.09.12 11:51, Bruno Wolff III (br...@wolff.to) wrote: > On Fri, Sep 07, 2012 at 18:30:10 +0200, > Lennart Poettering wrote: > >On Wed, 29.08.12 08:44, Jim Meyering (j...@meyering.net) wrote: > > > >So this happened because somebody updated the Rawhide package, which > >disabled package inheritance from F18. I have now untagged the package > >in Rawhide again, and added a notice to the .spec file so that people > >don't go and blindly update the package in Rawhide, but instead just let > >inheritance between F18 and Rawhide do its work. > > That won't interact well with mass rebuilds. I think it would be a good idea to do those only if the previous distro has been finalized, so that people can focus on one devel distribution at a time... > I actually wish people would stop doing updates just for branched > and not doing new rawhide builds. This is especially bad during > freezes (and the current one has been very long), as rawhide doesn't > inherit from updates-testing, so you don't automagicly get fixes. > For now I have enabled updates-testing for 18 in addition to rawhide > for my rawhide machine, in order to get a lot of the gnome related > stuff. Maybe rawhide should inherit not only from the most recent distro but also by updates-testing? > I think our policy is that you should do rawhide builds, but at > least some significant groups of packagers actively don't do rawhide > builds. If that is going to continue, we should consider having > rawhide inherit from updates-testing. The latter: yes, please. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning 4 packages
I'm going to release ownership of 4 of my packages because I do not use them anymore for quite a while now. These are: bzr-explorer: The GUI frontend for the bzr version control system. Because the latest upstream version requires bzr 2.6, it is still on version 1.2.2 in Fedora. Updating to new upstream versions is usually very simple. kde-plasma-daisy: This is a Plasma applet that provides a circular and dock launcher for applications. The latest upstream version is packaged in Rawhide. knights: A chess board for KDE with support for gnuchess and online games. Already ported to the new KDEgames API, and the latest upstream version is in Rawhide. sap: This is a console audio player. Upstream didn't do anything since almost two years now. The software uses Vala and has a couple of problems that never got ironed out. Regards, Julian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning 4 packages
On Fri, Sep 7, 2012 at 12:58 PM, Julian Aloofi wrote: > I'm going to release ownership of 4 of my packages because I do not use > them anymore for quite a while now. > These are: > > bzr-explorer: The GUI frontend for the bzr version control system. > Because the latest upstream version requires bzr 2.6, it is still on > version 1.2.2 in Fedora. Updating to new upstream versions is usually > very simple. > > kde-plasma-daisy: This is a Plasma applet that provides a circular and > dock launcher for applications. The latest upstream version is packaged > in Rawhide. > > knights: A chess board for KDE with support for gnuchess and online > games. Already ported to the new KDEgames API, and the latest upstream > version is in Rawhide. I've taken this, co-maintainers welcome. Thanks for your work! -J > sap: This is a console audio player. Upstream didn't do anything since > almost two years now. The software uses Vala and has a couple of > problems that never got ironed out. > > Regards, > Julian > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Network configuration future
On Mon, 2012-09-03 at 09:44 +0200, Olaf Kirch wrote: > Hi Miloslav, > > On Wednesday 29 August 2012 18:42:44 Miloslav Trmač wrote: > > Considering that it's not reasonable to expect that the replacement > > will cover 100% of the previous functionality, the "old" and "new" > > projects will have to live side by side again for some time. So a > > switch to a different system needs to provide benefits that exceed the > > quite large costs of the migration. > > > > Therefore, in general, I'd assume that modifying NetworkManager (in a > > backward-compatible way) is probably an easier way to add features > > than replacing the whole subsystem with something else. > > Hm, I beg to differ here. NetworkManager aims at a relatively compact > DBus API that hides most of the complexities of the network stack. > That, I believe, is one of the major reasons why it hasn't caught on > much in an Enterprise world - there's always one little extra knob an > admin wants to twiddle. NM tries to hide things where it makes sense; there's a *lot* of stuff that is simply unnecessary for clients to care about while handling networking. But there's a lot of stuff administrators and clients also want to change, and we're moving pretty quickly in that direction already. There are a lot more knobs in NM than people realize. > By contrast, I think a good network management framework needs to > have a low entry barrier (in terms of writing configuration files) > but still expose as many of the tunables and knobs as possible. And that pretty much describes how NM works today too; it'll handle your existing network configuration, but still does expose a lot of tunables in the configuration. But you have to ask whether those knobs are actually required. Knobs fall into one of three classes: 1) useful ones, like IPv6 privacy settings, IPv6 on/off, etc 2) dubious ones, where the kernel or low-level implementation just tries to avoid hard choices and decides to give up 3) workarounds for broken hardware or kernel drivers We've tried really hard over the past 6 or so years to *not* expose knobs that allow people to work around broken kernel stuff or hardware, and instead *fix* the kernel to do the right thing instead of expecting users to know which knob to twiddle to get the right result. Examples of this include SSID scanning in wifi drivers and carrier detection capability in wired drivers. Nobody should ever have to know whether their driver supports a specific feature or not and then set some option because of that; instead we need to fix this sort of thing in the kernel and then handle it automatically. My point is, not all knobs are worth exposing, and some knobs shouldn't be exposed, but should get fixed so they don't need to be exposed in the first place. It's hard, but it makes life better. Next, you need to analyze *why* a particular knob is requested. Is there a better way to do that? I've often found people want a checkbox for this or that, when there's actually a much better way to fix the problem for the user. Sometimes there's not and you just add the knob. But often there is. Adding knobs left and right often (a) increases complexity and therefore confusion, and (b) creates code that's really hard to maintain and document. > > Now, with my once-upon-a-time sysadmin and initscripts comaintainer hat on: > > > > Yes, it is possible to design a better configuration format than the > > ifcfg files, but I'm not sure that this is a really pressing problem: > > the primary problem with networking is understanding the concepts and > > designing the desired state, not the configuration format - once you > > know what you want to do, you can always find the > > HOPELESSLY_UNINTUITIVE_OPTION_NAME (or even > > nicely-scoped/well-designed-option-name-that-you-need-to-write-precisely-co > > rrectly-to-the-letter) in documentation. > > Sure, I'm not talking about the syntax. As I said, I couldn't care > less if its XML or anything else. My point was that the shell variable > syntax is unable to express anything but the most basic concepts, > and hence our network management remains simplistic. It actually works pretty well for most things, we've found. We have gone through rounds of trying to figure out better formats, but it turns out that for the most part, the ifcfg format is: 1) widely used and thus well-understood 2) compatible with a huge number of existing tools 3) easily machine-parsible (except for embedding shell inside the variables, ie backticks or whatever) 4) simple and fairly flexible If you treat the file as a simple key/value file, and disallow using actual shell macros or expansion, then it's actually pretty suitable. And nothing else anyone has come up with is actually so much better that it's worth the cost to switch. I came up with the NetworkManager "keyfile" format, and it's not hugely better, just cross-platform. But ifcfg will live a long, long time. > > In addition to a different co
Re: Rawhide boot problems
On Fri, 7 Sep 2012 19:16:39 +0200 Lennart Poettering wrote: > On Fri, 07.09.12 11:00, Kevin Fenzi (ke...@scrye.com) wrote: > > > > I think our policy is that you should do rawhide builds, but at > > > least some significant groups of packagers actively don't do > > > rawhide builds. If that is going to continue, we should consider > > > having rawhide inherit from updates-testing. > > > > I'd like to propose the opposite: > > > > Lets drop any inheritance between branched and rawhide. > > > > Is it really that much trouble to commit/build in rawhide first? > > Yes, it effectively doubles my Fedora workload. I don't think it doubles it. I agree it increases it some, but it also adds a layer of smoketesting and doublechecking, so IMHO it's worth it. > > Thats where you should be doing your development anyhow. Then, only > > if all looks well, should you push to branched. > > Dude, I already have to look afer way too many distros at the same > time. I see no point at all in developing two development distros > simultaneously. As long as I don want my F18 and F19 version of > packages diverge I see no point in doing everything twice. But f18 and f19 _are_ diverging behind your package. Some of the time you might not notice, but it's happening. > It sounds really bogus to me to develop to distros at the same time > rather than just focussing on stabilizing one of them and let the > other just get a copy of my packages. Think of rawhide as not another distro, but another packageset/check. > I mean, I don't really like doing packaging work that much. I do it > because it is necessary, not because it is fun. You know what is even > less fun? Doing everything twice if things could just as easily be > inherited automatically. Perhaps you could try and find some package maintainers to do that work for you while you work on upstream issues? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Network configuration future
On Mon, 2012-09-03 at 09:20 +0200, Olaf Kirch wrote: > On Friday 31 August 2012 02:47:38 Bill Nottingham wrote: > > I'm not saying you *can't* do it, but it's also not something to do > > lightly. > > Totally agreed. But what are really the points of maximum stickiness? > Obviously, configuration files and command line interfaces. > > So, for a new network management framework, this means > > -using ifconfig/route should continue to work (ie the service > shouldn't touch interfaces unless told so) Touching an interface depends on your use-cases. For many cases it should be automatically managed without any intervention from the user, and in many other cases, that should be under the control of the administrator. It's definitely not an either/or choice. > -there should be ifup/ifdown scripts that offer the same > semantics as the current ones, as far as possible. Yes; we've modified the ifup/ifdown scripts to handle interaction with NetworkManager. > -there should be a way to parse old-style ifcfg files Yes; obviously anything that handles network management on Fedora needs to do this. Dan > Could you think of any other? > > Olaf > -- > Neo didn't bring down the Matrix. SOA did. (soafacts.com) > > Olaf Kirch - Director SUSE Linux Enterprise; R&D (o...@suse.com) > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-File-Path-Tiny/el6] (8 commits) ...update to 0.5
Summary of changes: 52ec456... - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass (*) c93ed6f... Perl mass rebuild (*) a4f9fb6... - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass (*) 6b30f5e... update to 0.2 (*) 86bff38... update to 0.3 (*) 343ab90... Perl 5.16 rebuild (*) e9fb322... - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass (*) cd106e3... update to 0.5 (*) (*) This commit already existed in another branch; no separate mail sent -- 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
libfreebob breakage in Fedora 18 koji!
DEBUG util.py:257: Error: Package: jack-audio-connection-kit-1.9.8-10.fc18.x86_64 (build) DEBUG util.py:257: Requires: libfreebob.so.0()(64bit) :-( This is unacceptable! Please avoid breaking the koji buildroot like this. You could have rebuilt jack-audio-connection-kit prior to removing the required libfreebob! [...] http://lists.fedoraproject.org/pipermail/scm-commits/2012-September/854680.html [libfreebob/f18] Package obsoleted in favor of libffado [jack-audio-connection-kit] Removed libfreebob dependency as this package is retired -> https://admin.fedoraproject.org/updates/FEDORA-2012-13308/jack-audio-connection-kit-1.9.8-11.fc18 -> in updates-testing only -- Fedora release 17 (Beefy Miracle) - Linux 3.5.3-1.fc17.x86_64 loadavg: 0.40 0.17 0.12 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Lingua-EN-Inflect-Phrase-0.13.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-Lingua-EN-Inflect-Phrase: 4df51c5a21935393dc054280ee416663 Lingua-EN-Inflect-Phrase-0.13.tar.gz -- 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: Network configuration future
On Thu, 2012-08-30 at 13:23 +0200, Dennis Jacobfeuerborn wrote: > On 08/30/2012 08:55 AM, Bill Nottingham wrote: > > Bill Nottingham (nott...@redhat.com) said: > >> Olaf Kirch (o...@suse.de) said: > >>> On Wednesday 29 August 2012 21:56:45 Jóhann B. Guðmundsson wrote: > On 08/29/2012 11:58 AM, Olaf Kirch wrote: > > Your feedback is very much welcome! > > The network management/solution of the future most likely ( at least > will need to ) be something that is integrated into ( or with ) > systemd/Core OS > >>> > >>> Indeed, and that's where I'd like to go. Which is one of the reasons > >>> for choosing dbus as the transport. > >> > >> The systemd people do have some ideas they've already been kicking around > >> for this already... have you seen it? > > > > To be clear, I'm not really convinced yet that this is something we need... > > there is a lot of legacy admin overhead and infrastructure that is highly > > resistant to change here. > > Speaking as an admin I think something needs to happen here. The current > shell script/NetworkManager chimera is really ugly since they don't > cooperate well I really wished things would go one way or the other or > someone would come up with something that replaces both but I consider the > current situation as a worst case scenario. We're working on that in the NM space, with management modes in between "unmanaged" and "fully managed". For whatever reason, we'll never be in a position where one or the other solution "wins", so we'll have to figure out ways to coexist. And obviously the goal is to get better than the current situation. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Network configuration future
On Mon, 2012-09-03 at 09:20 +0200, Olaf Kirch wrote: > Hi Stephen, > > On Wednesday 29 August 2012 19:48:29 Stephen Gallagher wrote: > > Olaf, I'm very interested to learn more about wicked. Can you perhaps > > itemize the set of features available to wicked (current as well as > > in-development) that aren't available (or maybe "accessible) in Network > > Manager? > > Hm, let me see - this is going to be a bit tough :) > > Currently, wicked supports wired Ethernet, VLANs, bridges, bonds, wireless > (no EAP mode yet, though), openvpn, and to some degree GSM modems. For > most of these, the set of properties accessible exceeds those of > NetworkManager by far. Can you describe in what way it exceeds? > In terms of address configuration, it supports dhcp4 and dhcp6, as well as > IPv4 zeroconf (in addition to static and ipv6 autoconf). You can mix addrconf > modes (eg configure a NIC with DHCPv4 plus two static routes). Seems comparable to NM here. > The layered approach tries to decouple the settings of each layer. For > instance, you can take down the DHCPv6 agent and bring up the DHCPv4 > agent on an interface without having to cycle it completely. Same for > adding a bridge port, or removing one NIC from a bond, or for changing > the offload parameters on an Eth device. Interesting; something we're also looking at (at least at lower levels) for NetworkManager, but it also makes it hard to implement a connection-oriented architecture. NM has had decoupled IPv6 and IPv4 for quite a while now too, actually. dan > > I'm involved in a project that's aiming to improve central management of > > networking and having a comprehensive network stack wrapped in a D-BUS > > API sounds almost too good to be true from that perspective. A CIM > > wrapper around such an API could go a long way in that direction. > > Yes, I had been thinking of something like this as well. > > > Do you have a D-BUS API specification available somewhere in a readable > > form? That would be very helpful. > > Hm, not "readable" in the sense of nice HTML. There's a schema definition > in the source code which hopefully goes a long way to give you an idea of > how it works. > > Olaf > -- > Neo didn't bring down the Matrix. SOA did. (soafacts.com) > > Olaf Kirch - Director SUSE Linux Enterprise; R&D (o...@suse.com) > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Lingua-EN-Inflect-Phrase] update to 0.13
commit 55a7c4d2d2bf62ae4e202df60c4fc3c289dfefd2
Author: Iain Arnell
Date: Fri Sep 7 12:20:22 2012 -0600
update to 0.13
.gitignore |1 +
perl-Lingua-EN-Inflect-Phrase.spec | 11 +++
sources|2 +-
3 files changed, 9 insertions(+), 5 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 5c44f1e..4a284f9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -3,3 +3,4 @@
/Lingua-EN-Inflect-Phrase-0.10.tar.gz
/Lingua-EN-Inflect-Phrase-0.11.tar.gz
/Lingua-EN-Inflect-Phrase-0.12.tar.gz
+/Lingua-EN-Inflect-Phrase-0.13.tar.gz
diff --git a/perl-Lingua-EN-Inflect-Phrase.spec
b/perl-Lingua-EN-Inflect-Phrase.spec
index 6cb3ec5..eb8b1d5 100644
--- a/perl-Lingua-EN-Inflect-Phrase.spec
+++ b/perl-Lingua-EN-Inflect-Phrase.spec
@@ -1,6 +1,6 @@
Name: perl-Lingua-EN-Inflect-Phrase
-Version:0.12
-Release:3%{?dist}
+Version:0.13
+Release:1%{?dist}
Summary:Inflect short English Phrases
License:GPL+ or Artistic
Group: Development/Libraries
@@ -10,7 +10,7 @@ BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Lingua::EN::Inflect) >= 1.891
BuildRequires: perl(Lingua::EN::Inflect::Number) >= 1.1
-BuildRequires: perl(Lingua::EN::Tagger) >= 0.15
+BuildRequires: perl(Lingua::EN::Tagger) >= 0.20
BuildRequires: perl(Test::More) >= 0.94
Requires: perl(Lingua::EN::Inflect) >= 1.891
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
@@ -24,7 +24,7 @@ Attempts to pluralize or singularize short English phrases.
%setup -q -n Lingua-EN-Inflect-Phrase-%{version}
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+%{__perl} Makefile.PL INSTALLDIRS=vendor --skipdeps
make %{?_smp_mflags}
%install
@@ -44,6 +44,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Fri Sep 07 2012 Iain Arnell 0.13-1
+- update to latest upstream version
+
* Fri Jul 20 2012 Fedora Release Engineering
- 0.12-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
diff --git a/sources b/sources
index 4f87723..38ef34d 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-7738cb83d99466056e9aeb519add2ba7 Lingua-EN-Inflect-Phrase-0.12.tar.gz
+4df51c5a21935393dc054280ee416663 Lingua-EN-Inflect-Phrase-0.13.tar.gz
--
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: Network configuration future
On Thu, 2012-08-30 at 07:44 +0200, Olaf Kirch wrote: > Hi Adam, > > On Thursday 30 August 2012 04:16:23 Adam Williamson wrote: > > > *** Network Manager is just another daemon created for a task > > > which historically often did not need any daemons. It's almost as if > > > the new generation of Unix hackers wants to redo everything - > > > in x10 or x100 times bloated and more complex way than it was done > > > before. > > > > > > - > > > One, a modern network management framework should run as a service. > > > The > > > kernel offers a plethora of notifications via rtnetlink, and > > > increasingly > > > expects user space to react to these (for instance in the IPv6 area). > > > Running a network management daemon allows us to track the state, > > > detect > > > changes, and react to them appropriately. > > > > There appears to be some cognitive dissonance in the document. It seems > > odd to criticize NetworkManager solely for being a bloated, complex > > daemon, and then, having dismissed NM, in describing the ideal > > next-generation network management framework, declare that it ought to > > be a bloated complex daemon... > > That dissonance is explained easily. Only the second section you quote was > written by me, the other is a comment from Denis Vlasenko, actually :-) > > And no, I'm not criticizing NetworkManager for being bloated. My main > criticism of NetworkManager is that it's very much focused on managing > desktop machines, and it's not flexible and extensible enough to make it > handle server scenarios, much less vhost setups. It is also hard to make it > coexist peacefully with other network management on the system - if you > start NetworkManager, it tends to take possession of all interfaces > it finds (and understands). That's NM's heritage, but that's certainly not its focus. We're actually focusing a *lot* more on enterprise use-cases these days, including lots of knobs that admins like to turn. The main coexistence problems center around two things: DNS and the default route. In *any* system you need one thing to manage these, because they are a shared resource. Which interface gets default route priority? Which interface's DNS servers get priority? If the thing that manages these doesn't have the full information available to it, like the user preferences for these options, then you'll end up not making the right choices. The thing that manages these must have information about *all* interfaces. *That's* the problem with multiple competing network management systems. If it weren't for this, they'd all be just fine managing the individual interfaces they were told to manage. But unfortunately the default route and DNS are somewhat crucial to networking... NM has historically attempted to manage both of these, because it had a lot of information. And that creates some problems. We're working on ways to mitigate this issue, but it's not a problem that's easily solved when some people like to use one system, and other people like to use another system. And adding another layer of abstraction to the system to mitigate between network management systems doesn't help a lot either :( Dan > And no, I'm not advocating a bloated daemon either. Network management > has to fit into initrd and possibly small-footprint images. Currently, > wickedd, its library and the dhcp4/dhcp6 helpers fit into a little over > 1 MB. > > By contrast, the ISC dhlient comes in at 1.6MB on my system already. > > Regards, > Olaf > -- > Neo didn't bring down the Matrix. SOA did. (soafacts.com) > > Olaf Kirch - Director SUSE Linux Enterprise; R&D (o...@suse.com) > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Network configuration future
On Wed, 2012-08-29 at 16:48 +0100, Steven Whitehouse wrote: > Hi, > > I wonder if one way to deal with the network configuration issue is to > try and help different configuration systems work with each other, > rather than to try and create one system which does everything. Last > time I looked into this there were various things which could be done to > allow peaceful coexistence of various configuration tools, but which > were missing. Obviously we can add a couple of abstraction layers to avoid making hard choices and continue to funnel effort into multiple competing projects. That provides choice, but also increases complexity and the number of gaps that things fall through and that problems are caused by. > One of these is related to routing. Routes can be tagged with an > originator protocol (/etc/iproute2/rt_protos) with the default being > "kernel" for routes which are generated automatically, say on interface > being brought up. This means that utilities which do some form of > dynamic routing (and I include NetworkManager, dhcp clients, etc in > this) should only remove or change routes which are either marked > "kernel" or which are marked with their own protocol id. I brought this > issue up some time ago (I did look for a reference but didn't find one > immediately), but without seeing much enthusiasm for resolving it. I think mainly becuase it's orthogonal to the problem. NM already doesn't touch routes on interfaces it doesn't manage The real problem is the *default* route, and that's a shared resource. Tagging doesn't help here because only one thing (whatever that is) really should be handling the default route, precisely because it's a shared resource. It wouldn't be nice to create a higher priority default route than the one created by tool A, just like it wouldn't be nice for tool A to create a higher priority default route than that created by tool B. How do you mediate between them? We attempted to make NetworkManager that thing, but obviously that's incomplete since it doesn't have knowledge of all the interface on the system in some cases. But the thing that handles the default route and DNS priority *does* need to have a pretty good knowledge of all interfaces on the system, and their relative priority. Dan > My point is not so much that this particular issue should be fixed (and > maybe it has been since it is a while since I last checked) but that by > careful use of the available functions (and maybe with the odd extension > here and there) it should be possible to allow many different tools to > cooperate with each other. I'm just using the route issue as an example. > > Obviously there needs to be some coordination when it comes to dealing > with an interface coming up and which particular tool will deal with the > set up, but there is still scope for allowing multiple tools to > cooperate too. That way we can have specialist tools to deal with the > less common situations without needing to clutter up those tools dealing > with the more common case with more advanced features. > > So my take on the problem is to consider how it would be possible to > have different tools cooperating in the same space, and then maybe to > extract the common functions which allow this into a small library which > could then be used by each tool. > > I'm not sure if this is useful in the context of the original post, but > it is what it brought to mind while I was reading it, > > Steve. > > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Network configuration future
On Wed, 2012-08-29 at 15:17 +0200, Denys Vlasenko wrote: > On 08/29/2012 01:58 PM, Olaf Kirch wrote: > > Your feedback is very much welcome! > > > > Regards, > > Olaf > > Why Did You Do This?! > > Do we really need yet another network management thing? > === > > No, not really. We already have the good old ifup/ifdown scripts, which > are doing their job nicely. > > *** No they don't. > > > If you don't strain them too much or try to > teach them new tricks (like integrating with systemd). Of all the > tunables and knobs the kernel supports for each network interface, we're > covering maybe 10%, but what was good enough for grandpa should be > good enough for me as well, right? > > We've got udev messing around with network interface names, because > users don't like it when what's called eth0 today is called eth15 > on the next boot. Which works nicely except when it fails, for one > or the other weird reason. > > We've got Network Manager, which is also doing it's job nicely and won't > give you any headaches if you prevent it from stepping on anybody else's > toes. Or try to make it manage a thousand devices, like on System z. > > *** Network Manager is just another daemon created for a task > which historically often did not need any daemons. It's almost as if > the new generation of Unix hackers wants to redo everything - > in x10 or x100 times bloated and more complex way than it was done > before. Yes, guys, old stuff has problems and limitations. But > switching into high gear and writing a ton of stuff is not a solution > I like. Can you *think it through* and fix/improve stuff WITHOUT > increasing its complexity tenfold as a minimum? Yes, I do realize > that elegant solution is harder to do than coding spree solution, > but I still hope... Historically it didn't require daemons, but these days networking is a lot more complex, and people often run multiple interfaces, and something gets to mediate between multiple interfaces. I often argue that the *old* system of a ton of shellscripts and many different processes (dhcp, ppp, vpn, wpa_supplicant, ipsec, etc) all doing their own thing and being loosely tied together via a bunch of cobbled-together shellscripts is *more* complex, because: 1) error handling and reporting is very hard to get right in shell 2) there's about 10x more cracks for things to fall through and problems to occur in a loosely tied together system like this 3) each tool has it's own configuration format and it's own command/control format, and none of these are anything like the others 4) handling events from these tools often requires a daemon-type process anyway 5) half or more of the effort goes into making all these tools work together and talk reliably and to provide a consistent interface on top of all of them, instead of actually making the networking system better There's no reason *why* a system like NetworkManager should be as complex as you think it is, and I'd argue that it's not. Certianly not 10x as complex as the old system. I'm not acutally sure what a "more elegant" setup that you envision would be; any chance you can share some thoughts? Dan > > Then we've got libvirt and netcf, which do kind of an okay job if you > manage to frob netcf enough that it deals with configuration files other > than RedHat's, and as long as your network configuration doesn't get too > complicated. Which happens quickly in a virtualization environment. > > Beyond these, there are things like openvswitch, which is crucial in > a cloud environment but not at all integrated with any of the other > components. > > So no, we don't really need yet another network management thingy. > > We need a management thingy that replaces a lot of this stuff. > > > > Yeah, but it kind of works, why should we mess with it > == > > Quick, using any of the existing frameworks, can you tell me how to... > > - ... disable IPv6 on a specific interface? > - ... set up an interface for DHCPv4 and DHCPv6? > - ... change the link speed on an Ethernet interface? > - ... reconfigure a bonding device without bringing it down? > - ... set up a bridge using two bonded NICs as one of its ports? > - ... the same as above, with VLAN tagging? > - ... change the firewall rules on your UMTS modem? > - ... set up 802.1x authentication for your Ethernet NIC? > - ... set up persistent names for your System z devices? > > If you could answer all of them at the snap of a finger, please send me your > CV. > > *** I would rather send you a few URLs: > > http://busybox.net/~vda/no_ifup.txt > http://git.busybox.net/busybox/tree/examples/var_service/README > > > > So, what properties should a new network management framework have? > === > > Obviously, there are a number of aspects of the existing systems tha
File Mouse-1.02.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-Mouse: bc84af3461b16e631a000fe979b3ce2a Mouse-1.02.tar.gz -- 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
[perl-Mouse] update to 1.02
commit cb4f628e1baedf498662a618ddb7fc0a66d10f21
Author: Iain Arnell
Date: Fri Sep 7 12:37:32 2012 -0600
update to 1.02
.gitignore |1 +
perl-Mouse.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 3688d28..42bfccc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@ Mouse-0.58.tar.gz
/Mouse-0.97.tar.gz
/Mouse-0.99.tar.gz
/Mouse-1.01.tar.gz
+/Mouse-1.02.tar.gz
diff --git a/perl-Mouse.spec b/perl-Mouse.spec
index 253eb04..f84bbbf 100644
--- a/perl-Mouse.spec
+++ b/perl-Mouse.spec
@@ -1,6 +1,6 @@
Name: perl-Mouse
Summary:Moose minus the antlers
-Version:1.01
+Version:1.02
Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
@@ -96,6 +96,9 @@ make test
%{_mandir}/man3/Test::Mouse*
%changelog
+* Fri Sep 07 2012 Iain Arnell 1.02-1
+- update to latest upstream version
+
* Sun Aug 26 2012 Iain Arnell 1.01-1
- update to latest upstream version
diff --git a/sources b/sources
index 5a46aaa..e8b34c9 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-c5aa69756abbd09732c43d95a792035e Mouse-1.01.tar.gz
+bc84af3461b16e631a000fe979b3ce2a Mouse-1.02.tar.gz
--
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: libfreebob breakage in Fedora 18 koji!
On Fri, 7 Sep 2012 20:06:36 +0200, Michael Schwendt wrote: > -> > https://admin.fedoraproject.org/updates/FEDORA-2012-13308/jack-audio-connection-kit-1.9.8-11.fc18 > -> in updates-testing only I've requested a buildroot override for this one as a temporary fix: $ koji wait-repo --target f18 --build jack-audio-connection-kit-1.9.8-11.fc18 Successfully waited 18:13 for jack-audio-connection-kit-1.9.8-11.fc18 to appear in the f18-build repo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Fri, 07.09.12 12:03, Kevin Fenzi (ke...@scrye.com) wrote: > On Fri, 7 Sep 2012 19:16:39 +0200 > Lennart Poettering wrote: > > > On Fri, 07.09.12 11:00, Kevin Fenzi (ke...@scrye.com) wrote: > > > > > > I think our policy is that you should do rawhide builds, but at > > > > least some significant groups of packagers actively don't do > > > > rawhide builds. If that is going to continue, we should consider > > > > having rawhide inherit from updates-testing. > > > > > > I'd like to propose the opposite: > > > > > > Lets drop any inheritance between branched and rawhide. > > > > > > Is it really that much trouble to commit/build in rawhide first? > > > > Yes, it effectively doubles my Fedora workload. > > I don't think it doubles it. I agree it increases it some, but it also > adds a layer of smoketesting and doublechecking, so IMHO it's worth > it. Humm. I don't agree with this. As long as F18 is unreleased Rawhide will be basically untested and I also wonder what testing it at this point would bring, given that it right now is mostly F18 and very far from F19, so why not test the real F18 where we need all testing focussed anyway? Committing this twice brings no benefit really, just doubles the work necessary. > > > > Thats where you should be doing your development anyhow. Then, only > > > if all looks well, should you push to branched. > > > > Dude, I already have to look afer way too many distros at the same > > time. I see no point at all in developing two development distros > > simultaneously. As long as I don want my F18 and F19 version of > > packages diverge I see no point in doing everything twice. > > But f18 and f19 _are_ diverging behind your package. Some of the time > you might not notice, but it's happening. Well, eventually they will, but I think it would be good to do that as late as possible so that people can focus on F18 to give it the detail love it needs. > > It sounds really bogus to me to develop to distros at the same time > > rather than just focussing on stabilizing one of them and let the > > other just get a copy of my packages. > > Think of rawhide as not another distro, but another packageset/check. Tests/checks are automized. Cherrypicking/commiting/building things twice is not automized. Tests are automated checks which help finding mistakes in what humans do. Making the human commit/build everything twice is just a way to increase the chance that mistakes are made because humans suck at doing repetitive tasks in comparison to computers which excel at it. > > I mean, I don't really like doing packaging work that much. I do it > > because it is necessary, not because it is fun. You know what is even > > less fun? Doing everything twice if things could just as easily be > > inherited automatically. > > Perhaps you could try and find some package maintainers to do that work > for you while you work on upstream issues? We already have multiple commiters to the packages. But that doesn't change the fact that you shouldn't throw people at a problem that should be solved with a computer. It's a simple fact that we have too little people working on Free Software, and computers are much better at this specific task than people, so it should be computers doing the job, not humans. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Announcing 389 Directory Server version 1.2.11.14 Testing
The 389 Project team is pleased to announce the release of 389-ds-base-1.2.11.14 for Testing. This release fixes a bug with CLEANALLRUV and winsync, and a race condition in the replication consumer extop code. The new packages and versions are: 389-ds-base 1.2.11.14 NOTE: 1.2.11 will not be available for Fedora 16 or earlier, nor for EL6 or earlier - 1.2.11 will only be available for Fedora 17 and later. We are trying to stabilize current, stable releases - upgrades to 1.2.11 will disrupt stability. Installation yum install 389-ds --enablerepo=updates-testing # or for EPEL yum install 389-ds --enablerepo=epel-testing setup-ds-admin.pl Upgrade yum upgrade 389-ds-base --enablerepo=updates-testing # or for EPEL yum upgrade 389-ds-base --enablerepo=epel-testing setup-ds-admin.pl -u How to Give Feedback The best way to provide feedback is via the Fedora Update system. Go to https://admin.fedoraproject.org/updates In the Search box in the upper right hand corner, type in the name of the package In the list, find the version and release you are using (if you're not sure, use rpm -qi on your system) and click on the release On the page for the update, scroll down to "Add a comment" and provide your input Or just send us an email to 389-us...@lists.fedoraproject.org Reporting Bugs If you find a bug, or would like to see a new feature, use the 389 Trac - https://fedorahosted.org/389 More Information * Release Notes - http://port389.org/wiki/Release_Notes * Install_Guide - http://port389.org/wiki/Install_Guide * Download - http://port389.org/wiki/Download ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Network configuration future
On Mon, 2012-09-03 at 09:20 +0200, Olaf Kirch wrote: > On Thursday 30 August 2012 08:55:02 Bill Nottingham wrote: > > > The systemd people do have some ideas they've already been kicking around > > > for this already... have you seen it? > > > > To be clear, I'm not really convinced yet that this is something we need... > > there is a lot of legacy admin overhead and infrastructure that is highly > > resistant to change here. > > Agreed. On the other hand, with systemd comes a lot of change anyway. > And obviously, something like wicked doesn't have to be completely disruptive. > The idea is to still have ifup/ifdown scripts for those who have been > using them, and have written their scripts around those. Or to be able > to parse the old ifcfg-* files for backward compatibility. The problem with integrating network management into systemd in some form is that system only wants to handle the "simple" use-cases. Mainly because it's intended to be a lightweight part of the boot process. But when you start handling any "simple" networking, you'll eventually start handling more complex networking too, because users will request it. And then at some point, you're duplicating all the code that a more complex network management daemon is already doing, and that makes things more confusing for everyone. Is this interface managed by systemd? Or is this interface managed by NM/something-else? Or is this interface manually managed? Should you even have to make this choice? What mediates the routing table and the DNS entries if you have systemd managing some interfaces, NM some other interfaces, and manually managed interfaces too? Another daemon? Yay! Piles of daemons! And since this is Linux, everyone wants to use each thing in isolation from the others, so you can't depend on anything else being on the system. Talking about low-level networking in systemd or whatever flavor-of-the-year initsystem there happens to be necessarily brings up questions like this. I'm not sure the right place for this sort of thing is in the init system. Instead, we should be creating a lightweight-enough network management daemon that could be included on these resource-constrained systems along with systemd to do that. Which is also something we're working towards with NetworkManager. It's actually been possible for a long time to build/run NM without any of [wpa-supplicant, ppp, ConsoleKit, PolicyKit, bluez, etc] if you want a stripped-down system. Dan > Olaf > -- > Neo didn't bring down the Matrix. SOA did. (soafacts.com) > > Olaf Kirch - Director SUSE Linux Enterprise; R&D (o...@suse.com) > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Network configuration future
On Fri, Sep 07, 2012 at 13:23:37 -0500, Dan Williams wrote: That's NM's heritage, but that's certainly not its focus. We're actually focusing a *lot* more on enterprise use-cases these days, including lots of knobs that admins like to turn. Is there a good source of documentation for these knobs? About a month ago I was looking for a way to force specific settings in /etc/resolv.conf when making wireless connections (to use a local caching resolver and a fixed domain search list), and just happened to find that NM used dhclient-$ifname.conf instead of dhclient.conf (somewhere other than a documentation page found using google). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Aw: Re: undefined reference to symbol 'gdk_pixbuf_save_to_buffer'
Gesendet: Freitag, 07. September 2012 um 17:03 Uhr
Von: "Michael Schwendt"
An: devel@lists.fedoraproject.org
Betreff: Re: undefined reference to symbol 'gdk_pixbuf_save_to_buffer'
> On Fri, 7 Sep 2012 15:51:04 +0200 (CEST), Martin Gansser wrote:
>
>> hmm, the question is, in which file do i add the '-lgdk_pixbuf-2.0' linker
>> option ?
>> thanks
>> Martin
>
> The one that creates/links the main executable. ;)
> For a clean fix, intimate familiarity with CMake may be necessary, but
> this work-around would do, too:
>
> diff -Nurb --strip-trailing-cr guayadeque-svn1830-orig/src/CMakeLists.txt
> guayadeque-svn1830/src/CMakeLists.txt
> --- guayadeque-svn1830-orig/src/CMakeLists.txt2012-04-01
> 12:18:27.0 +0200
> +++ guayadeque-svn1830/src/CMakeLists.txt 2012-09-07 16:55:47.509756245
> +0200
> @@ -303,6 +303,7 @@
> ${LIBINDICATE06_LIBRARIES}
> ${LIBINDICATE07_LIBRARIES}
> ${LIBAPPINDICATOR_LIBRARIES}
> + -lgdk_pixbuf-2.0
> )
>
> INSTALL( TARGETS guayadeque
>
thanks, works for me.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On 09/07/2012 06:54 PM, Jesse Keating wrote: On 09/07/2012 11:48 AM, Lennart Poettering wrote: Humm. I don't agree with this. As long as F18 is unreleased Rawhide will be basically untested and I also wonder what testing it at this point would bring, given that it right now is mostly F18 and very far from F19, so why not test the real F18 where we need all testing focussed anyway? Fedora 18 is basically closed for new feature work, and instead the focus needs to be on integration of the existing feature set and bugfixes. But as you state there is a large amount of time before F18 releases, which means new feature work would have to stall out for months. Instead, new feature work can begin for F19 and get ahead of the game. That's why F18 and F19 are divergent. That's why we went from a single line of development to two. As you know we ( QA Community ) want all the testing to be focused on the release we are about to push out the door and we would like ( and some expect ) that maintainers are keeping the same focus and give what time they have to address the bugs we find in the process as Lennart has correctly pointed out. Now that to me the begs the question with our short release cycles do we have any numbers on how many maintainers have the time to be working on both and are those maintainers that do have that time actually taking advantage of the current model in place? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
upstream wants me to rename my package
Hello, I am working on a package called VirtualGL: https://bugzilla.redhat.com/show_bug.cgi?id=834127 After contacting the upstream on their mailing list, they seem obsessed with being able to install their own rprms and my package together at the same time. This seems odd / bad to me since only one vglrun could be in the path. He keeps talking about using symlinks in /opt and so forth to to somehow make my package able to co-exists with his package downloadable at: http://www.virtualgl.org/ He does want me to change the package name also. Is it too late for me to that after that package has been accepted into fedora? Here is what he says about that: In terms of naming, I would suggest naming your RPM something besides VirtualGL. If you are splitting it into multiple RPMs, then this is easy. Just ship RPMs named "VirtualGL-common", "VirtualGL-client", "VirtualGL-utils", "VirtualGL-server", "VirtualGL-devel", etc., and none of them will actually be named "VirtualGL". Or maybe use "VirtualGL-fedora" or some alternative (even lowercase "virtualgl", perhaps.) If a upstream project somehow objects to someone packaging their software should you just give up and tell people that the upstream would prefer you download their self created rpms or is it considered acceptable to go ahead and package their software over their objections? He says at the end of his email: "'I'm willing to help out in any way I can, within reason, but I will also re-iterate that VirtualGL was never really designed to be integrated into an O/S distribution." Thanks for any thoughts you guys might have about this surprising reaction... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Network configuration future
On 09/07/2012 07:13 PM, Dan Williams wrote: I'm not sure the right place for this sort of thing is in the init system. Well I happen to be sure that the init systemd regardless of which flavor of the month it is should handle this because it is responsible to signal the service(s) and or order the service after the network connection is established. To me it's pointless to have the plethora of network managment application that exist out there playing some kind of middle man there talking to the init system and telling it when it's ready or when it's gone. And here comes the bigger question what is keeping all you networking guys from simply combine all that effort and coming up with one single network application that everybody can use happily from embedded to servers to desktop? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
fedora-review command fails on package
Hi, i tried to check my package with fedora-review, but this fails. martin@fc17 SPECS$ fedora-review -b 853553 Processing bugzilla bug: 853553 Bugzilla v0.7.0 initializing Chose subclass RHBugzilla v0.1 Trying bugzilla cookies for authentication Getting .spec and .srpm Urls from : 853553 --> SRPM url: https://www.disk.dsl.o2online.de/Fcl...?a=0tythsdteBc[https://www.disk.dsl.o2online.de/FclyPlh/RPMS/guayadeque/guayadeque-0.3.6-2.svn1830/guayadeque-0.3.6-2.svn1830.fc17.src.rpm?a=0tythsdteBc] --> Spec url: https://www.disk.dsl.o2online.de/Fcl...?a=ZK1IIr7oO60[https://www.disk.dsl.o2online.de/FclyPlh/RPMS/guayadeque/guayadeque-0.3.6-2.svn1830/guayadeque.spec?a=ZK1IIr7oO60] Using review directory: /home/martin/rpmbuild/SPECS/853553-guayadeque Downloading .spec and .srpm files No upstream for (Source0): guayadeque-svn1830.tar.bz2 Running checks and generate report Rebuilding /home/martin/rpmbuild/SPECS/853553-guayadeque/srpm/guayadeque-0.3.6-2.svn1830.fc17.src.rpm?a=0tythsdteBc using default root ERROR: Exception(/home/martin/rpmbuild/SPECS/853553-guayadeque/srpm/guayadeque-0.3.6-2.svn1830.fc17.src.rpm?a=0tythsdteBc) Config(fedora-17-x86_64) 13 minutes 48 seconds INFO: Results and/or logs in: /home/martin/rpmbuild/SPECS/853553-guayadeque/results ERROR: Command failed. See logs for output. Build failed rc = Build error(s) Exception down the road... the log file contains the following message: + /usr/bin/cmake -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -DCMAKE_VERBOSE_MAKEFILE=TRUE -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_SKIP_RPATH=TRUE -DCMAKE_BUILD_WITH_INSTALL_RPATH=FALSE .. -- The C compiler identification is GNU 4.7.0 -- The CXX compiler identification is GNU 4.7.0 -- Check for working C compiler: /usr/lib64/ccache/gcc -- Check for working C compiler: /usr/lib64/ccache/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/lib64/ccache/c++ -- Check for working CXX compiler: /usr/lib64/ccache/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Using install prefix /usr ... -- Found PkgConfig: /usr/bin/pkg-config (found version "0.25") -- Found wxWidgets: TRUE -- checking for module 'gstreamer-0.10' -- found gstreamer-0.10, version 0.10.36 -- checking for module 'sqlite3' -- package 'sqlite3' not found CMake Error at CMakeLists.txt:46 (MESSAGE): sqlite3 not found! -- Configuring incomplete, errors occurred! sqlite and sqlite-devel are installed, a local rpmbuild works. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora-review command fails on package
Le vendredi 07 septembre 2012 à 23:04 +0200, Martin Gansser a écrit : > Hi, > > i tried to check my package with fedora-review, but this fails. > > martin@fc17 SPECS$ fedora-review -b 853553 > Processing bugzilla bug: 853553 > Bugzilla v0.7.0 initializing > Chose subclass RHBugzilla v0.1 > Trying bugzilla cookies for authentication > Getting .spec and .srpm Urls from : 853553 > --> SRPM url: > https://www.disk.dsl.o2online.de/Fcl...?a=0tythsdteBc[https://www.disk.dsl.o2online.de/FclyPlh/RPMS/guayadeque/guayadeque-0.3.6-2.svn1830/guayadeque-0.3.6-2.svn1830.fc17.src.rpm?a=0tythsdteBc] > --> Spec url: > https://www.disk.dsl.o2online.de/Fcl...?a=ZK1IIr7oO60[https://www.disk.dsl.o2online.de/FclyPlh/RPMS/guayadeque/guayadeque-0.3.6-2.svn1830/guayadeque.spec?a=ZK1IIr7oO60] > Using review directory: /home/martin/rpmbuild/SPECS/853553-guayadeque > Downloading .spec and .srpm files > No upstream for (Source0): guayadeque-svn1830.tar.bz2 > Running checks and generate report > > Rebuilding > /home/martin/rpmbuild/SPECS/853553-guayadeque/srpm/guayadeque-0.3.6-2.svn1830.fc17.src.rpm?a=0tythsdteBc > using default root > ERROR: > Exception(/home/martin/rpmbuild/SPECS/853553-guayadeque/srpm/guayadeque-0.3.6-2.svn1830.fc17.src.rpm?a=0tythsdteBc) > Config(fedora-17-x86_64) 13 minutes 48 seconds > INFO: Results and/or logs in: > /home/martin/rpmbuild/SPECS/853553-guayadeque/results > ERROR: Command failed. See logs for output. > Build failed rc = Build error(s) > Exception down the road... > > the log file contains the following message: > > + /usr/bin/cmake -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr > -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 > -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share > -DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -DCMAKE_VERBOSE_MAKEFILE=TRUE > -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_SKIP_RPATH=TRUE > -DCMAKE_BUILD_WITH_INSTALL_RPATH=FALSE .. > -- The C compiler identification is GNU 4.7.0 > -- The CXX compiler identification is GNU 4.7.0 > -- Check for working C compiler: /usr/lib64/ccache/gcc > -- Check for working C compiler: /usr/lib64/ccache/gcc -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Check for working CXX compiler: /usr/lib64/ccache/c++ > -- Check for working CXX compiler: /usr/lib64/ccache/c++ -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Using install prefix /usr ... > -- Found PkgConfig: /usr/bin/pkg-config (found version "0.25") > -- Found wxWidgets: TRUE > -- checking for module 'gstreamer-0.10' > -- found gstreamer-0.10, version 0.10.36 > -- checking for module 'sqlite3' > -- package 'sqlite3' not found > CMake Error at CMakeLists.txt:46 (MESSAGE): > sqlite3 not found! > -- Configuring incomplete, errors occurred! > > sqlite and sqlite-devel are installed, a local rpmbuild works. Hi, There is no sqlite-devel in buildRequires in the spec, so mock cannot find it. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora-review command fails on package
On Fri, 2012-09-07 at 23:04 +0200, Martin Gansser wrote: > > sqlite and sqlite-devel are installed, a local rpmbuild works. Did you try with mock? Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Network configuration future
On Fri, 2012-09-07 at 21:02 +, "Jóhann B. Guðmundsson" wrote: > On 09/07/2012 07:13 PM, Dan Williams wrote: > > I'm not sure the right place for this sort of > > thing is in the init system. > > Well I happen to be sure that the init systemd regardless of which > flavor of the month it is should handle this because it is responsible > to signal the service(s) and or order the service after the network > connection is established. > > To me it's pointless to have the plethora of network managment > application that exist out there playing some kind of middle man there > talking to the init system and telling it when it's ready or when it's gone. I don't think the init system should really be responsible for a ton of the network management, otherwise you'll have people like Denys V. saying it's too bloated and should be simpler. I'm not really sure that moving everything a network management system *should* be doing into the init system solves any problems WRT complexity. There's clearly a gray area here, but my assertion is that if you put a significant amount of logic into the init system, where does it end? If you don't add bridging, then people are going to request bridging in the init system. And if you add it there, then why not add bonding? Where does it end? Next, for the things it *doesn't* do, how does it interact with the other management system that *does* do those things? What mediates the shared resources like DNS and the default route? And they all have to use the same configuration formats too. > And here comes the bigger question what is keeping all you networking > guys from simply combine all that effort and coming up with one single > network application that everybody can use happily from embedded to > servers to desktop? Because everyone is different, everyone has their own requirements and a lot of people don't care about anything *except* their own requirements. Saying "you have to take an extra step after plugging your network device in because server-type people need it to work this way" is just as much a non-starter as saying "you have to upgrade your kernel driver because we made this option automatic instead of manual so desktop users don't have to toggle a checkbox" to server people. That's Free Software. If we all agreed, 6 months later somebody would come up with a different system because they didn't like D-Bus, didnt' like the base library we were using (glib/qt/whatever), didn't like the API or the configuration model, etc. There's room to work towards consensus on functionality, but at the moment I don't see a lot of momentum towards a Grand New Unified Plan, partially because that's how free software works. It would be great if we had one, and I'm certainly willing to entertain changes to NetworkManager that make it more capable for anyone's use-cases. Nobody thinks NM has reached perfection, least of all me. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora-review command fails on package
On Fri, 7 Sep 2012 23:04:14 +0200 (CEST), Martin Gansser wrote: > -- checking for module 'sqlite3' > -- package 'sqlite3' not found > CMake Error at CMakeLists.txt:46 (MESSAGE): > sqlite3 not found! > -- Configuring incomplete, errors occurred! > > sqlite and sqlite-devel are installed, a local rpmbuild works. What about adding BuildRequires: sqlite-devel dbus-devel subversion-devel gettext-devel ? Probably more... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Network configuration future
On Fri, 2012-09-07 at 14:49 -0500, Bruno Wolff III wrote: > On Fri, Sep 07, 2012 at 13:23:37 -0500, >Dan Williams wrote: > > > >That's NM's heritage, but that's certainly not its focus. We're > >actually focusing a *lot* more on enterprise use-cases these days, > >including lots of knobs that admins like to turn. > > Is there a good source of documentation for these knobs? About a month ago > I was looking for a way to force specific settings in /etc/resolv.conf > when making wireless connections (to use a local caching resolver and > a fixed domain search list), and just happened to find that NM used > dhclient-$ifname.conf instead of dhclient.conf (somewhere other than > a documentation page found using google). 'man NetworkManager' is a good place to start here, which leads you to NetworkManager.conf, which leads you to: dns=dnsmasq which with 0.9.6 and any options you put into custom configuration in /etc/NetworkManager/dnsmasq.d, should do exactly what you want. The local caching nameserver functionality has actually been around for quite a few years. Also, on per-connection basis, NM allows appending custom search domains to the list returned by the DHCP server, or as you've found you can hijack the dhclient config files to do what you want too. As always, more documentation would be awesome; we've got a wiki but we can also add stuff to a FAQ in git too. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Fri, Sep 07, 2012 at 11:54:03AM -0700, Jesse Keating wrote: > Fedora 18 is basically closed for new feature work, and instead the > focus needs to be on integration of the existing feature set and > bugfixes. But as you state there is a large amount of time before > F18 releases, which means new feature work would have to stall out > for months. Instead, new feature work can begin for F19 and get > ahead of the game. That's why F18 and F19 are divergent. That's > why we went from a single line of development to two. This makes sense, but it runs directly against the current auto-inheritence behaviour. It's unsurprising that people end up with different opinions of the right thing to do here. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: upstream wants me to rename my package
On Fri, 2012-09-07 at 16:54 -0400, Gary Gatling wrote: > Hello, > > > I am working on a package called > VirtualGL: https://bugzilla.redhat.com/show_bug.cgi?id=834127 > > > After contacting the upstream on their mailing list, they seem > obsessed with being able to install their own rprms and my package > together at the same time. This seems odd / bad to me since only one > vglrun could be in the path. He keeps talking about using symlinks > in /opt and so forth to to somehow make my package able to co-exists > with his package downloadable at: That's not usually something Fedora does. The package name takes the name of the upstream project, because the package *is* the delivery option for that software in Fedora. We do not care that much about upstream RPMs that random projects may distribute, because they are often not tailored to the specifics of Fedora. We as Fedora packagers are familiar with the requirements of Fedora, and if the upstream project really wants control over the Fedora package, then they should become Fedora packagers themselves. Yes, you can use the 'alternatives' functionality, but that's mostly only been used by completely different, competing implementations of the same program, like Java vs. OpenJDK. It has not (nor, IMHO, should not) be used to allow slightly different versions of the same project, which isn't even forked (since you're just repackaging upstream code), to coexist and be switched between. My opinion, at least. Dan > > http://www.virtualgl.org/ > > > He does want me to change the package name also. Is it too late for me > to that after that package has been accepted into fedora? Here is > what he says about that: > > > In terms of naming, I would suggest naming your RPM something besides > VirtualGL. If you are splitting it into multiple RPMs, then this is > easy. Just ship RPMs named "VirtualGL-common", "VirtualGL-client", > "VirtualGL-utils", "VirtualGL-server", "VirtualGL-devel", etc., and > none > of them will actually be named "VirtualGL". Or maybe use > "VirtualGL-fedora" or some alternative (even lowercase "virtualgl", > perhaps.) > > > > > If a upstream project somehow objects to someone packaging their > software should you just give up and tell people that the upstream > would prefer you download their self created rpms or is it considered > acceptable to go ahead and package their software over their > objections? > > > > > He says at the end of his email: > > > "'I'm willing to help out in any way I can, within reason, but I will > also > re-iterate that VirtualGL was never really designed to be integrated > into an O/S distribution." > > > Thanks for any thoughts you guys might have about this surprising > reaction... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On 09/07/2012 02:36 PM, Matthew Garrett wrote: On Fri, Sep 07, 2012 at 11:54:03AM -0700, Jesse Keating wrote: Fedora 18 is basically closed for new feature work, and instead the focus needs to be on integration of the existing feature set and bugfixes. But as you state there is a large amount of time before F18 releases, which means new feature work would have to stall out for months. Instead, new feature work can begin for F19 and get ahead of the game. That's why F18 and F19 are divergent. That's why we went from a single line of development to two. This makes sense, but it runs directly against the current auto-inheritence behaviour. It's unsurprising that people end up with different opinions of the right thing to do here. I'm of the opinion that rawhide should be inheriting from the builds of the previous release, so long as there haven't been any builds directly on rawhide. I'm also of the opinion that the inheritance should happen as early as possible, eg as soon as the package is built, instead of waiting for a bodhi introduced delay. Rawhide works this way, the inheritance into rawhide should work this way too. Getting there is a little complicated due to how the fXX-updates-candidate -> fXX-updates-testing -> fXX tag dance works, but I'm confident smart people can figure that out if change is desired here. -- Help me fight child abuse: http://tinyurl.com/jlkcourage - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Fri, Sep 07, 2012 at 20:43:23 +, "\"Jóhann B. Guðmundsson\"" wrote: As you know we ( QA Community ) want all the testing to be focused on the release we are about to push out the door and we would like ( and some expect ) that maintainers are keeping the same focus and give what time they have to address the bugs we find in the process as Lennart has correctly pointed out. While QA is focused on testing for the next release, other testing is still useful. For example testing updates-testing packages for already released versions of Fedora is important. Even testing updates-testing stuff for branched (as opposed to say test / RC composes) is useful as it can keep bad stuff from being pulled in, rather than catching it after the fact. Now that to me the begs the question with our short release cycles do we have any numbers on how many maintainers have the time to be working on both and are those maintainers that do have that time actually taking advantage of the current model in place? It may be the case that some maintainers are actively working on changes in the branch release while a different set of maintainers are working on changes for the next release. It may be hard in some cases for maintainers to work on big changes for both branched and rawhide at the same time, but I expect in many cases two different sets of changes don't hit the same package (or set of packages) at the same time in branched and rawhide. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Network configuration future
Dan Williams wrote: > 'man NetworkManager' is a good place to start here, which leads you to > NetworkManager.conf, which leads you to: > > dns=dnsmasq > > which with 0.9.6 and any options you put into custom configuration > in /etc/NetworkManager/dnsmasq.d, should do exactly what you want. The > local caching nameserver functionality has actually been around for > quite a few years. Also, on per-connection basis, NM allows appending > custom search domains to the list returned by the DHCP server, or as > you've found you can hijack the dhclient config files to do what you > want too. > > As always, more documentation would be awesome; we've got a wiki but we > can also add stuff to a FAQ in git too. Would this not be more beneficial if this option was visible in the Gnome network settings UI? What if "Network proxy" was changed to "Network defaults" and a dns= option was added to the existing proxy options? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Fri, Sep 07, 2012 at 14:42:20 -0700, Jesse Keating wrote: I'm of the opinion that rawhide should be inheriting from the builds of the previous release, so long as there haven't been any builds directly on rawhide. I'm also of the opinion that the inheritance should happen as early as possible, eg as soon as the package is built, instead of waiting for a bodhi introduced delay. Rawhide works this way, the inheritance into rawhide should work this way too. That would be my preference as well. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Network configuration future
On Fri, Sep 07, 2012 at 16:38:27 -0500, Dan Williams wrote: 'man NetworkManager' is a good place to start here, which leads you to NetworkManager.conf, which leads you to: dns=dnsmasq I knew about that, but I don't use dnsmasq, I use dnscache. which with 0.9.6 and any options you put into custom configuration in /etc/NetworkManager/dnsmasq.d, should do exactly what you want. The local caching nameserver functionality has actually been around for quite a few years. Also, on per-connection basis, NM allows appending custom search domains to the list returned by the DHCP server, or as you've found you can hijack the dhclient config files to do what you want too. The per connection stuff needs to be set up for each AP though, so is a pain to use for generic settings. As always, more documentation would be awesome; we've got a wiki but we can also add stuff to a FAQ in git too. OK, I'll try to see if I can get the dhclient stuff noted somewhere appropriate. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Network configuration future
On Fri, 2012-09-07 at 16:46 -0500, Bruno Wolff III wrote: > On Fri, Sep 07, 2012 at 16:38:27 -0500, >Dan Williams wrote: > >'man NetworkManager' is a good place to start here, which leads you to > >NetworkManager.conf, which leads you to: > > > >dns=dnsmasq > > I knew about that, but I don't use dnsmasq, I use dnscache. In that case, how about we add a plugin for dnscache too? Though we are in the process of figuring out a more generic interface, so that for example dnscache itself could distribute a plugin for NM instead of having to build this stuff into NM. Dan > >which with 0.9.6 and any options you put into custom configuration > >in /etc/NetworkManager/dnsmasq.d, should do exactly what you want. The > >local caching nameserver functionality has actually been around for > >quite a few years. Also, on per-connection basis, NM allows appending > >custom search domains to the list returned by the DHCP server, or as > >you've found you can hijack the dhclient config files to do what you > >want too. > > The per connection stuff needs to be set up for each AP though, so is a > pain to use for generic settings. > > >As always, more documentation would be awesome; we've got a wiki but we > >can also add stuff to a FAQ in git too. > > OK, I'll try to see if I can get the dhclient stuff noted somewhere > appropriate. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Network configuration future
On Fri, 2012-09-07 at 16:44 -0500, Michael Cronenworth wrote: > Dan Williams wrote: > > 'man NetworkManager' is a good place to start here, which leads you to > > NetworkManager.conf, which leads you to: > > > > dns=dnsmasq > > > > which with 0.9.6 and any options you put into custom configuration > > in /etc/NetworkManager/dnsmasq.d, should do exactly what you want. The > > local caching nameserver functionality has actually been around for > > quite a few years. Also, on per-connection basis, NM allows appending > > custom search domains to the list returned by the DHCP server, or as > > you've found you can hijack the dhclient config files to do what you > > want too. > > > > As always, more documentation would be awesome; we've got a wiki but we > > can also add stuff to a FAQ in git too. > > Would this not be more beneficial if this option was visible in the > Gnome network settings UI? What if "Network proxy" was changed to > "Network defaults" and a dns= option was added to the existing proxy > options? Honestly, no. And here's why. First, we should probably be using a caching dns server by default. But really, this isn't an option that should ever be in a UI, because it should Just Work and you shouldn't have to care about DNS. Just like we should be auto-detecting proxy servers if we can, instead of making you enter that all manually. If you know you want a local caching DNS server, then you'll probably know how to turn it on. If you don't know what one is, then we should be setting up the right defaults for you. A distro that caters towards "easy to use" should probably just drop a default NM config file with dns=dnsmasq into /etc, while ones that cater more towards sysadmins would not. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: upstream wants me to rename my package
On Fri, Sep 7, 2012 at 5:43 PM, Dan Williams wrote: > > > That's not usually something Fedora does. The package name takes the > name of the upstream project, because the package *is* the delivery > option for that software in Fedora. We do not care that much about > upstream RPMs that random projects may distribute, because they are > often not tailored to the specifics of Fedora. We as Fedora packagers > are familiar with the requirements of Fedora, and if the upstream > project really wants control over the Fedora package, then they should > become Fedora packagers themselves. > I feel like maybe the name change is reasonable? Since he makes money somehow off his rpms? And I wouldn't want his customers or whatever to have their package clobbered by yum... (that is why I didn't push out into an update in Bodhi yet in any branch) But like everything else he is talking about, I feel its not my problem. And I don't really care. Maybe thats evil/wrong of me? Like, for example, If you want 2 packages to co-exist , then keep using /opt (freaking non-standard) and also put your vglrun script in /usr/local/bin/ so it "wins" and is first in the path and then their is no rpm conflict (except maybe the docs? Need to think about it more maybe...) but don't expect us to change our fedora packaging guidelines or our package just because you believe in having static binaries, non system headers, packages that do the same thing co-existing, etc. Rules are rules for a reason. I know we wouldn't change these fundamentals but I also don't think I should have to change anything other than the packages name at this point. I told him to tell me if their were security updates, or critical bugs and I would do likewise... Its all just weird to me his reaction. Maybe others on this list have had similar reactions from developers of open source software? My opinion, at least. > > Dan > Thanks! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: upstream wants me to rename my package
On Fri, Sep 7, 2012 at 4:57 PM, Gary Gatling wrote: > But like everything else he is talking about, I feel its not my problem. And > I don't really care. Maybe thats evil/wrong of me? Well, there are occasions when upstream's priorities are somewhat antithetical to what we're doing in Fedora. And pissing off upstream is never a great idea :) I think the goal is tread carefully, walking the fine line of trying to change what we can upstream, attempting to accommodate upstream's stated priorities as much as possible, while still making our Fedora packaging job easier. With VirtualGL, if his main concern is that Fedora's RPMs will overwrite the ones that he sells, could he just bump the Epoch tag in his copies? - Ken -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: upstream wants me to rename my package
On Fri, Sep 7, 2012 at 7:09 PM, Ken Dreyer wrote: > > Well, there are occasions when upstream's priorities are somewhat > antithetical to what we're doing in Fedora. And pissing off upstream > is never a great idea :) I think the goal is tread carefully, walking > the fine line of trying to change what we can upstream, attempting to > accommodate upstream's stated priorities as much as possible, while > still making our Fedora packaging job easier. > Understood. Do not want to piss them off. > > With VirtualGL, if his main concern is that Fedora's RPMs will > overwrite the ones that he sells, could he just bump the Epoch tag in > his copies? I think he was mostly concerned about the users who already installed his "Official" rpm before he found out about the review request. (For however long the packages have been there on his site for download) I think the epoch bump would work once he modified his package for any new downloads if he agreed to do that. But it would not help the people who already installed it. I don't think he sells the rpms directly but he has customers and said something about like 200 hours of work being supported for some time period by customers and also doing free (bonus) work on the project and not having time to learn to set up a yum repo or anything: "For starters, all of my paying customers are using RHEL, not Fedora, and the second most popular platform among VGL users is Ubuntu." So he has paying customers... The first suggestion was for him to set up a yum repo and use yum-priorities to prefer that repo over the fedora repos. But he did not like that idea at all. I could suggest an epoc version number if that if that is the best / proffered way to go. However, I might wait a few days to reply to his email. If he does not like that idea of an epoc version what do we offer next? I do think its strange to say "VirtualGL was never really designed to be integrated into an O/S distribution" when its in lots of Linux distros already such as ubuntu, arch and gentoo AFAIK. Thanks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Fri, 07.09.12 11:54, Jesse Keating (jkeat...@j2solutions.net) wrote: > On 09/07/2012 11:48 AM, Lennart Poettering wrote: > >Humm. I don't agree with this. As long as F18 is unreleased Rawhide will > >be basically untested and I also wonder what testing it at this point > >would bring, given that it right now is mostly F18 and very far from > >F19, so why not test the real F18 where we need all testing focussed > >anyway? > > Fedora 18 is basically closed for new feature work, and instead the > focus needs to be on integration of the existing feature set and > bugfixes. But as you state there is a large amount of time before > F18 releases, which means new feature work would have to stall out > for months. Instead, new feature work can begin for F19 and get > ahead of the game. That's why F18 and F19 are divergent. That's > why we went from a single line of development to two. I totally understand that. However this is not really how many people work. The assumption that everybody actually wants to get started asap with new feature development is simply wrong. I tend to focus on stabilization and bugfixes for quite some time before I switch back to feature development, and I actually believe most people should do it that way. And because I do it that way I want to keep F18 and F19 in sync for as long as I can. I want to decide on my own when we are ready and when I want to have F19 diverge from F18, and it shouldn't be implied that this is immediately done when pre-alpha is branched. Or to put this in other words: The default workflow should be that package developers focus on fixing/polishing the upcoming release. The exception should be that package developers immediately forget about the branch and focus immediately on new features. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-18 Branched report: 20120907 changes
On 07/09/12 22:07, Fedora Branched Report wrote:
> Compose started at Fri Sep 7 09:15:28 UTC 2012
>
> Broken deps for x86_64
> --
Who would like to re-arrange this report to be more effective and useful ?
1. The broken dependency first, not the package that requires it !
[libboost_thread-mt.so.1.48.0()(64bit)] [{owner/username/last commiter}]
blocking:
LuxRender
condor
ekiga
flush
gearmand
glob2
glom
iwhd
leechcraft
total: 9 packages blocked due to missing dependency on {blah}
last: previously found in package libboost, from source package boost
(or whatever).
And so on.
2. The other simplifying thing would be to only note x86_64 or 686 if
both are not broken.
eg:
both broken:
[libboost_thread-mt.so.1.48.0()(64bit)]
[libboost_thread-mt.so.1.48.0()]
show only once as
[libboost_thread-mt.so.1.48.0()] !both!
, but show:
[libboost_thread-mt.so.1.48.0()] !32bit!
Otherwise the report is really just duplicating half the information, ie
is twice as long as it needs to be.
3.
It could also be much nicer in a web page, perhaps with columns for
applies to (64 bit and 32 bit), and links to the git package source for
failing dependency package and the packages using it.
Having no internal knowledge of Fedora build stuff, I'm not volunteering
myself.
> Summary:
> Added Packages: 0
> Removed Packages: 0
> Upgraded Packages: 0
> Compose finished at Fri Sep 7 12:03:57 UTC 2012
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Fri, Sep 07, 2012 at 02:42:20PM -0700, Jesse Keating wrote: > On 09/07/2012 02:36 PM, Matthew Garrett wrote: > >This makes sense, but it runs directly against the current > >auto-inheritence behaviour. It's unsurprising that people end up with > >different opinions of the right thing to do here. > > > > I'm of the opinion that rawhide should be inheriting from the builds > of the previous release, so long as there haven't been any builds > directly on rawhide. I'm also of the opinion that the inheritance > should happen as early as possible, eg as soon as the package is > built, instead of waiting for a bodhi introduced delay. Rawhide > works this way, the inheritance into rawhide should work this way > too. Sure, and that's clearly the behaviour that Lennart wanted as well. But instead there was a mass rebuild that bumped his rawhide nvr and now he needs to do rawhide work manually. If development should be happening in rawhide then why is rawhide inheriting from f18? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Sat, Sep 08, 2012 at 01:28:53AM +0100, Matthew Garrett wrote: > Sure, and that's clearly the behaviour that Lennart wanted as well. But > instead there was a mass rebuild that bumped his rawhide nvr and now he > needs to do rawhide work manually. If development should be happening in > rawhide then why is rawhide inheriting from f18? I should clarify that. If there's still feature development then clearly that should happen in rawhide. But if the maintainer is working on stabalisation in f18 then rawhide should still get those packages. Right now what happens is that that's absolutely fine right up until someone decides to do a mass rebuild and suddenly the maintainer has to do active development in rawhide at the same time as they're trying to stabalise f18. That doesn't seem optimal. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Sat, 8 Sep 2012 01:32:55 +0100 Matthew Garrett wrote: > On Sat, Sep 08, 2012 at 01:28:53AM +0100, Matthew Garrett wrote: > > > Sure, and that's clearly the behaviour that Lennart wanted as well. > > But instead there was a mass rebuild that bumped his rawhide nvr > > and now he needs to do rawhide work manually. If development should > > be happening in rawhide then why is rawhide inheriting from f18? > > I should clarify that. If there's still feature development then > clearly that should happen in rawhide. But if the maintainer is > working on stabalisation in f18 then rawhide should still get those > packages. Right now what happens is that that's absolutely fine right > up until someone decides to do a mass rebuild and suddenly the > maintainer has to do active development in rawhide at the same time > as they're trying to stabalise f18. That doesn't seem optimal. This actually has nothing to do with mass rebuilds (unless I am misunderstanding). Mass rebuilds are done _before_ branching to avoid problems like this. :) In this case a proven packager noticed an issue in systemd, fixed it in rawhide. That breaks inheritence, so it will now always need builds in rawhide, it will not inherit from f18. We have discussed this before, and probibly will again. ;) During freezes (like the especially long one we have right now) this is especially painfull for rawhide, as fewer packages come in and they have to wait for the freeze to be over to get updates for non release blocking issues. It's a balancing act I fear, nothing will make everyone happy. Inheriting from updates-testing means rawhide can and will 'go backwards' as updates get unpushed/dropped. Dropping inheritance entirely means more work for maintainers. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-18 Branched report: 20120907 changes
On Sat, 08 Sep 2012 10:11:44 +1000 David Timms wrote: > On 07/09/12 22:07, Fedora Branched Report wrote: > > Compose started at Fri Sep 7 09:15:28 UTC 2012 > > > > Broken deps for x86_64 > > -- > Who would like to re-arrange this report to be more effective and > useful ? ...snip... > Having no internal knowledge of Fedora build stuff, I'm not > volunteering myself. Well, if you want to look, or anyone else wishes to take up the gauntlet: http://git.fedorahosted.org/cgit/mash/tree/utils/spam-o-matic kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Fri, Sep 07, 2012 at 07:43:32PM -0600, Kevin Fenzi wrote: > This actually has nothing to do with mass rebuilds (unless I am > misunderstanding). Mass rebuilds are done _before_ branching to avoid > problems like this. :) Argh, sorry, I was confusing it with something unrelated. Yeah, not a mass rebuild problem in this case. > During freezes (like the especially long one we have right now) this is > especially painfull for rawhide, as fewer packages come in and they > have to wait for the freeze to be over to get updates for non release > blocking issues. > > It's a balancing act I fear, nothing will make everyone happy. > > Inheriting from updates-testing means rawhide can and will 'go > backwards' as updates get unpushed/dropped. Dropping inheritance > entirely means more work for maintainers. Add a flag to bodhi to let maintainers re-enable inheritance? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 8 Sep 2012 01:58:35 +0200 Lennart Poettering wrote: > On Fri, 07.09.12 11:54, Jesse Keating (jkeat...@j2solutions.net) > wrote: > > > On 09/07/2012 11:48 AM, Lennart Poettering wrote: > > >Humm. I don't agree with this. As long as F18 is unreleased > > >Rawhide will be basically untested and I also wonder what testing > > >it at this point would bring, given that it right now is mostly > > >F18 and very far from F19, so why not test the real F18 where we > > >need all testing focussed anyway? > > > > Fedora 18 is basically closed for new feature work, and instead the > > focus needs to be on integration of the existing feature set and > > bugfixes. But as you state there is a large amount of time before > > F18 releases, which means new feature work would have to stall out > > for months. Instead, new feature work can begin for F19 and get > > ahead of the game. That's why F18 and F19 are divergent. That's > > why we went from a single line of development to two. > > I totally understand that. However this is not really how many people > work. The assumption that everybody actually wants to get started asap > with new feature development is simply wrong. I tend to focus on > stabilization and bugfixes for quite some time before I switch back to > feature development, and I actually believe most people should do it > that way. And because I do it that way I want to keep F18 and F19 in > sync for as long as I can. I want to decide on my own when we are > ready and when I want to have F19 diverge from F18, and it shouldn't > be implied that this is immediately done when pre-alpha is branched. really what is so hard about commiting to master and building. then doing "git checkout f18&& git merge master&& git push && fedpkg build&& fedpkg update" its really not much effort to keep them in sync at all if thats what you choose. you dont delay things getting into rawhide and tested by those running rawhide, its win all round. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlBKtewACgkQkSxm47BaWffdlQCfeQnSlBx3HbHR1oSrl5Og6F8Z m7YAoMIoCcNbIU7YrHs1P+YQSYJ2nzcS =7QNm -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Fri, Sep 07, 2012 at 19:43:32 -0600, Kevin Fenzi wrote: On Sat, 8 Sep 2012 01:32:55 +0100 This actually has nothing to do with mass rebuilds (unless I am misunderstanding). Mass rebuilds are done _before_ branching to avoid problems like this. :) Yeah this isn't as much of a problem as I first thought. Branched wouldn't be there at that time. There still be cases where updates to the latest release branch would need to be duplicated in rawhide, that wouldn't otherwise, but there wouldn't be that many. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Network configuration future
On Fri, Sep 07, 2012 at 17:04:31 -0500, Dan Williams wrote: On Fri, 2012-09-07 at 16:46 -0500, Bruno Wolff III wrote: On Fri, Sep 07, 2012 at 16:38:27 -0500, Dan Williams wrote: >'man NetworkManager' is a good place to start here, which leads you to >NetworkManager.conf, which leads you to: > >dns=dnsmasq I knew about that, but I don't use dnsmasq, I use dnscache. In that case, how about we add a plugin for dnscache too? Though we are in the process of figuring out a more generic interface, so that for example dnscache itself could distribute a plugin for NM instead of having to build this stuff into NM. I wouldn't be adverse to that. I don't work on that package though. (I find it convenient though since I had been using dnscache built from source before the ndjbdns package was available in Fedora and using the package is more convenient for new installs.) I could file an RFE with that package. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Aw: Re: fedora-review command fails on package
Gesendet: Freitag, 07. September 2012 um 23:32 Uhr Von: "Michael Schwendt" An: devel@lists.fedoraproject.org Betreff: Re: fedora-review command fails on package On Fri, 7 Sep 2012 23:04:14 +0200 (CEST), Martin Gansser wrote: >> -- checking for module 'sqlite3' >> -- package 'sqlite3' not found >> CMake Error at CMakeLists.txt:46 (MESSAGE): >> sqlite3 not found! >> -- Configuring incomplete, errors occurred! >> >> sqlite and sqlite-devel are installed, a local rpmbuild works. > > What about adding > BuildRequires: sqlite-devel dbus-devel subversion-devel gettext-devel > ? > Probably more... i have added this build requirements and now mock and fedora-review working as aspected. But more problematic, however, is the license question for the bug review, already discussed on: http://lists.fedoraproject.org/pipermail/devel/2012-September/171344.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
