January 2008 - Arch-dev-public - lists.archlinux.org

[arch-dev-public] No internet? No codemac.
by Jeff Mickey 25 Jan '08

25 Jan '08

There is an awesome story involving Comcast, myself, and a cut cable cord. I shall not recount it here, but I think you can get the picture. Jeff has no internet. They are reconnecting on this upcoming Thursday, so consider me inactive until at least the weekend. My first week of classes is this week (My last semester!!) so I'll be busy anyways. I'll have internet on campus, but it's best if I do my school work... I'll see you soon, feel free to update/etc any of my packages that need it. I'm not that possessive of them. // jeff -- . : [ + carpe diem totus tuus + ] : .

5 5

[arch-dev-public] Adding mpg123 in [extra]
by Eric Belanger 25 Jan '08

25 Jan '08

Hi, I would like to replace the mpg321 package in extra by mpg123 (FS#9221) because mpg321 hasn't been updated since 2002 and mpg123 is now licensed under the GPL/LGPL. Any objections/comments? Eric -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

5 4

[arch-dev-public] Kernel framebuffer logo
by Thayer Williams 25 Jan '08

25 Jan '08

I've been testing various forms of the new logo for use in the kernel framebuffer and I still think the best implementation is to use no logo at all. The inherint disadvatange is that more and more monitors are widescreen these days and that means the logo proportions are distorted (short and wide) in the framebuffer since standard vga settings use a 4:3 ratio. This is just my two cents of course, but I suggest that we remove the logo from the framebuffer altogether.

6 11

[arch-dev-public] Fwd: [signoff] bash 3.2.0330-1 and filesystem 2007.11-4
by Aaron Griffin 23 Jan '08

23 Jan '08

Please retest. This bash package overrides the previous one. Patch level updated, profile.bash added to backup=() array. Potential issue: Apparently /etc/profile is not replaced if modified. Can someone verify if this is fixed or not? I will investigate further as I fear it may be a pacman bug - if so, I'm guessing keeping etc/profile in BOTH backup arrays for the time being may fix this. filesystem changes: Setup for FHS compliant man pages - FS#8839 Claim ownership of /etc/profile from bash - FS#4766 Remove LESSCHARSET env var from /etc/profile - FS#8877 bash changes: Update patch level to 033 Remove /etc/profile from package. Move bashisms to /etc/profile.bash - FS#4766 /etc/profile was also largely revamped. Please comment on the changes there if you'd like.

5 12

[arch-dev-public] groff: archaic technology go
by Aaron Griffin 23 Jan '08

23 Jan '08

Man.... man pages and groff and all this crap are waaay too complex for what they do. Anyway, here's the deal, and hopefully someone will know a better/more proper way to do this. With the utf8 man page changes (pending, see other email), some UTF-8 characters come out a bit goofy. I don't know if it is only en_US.UTF-8 or not. The simply fact is that there's like 3 different 'dash' characters in UTF-8, and the ones displayed are not the ones your keyboard outputs. So searching for "-S" doesn't work. Long story short, adding the following to /usr/share/groff/site-tmac/man.local fixes this: .if '\*[.T]'utf8' \ . char \- \N'45' . char - \N'45' . char ' \N'39' .. Yeah, all those dots are needed... most of those replacements are gleaned from a SuSe changelog, but they work here. Could someone else make this change, or possibly suggest a better way to do the same thing? What we're doing is telling nroff not to use the fancy chars and use the same ones the keyboard uses. Opinions? Thoughts? Comments? Beer?

2 2

[arch-dev-public] [signoff] lvm2 2.02.31-1
by Thomas Bächler 23 Jan '08

23 Jan '08

lvm2 update 2.02.29 -> 2.02.31, please sign off.

3 2

[arch-dev-public] [signoff] pcre 7.5
by Eric Belanger 22 Jan '08

22 Jan '08

Simple upstream update. Please signoff. Thanks. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

4 4

[arch-dev-public] Building mplayer
by Thomas Bächler 22 Jan '08

22 Jan '08

I have been maintaining mplayer for a while now. Unfortunately, during my absence mplayer had to be rebuilt by someone else. The x86_64 version (built by Eric) is fine, but the i686 (built by someone who doesn't know what the "Packager" option in makepkg.conf is for) version is missing features (bug #9288). The mplayer build system sucks. Seriously, it is the worst idea people have ever had, but the guys who are currently maintaining it are proud of it (I had the pleasure of arguing with one of them about autotools vs. mplayer during a two hour car trip last summer). Here is the thing: In autotools, you can use --enable-FOO to force configure to enable a feature. However, configure still checks if all libraries and headers are present and will add the needed options to gcc, or abort if a check fails. In mplayer, --enable-FOO forces the build system to enable a feature, but also skips all checks and doesn't add any options to the compiler, thus making 'make' fail unless you modify Makefiles by hand. This is not only unintuitive but also completely inconsistent with the way autotools work. The only way to properly enable a feature in mplayer is to put no --enable or --disable flag in and hope that configure's autodetection detects it properly. And of course you have to check if everything went fine after configure finished by reading the output summary. I don't have to tell you that this is very distributior-unfriendly. Since there is no way to force mplayer's configure to abort if something we want is missing, we must have the necessary makedepends listed - which we don't, as they are not easy to determine. The only way to properly build mplayer is to watch everything it does carefully and abort if something is wrong. For a while, a "we need clean build chroots so that our packages are not corrupted" attitude has spread, and this is exactly what broke mplayer (I have no idea which makedepend may be missing though). So please, unless you know exactly what you are doing and have much time to check everything, don't build mplayer!

4 4

[arch-dev-public] moving qt-4 and qt3 to [extra]
by Pierre Schmitz 22 Jan '08

22 Jan '08

Hi all, finally with pacman 3.1 qt3 and qt-4 can be moved to [extra] without problems. I want to start this tonight or at the weekend (if I have internet access). So please make sure the packages in testing are the latest and do not touch qt related packages during the move. Here is a first list of packages that I want to move. Please check if I missed some (@tpowa: there are some kde-4 related packages in testing). eric oprofile qgit arts kdebindings kdebluetooth kdegraphics kdelibs dbus-qt3 poppler-qt poppler-qt3 pyqt pyqt3 python-qscintilla qca qca-qt3 qca-tls qscintilla qscintilla-qt3 qt qt-doc qt3 qt3-doc qwt qwtplot3d amarok-base amarok-engine-xine kmplayer qjackctl qsynth scribus fwbuilder opera psi twinkle twinkle-kdefree wpa_supplicant_gui djvulibre kile kmobiletools lyx qtparted spassgen gtk-qt-engine qtiplot speedcrunch stellarium xdrawchem Pierre PS: If someone knows an elegant way to do the move without untagging,copying to add and del, retag and run db-scripts, please let me know. :-) -- archlinux.de

11 23

[arch-dev-public] [signoff] xulrunner packages
by Aaron Griffin 22 Jan '08

22 Jan '08

Just so this doesn't get buried in the middle of a thread: https://dev.archlinux.org/todo/44/ On Jan 21, 2008 8:17 AM, Alexander Baldeck <kth5(a)archlinuxppc.org> wrote: > I'll push them as soon as I get a sign-off for all the xulrunner packages.

2 1