March 2009 - Arch-dev-public - lists.archlinux.org

[arch-dev-public] Scim and arphic fonts update in [testing]
by Eric Bélanger 19 Mar '09

19 Mar '09

Hi all, I've just updated several scim-related packages. They are in the [testing] repo. The updated packages are: anthy libchewing libhangul scim scim-anthy scim-chewing scim-tables uim scim-uim (no update, just rebuild against uim 1.5.5) As I don't use these packages (I believe no dev use them either), I could only do minimal testing. It would be nice if users of these packages test them and report if they work properly or if there are problems with them. I've also updated (in [testing] repo) the Arphic fonts: ttf-arphic-ukai and ttf-arphic-uming There are two points about these fonts: 1. According to upstream: "This release contains Firefly's Bitmap fonts. The Bitmap fonts are available for 11, 12, 13, 14, 15 and 16 pixel and currently cover Big5 and GB2312. HKSCS is currently not supported as there are many more characters missing. So, for Big5 and GB2312 characters the bitmap glyphs should improve the rendering, but for all other characters, the rendering is the same like without bitmap glyphs." I might be nice to get comments about someone using these fonts to see if the ttf-fireflysung package is indeed no longer needed (http://bugs.archlinux.org/task/8951). 2. The updated ttf-arphic-* packages in testing provide the fonts as a TrueType Collection, i.e. the fonts come in 4 flavors (CN, HK, TW and TW MBE), with different glyph shapes according to the preferred shapes in each region (more info here: http://www.freedesktop.org/wiki/Software/CJKUnifonts/Download). As a result TeX users will encounter trouble using this font. The following programs/libraries are known to not fully support TTC files and can usually only use the first fontface of the TTC: - jdk and openjdk6 - imlib2 and applications which use imlib2. Again, I and probably none of the devs don't use these fonts so feedback from users would be nice. Eric

2 5

[arch-dev-public] Move the catalyst drivers from extra to AUR/Community
by Eduardo Romero 19 Mar '09

19 Mar '09

Here it is, Andreas Radke and I have talked about this and have come to a conclusion. The ATI catalyst drivers are in a pitiful state and AMD is doing close to nothing to improve the situation, they just take Linux as a joke. At least, that is the impression one gets when nvidia releases great drivers for Linux and ATI in the other hand is not showing any promises in making their drivers better and well supported. In the other hand the radeonhd driver, which is in extra shows some promise, and so far have been good, they have been able to make a good driver with only some documentation released by AMD, when AMD can't make one while being the makers, go figure out. This situation is worse in the x86_64 system, we have been stuck with catalyst 8.12 while i686 has 9.2 already, because AMD just wanted to break things at will, because their approach is very strange, break some things to improve others. That is why, we hope for a TU who can bring this drivers to community to raise his hand and help us with this task. Please, if you want to give catalyst the love they don't deserve but need, do not hesitate to offer yourself as the new maintainer. In the worse case scenario where no one raises his hand, the package should be moved to AUR. I personally would not want this, so please TUs respond. A TU will be able to do what is required for the best with this drivers, which includes making 9.2 and later work with x86_64. What do the other developers think? Any developer that wants to take care of them? PS: I do use this drivers, so I do care about them, but this is a choice that had to be made. Thanks, Eduardo "kensai" Romero

9 23

[arch-dev-public] dropping lilo?
by Andreas Radke 19 Mar '09

19 Mar '09

I'm still listed being the maintainer of our lilo package. The former upstream website is down for months, only some mirrors are available. Though the package is still working well (haven't heard any complains) we have 2 good working grub(-legacy) and also grub(2) alternatives and we recommend these now all time. Do you guys think it's time to drop lilo from the repos? I'd like to do so. Or does somebody want to take it over from me? -Andy

5 7

[arch-dev-public] [signoff] klibc-udev-140-1
by Tobias Powalowski 19 Mar '09

19 Mar '09

Hi bump to latest version, please recreate your initrd and signoff for both arches. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 2

[arch-dev-public] [signoff] udev-140-1
by Tobias Powalowski 19 Mar '09

19 Mar '09

Hi bump to latest version, fixes: http://bugs.archlinux.org/task/13834 http://bugs.archlinux.org/task/13801 http://bugs.archlinux.org/task/13720 please signoff for both arches greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

6 5

[arch-dev-public] [signoff] kernel26 2.6.28.8-1
by Tobias Powalowski 19 Mar '09

19 Mar '09

Hi guys, new kernel adresses the following things: - bump to latest version fixed: http://bugs.archlinux.org/task/13717 please signoff for both arches greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

5 4

[arch-dev-public] New digikam and kipi-plugins (KDE4)
by Daniel Isenmann 18 Mar '09

18 Mar '09

Hi, now that the digikam developer team released the first stable KDE4 version I would like to move those version to [extra]. This will replace the old digikam 0.9.5 (KDE3) and makes libkipi obsolete. A new package called lensfun will be moved to [extra], too. This is necessary and needed by the new digikam. Everything is running here fine with the new version and I don't see any errors or issues. I'm not the maintainer of digikam, it's Tobias, but I use digikam in a daily basis with my photos. Because of that I have built the 0.10.0 release for testing today. What do you think, can we move it and replace the old KDE3 version with the new KDE4 version? Daniel

3 7

[arch-dev-public] [signoff] make 3.81-4
by Andreas Radke 18 Mar '09

18 Mar '09

I've added info files and fixes man+info path (FHS), fixes #13113. please signoff. -Andy

2 2

[arch-dev-public] Move libtorrent-rasterbar to extra
by Hugo Doria 18 Mar '09

18 Mar '09

Hi guys, I want to move libtorrent-rasterbar to [extra] to add as a dependency for deluge and close this bug report: http://bugs.archlinux.org/task/12764 Any objections? -- Hugo

5 13

Re: [arch-dev-public] [arch-general] Fixing licenses / sources
by Eric Bélanger 17 Mar '09

17 Mar '09

On Tue, Mar 17, 2009 at 1:51 PM, Aaron Griffin <aaronmgriffin(a)gmail.com> wrote: > On Fri, Mar 13, 2009 at 3:02 PM, Eric Bélanger <snowmaniscool(a)gmail.com> wrote: >> On Fri, Mar 13, 2009 at 1:27 PM, Gerardo Exequiel Pozzi >> <vmlinuz386(a)yahoo.com.ar> wrote: >>> >>>> The list : >>>> http://wiki.archlinux.org/index.php/User:Snowman/License_Rebuild_TODO >>>> >>>> Eric >>> >>> Hi Eric, >>> >>> I made a list of 90 extra-packages from your list, that also have bad mandir >>> Please see here: http://bugs.archlinux.org/task/13765#comment41164 >>> >>> Both isdn4k-utils and xinetd from core have bad mandir. >>> >>> >>> Take care. >> >> We'll also check for mandir at the same time: >> http://wiki.archlinux.org/index.php/User:Snowman/License_Rebuild_Checklist >> >> We'll take care or the ones with correct license and bad mandir later. > > In addition to the mandir/license thing, we could also do a check for > info files too. That's also in the checklist. > > This is getting ambitious :) Sounds like something that could be > covered on bug day > It would be nice if other devs other than Phil and myself would try to do some license rebuild on bug day. Or at least check for these things while fixing bugs. However, on bug day, we probably don't want all devs doing license rebuild instead of fixing bugs. Most of these license rebuilds don't have bugs assigned to them; they just a been built several years ago. Also, doing all these chacks and fixes is quite time consuming. A couple of remarks for the rebuilders: - GPL vs GPL2 vs GPL3 : Remember to check if the packages is licensed for a specific GPL version or if it's licensed for version 2 or later. The best way to do that is to check the main source file. It usually have a blurb specifying that. Even if the license has been already added to trunk, better double check as sometime I need to change it form GPL2 to GPL. - ChangeLog: If there is a package ChangeLog please add an entry describing your changes. If there is no ChangeLog, don't add one unless it's a package that you maintain or want to adopt. Some devs don't use ChangeLog so it won't be updated which defeats the presence of a ChangeLog. If there are devs who wants their packages to have ChangeLog, let us know. We could add them in that case.

1 0