August 2012 - openSUSE Features - openSUSE Mailing Lists

[openFATE 313536] Get rid of SuSEconfig.fonts
by fate_noreply＠suse.de 02 Aug '12

02 Aug '12

Feature changed by: Petr Gajdos (pgajdos) Feature #313536, revision 18 Title: Get rid of SuSEconfig.fonts openSUSE Distribution: Implementation Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Andreas Jaeger (a_jaeger) Partner organization: openSUSE.org Description: There is no point to run that code after installation of every package (and it's not run when you use zypper or 3rd party tools anyways). That code should be only run as a part of post-install of the fonts packages as only those are affected. Relations: - Remove SuSEconfig (feature/id: 100011) Discussion: #1: Petr Gajdos (pgajdos) (2012-07-03 17:13:23) Added "fontpackage" package to the M17N:fonts. fontpackage is intended to common runtime deps of every font package (e. g. /usr/share/fonts/truetype) and fontpackage-devel for buildtime dependency of every font package. fontpackage-devel contains only one file for now, which installs on /etc/rpm/macros.fonts-config. For details see osc cat M17N:fonts fontpackage rpm-macros.fonts-config Example of modified font package is M17N:fonts/xano-mincho-fonts. Could you please express your opinion on this plan? #2: Petr Gajdos (pgajdos) (2012-07-04 09:39:25) (reply to #1) After rethinking I've choosen fontpackages-runtime and fontpackages- devel. #3: Thorsten Kukuk (kukuk) (2012-07-06 14:37:38) I'm not a fonts expert, but looks good to me, beside one thing I don't really like: fontpackages-runtime contains only one directory. I think we should drop that package and package the directory inside of the RPMs which contains fonts. This has the big advantage, that RPM will take care of the directory itself, if the last package using it is removed. Or the directory should be added to filesystem directory, which includes already the parent directory. #4: Petr Gajdos (pgajdos) (2012-07-10 21:32:54) Ok, submitted fontpackages package into factory. sr#127540. #5: Petr Gajdos (pgajdos) (2012-07-11 13:47:20) As far as I can tell, M17N:fonts are ready for removing SUSEconfig. fonts. There are few packages using %run_suseconfig_fonts macro: 844- ksc-pcf (forgotten font package to be moved to M17N:fonts) daps fonts- config plotutils susedoc texlive-bin tv-fonts (package maybe to be moved to M17N:fonts) x3270 xmahjong xorg-x11-fonts xterm Also ghostcript-fonts package is subject to change in this regard (% run_suseconfig -m fonts). Unfortunately I can do anything until fontpackages package is in factory, so this process is blocked by license issue of our own code :- / (see declined sr#127540). Maybe we could consider to accept package as is for now and change license later (of course Novell replaced by SUSE LINUX Products GmbH, Nuernberg, Germany or something like that). #6: Petr Gajdos (pgajdos) (2012-07-30 09:22:45) https://bugzilla.novell.com/show_bug.cgi?id=772595 #7: Thorsten Kukuk (kukuk) (2012-08-02 12:09:22) (reply to #6) "You are not authorized to access bug #772595." About what is the bug and why is access limited? + #8: Petr Gajdos (pgajdos) (2012-08-02 12:17:48) (reply to #7) + This is default policy for legal issues I think. I have added you to cc + of this bug. -- openSUSE Feature: https://features.opensuse.org/313536

1 0

[openFATE 313536] Get rid of SuSEconfig.fonts
by fate_noreply＠suse.de 02 Aug '12

02 Aug '12

Feature changed by: Thorsten Kukuk (kukuk) Feature #313536, revision 17 Title: Get rid of SuSEconfig.fonts openSUSE Distribution: Implementation Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Andreas Jaeger (a_jaeger) Partner organization: openSUSE.org Description: There is no point to run that code after installation of every package (and it's not run when you use zypper or 3rd party tools anyways). That code should be only run as a part of post-install of the fonts packages as only those are affected. Relations: - Remove SuSEconfig (feature/id: 100011) Discussion: #1: Petr Gajdos (pgajdos) (2012-07-03 17:13:23) Added "fontpackage" package to the M17N:fonts. fontpackage is intended to common runtime deps of every font package (e. g. /usr/share/fonts/truetype) and fontpackage-devel for buildtime dependency of every font package. fontpackage-devel contains only one file for now, which installs on /etc/rpm/macros.fonts-config. For details see osc cat M17N:fonts fontpackage rpm-macros.fonts-config Example of modified font package is M17N:fonts/xano-mincho-fonts. Could you please express your opinion on this plan? #2: Petr Gajdos (pgajdos) (2012-07-04 09:39:25) (reply to #1) After rethinking I've choosen fontpackages-runtime and fontpackages- devel. #3: Thorsten Kukuk (kukuk) (2012-07-06 14:37:38) I'm not a fonts expert, but looks good to me, beside one thing I don't really like: fontpackages-runtime contains only one directory. I think we should drop that package and package the directory inside of the RPMs which contains fonts. This has the big advantage, that RPM will take care of the directory itself, if the last package using it is removed. Or the directory should be added to filesystem directory, which includes already the parent directory. #4: Petr Gajdos (pgajdos) (2012-07-10 21:32:54) Ok, submitted fontpackages package into factory. sr#127540. #5: Petr Gajdos (pgajdos) (2012-07-11 13:47:20) As far as I can tell, M17N:fonts are ready for removing SUSEconfig. fonts. There are few packages using %run_suseconfig_fonts macro: 844- ksc-pcf (forgotten font package to be moved to M17N:fonts) daps fonts- config plotutils susedoc texlive-bin tv-fonts (package maybe to be moved to M17N:fonts) x3270 xmahjong xorg-x11-fonts xterm Also ghostcript-fonts package is subject to change in this regard (% run_suseconfig -m fonts). Unfortunately I can do anything until fontpackages package is in factory, so this process is blocked by license issue of our own code :- / (see declined sr#127540). Maybe we could consider to accept package as is for now and change license later (of course Novell replaced by SUSE LINUX Products GmbH, Nuernberg, Germany or something like that). #6: Petr Gajdos (pgajdos) (2012-07-30 09:22:45) https://bugzilla.novell.com/show_bug.cgi?id=772595 + #7: Thorsten Kukuk (kukuk) (2012-08-02 12:09:22) (reply to #6) + "You are not authorized to access bug #772595." + About what is the bug and why is access limited? -- openSUSE Feature: https://features.opensuse.org/313536

1 0

[New: openFATE 313475] opensuse 12.2 - is it time to replace kopete with telepathy?
by fate_noreply＠suse.de 02 Aug '12

02 Aug '12

Feature added by: jimbo bigcreed (Dimble_ThriceFoon) Feature #313475, revision 1 Title: opensuse 12.2 - is it time to replace kopete with telepathy? Package Wishlist: Unconfirmed Priority Requester: Important Requested by: jimbo bigcreed (dimble_thricefoon) Partner organization: openSUSE.org Description: it hasn't been considered ready for previous releases, but in the time since 12.1 released v0.3 of telepathy arrived to generally positive reaction, and after a minor bug-fix we can expect v0.4 to release on June 1st: http://mail.kde.org/pipermail/kde-telepathy/2012-May/006268.html -- openSUSE Feature: https://features.opensuse.org/313475

1 8

[New: openFATE 311068] Akmod Equivalent for openSUSE
by fate_noreply＠suse.de 02 Aug '12

02 Aug '12

Feature added by: Luke Wolf (LukeWolf) Feature #311068, revision 1 Title: Akmod Equivalent for openSUSE openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Luke Wolf (lukewolf) Partner organization: openSUSE.org Description: Tumbleweed related as opposed to 11.4 related Fedora has this really nice tool called Akmod or Automatic Kernel Module, which builds kmods on boot when you load into a new kernel that doesn't have kmods or to use the openSUSE term kmps. As we now have a rolling release in openSUSE: Tumbleweed this kind of functionality is more important than ever. Unless there are plans for rebuilding the kmps for Tumbleweed each time there is a new kernel. Which doesn't seem to be the case with the Nvidia kmp only supporting up to 2.6.34 series. Use Case: A user wants to run the rolling release version as opposed to the version based version because it better suits his needs to not have to reinstall every 8 months, This user updates to all the latest packages in Tumbleweed but unfortunately the latest kmp is for the last version release and so the user is forced to fall back to either the open source drivers which as of yet are not up to the user's needs, or fall back to the older kernel. an Akmod equivalent would fix this problem Business case (Partner benefit): openSUSE.org: Because we have a rolling release now and this rolling release has new kernels but there aren't for instance new Nvidia kmps to support it but an akmp or whatever you want to call it would fix that -- openSUSE Feature: https://features.opensuse.org/311068

1 3