- Arch-general - lists.archlinux.org

Re: [arch-general] [arch-dev-public] ATTN: Kernel maintainers (tpowa, brain0): libcap
by Michal Soltys 05 May '08

05 May '08

Travis Willard wrote: > Hey guys, > > I just realized that, for some squirrely reason, I am currently > "maintaining" libcap. I have no freakin' clue what libcap even is. I > just got a flag-out-of-date version asking if we should update it to > libcap2, which seems reasonable, as it's nice and shiny-new. Looking > around, however, libcap seems tied to kernel releases, so maybe it'd > make more sense for someone more in-the-know with kernel.org stuff to > take it on? > Version 2.x works pretty fine - I've been using it for a while, but you will need some simple and straightforward patches for e.g. samba (it assumes ancient lack of header declarations, should be fixed in .29) and vsftpd (doesn't look for 2.x at all, but otherwise compiles and works perfectly fine). From other notable things - ntpd requires linking to libcap, if you want to run it with privilege separation. > Basically, if someone out there knows WTF libcap is for, and how to > test, etc., then let me know and you can grab it. > In short - it's overbloated suid ;) http://www.friedhoff.org/posixfilecaps.html Sorry for crossposting, but I though I'd be good to mention samba / vsftpd stuff. Cheers

2 1

[arch-general] Spellcheck in Firefox3
by Jackson Alley 05 May '08

05 May '08

Hey, I know it's still in beta, but for me everything works except for spell check. I was wondering if anyone has figured out how to get spell check working in the latest beta? J

2 1

[arch-general] AUR Cleanup
by Allan McRae 05 May '08

05 May '08

The AUR has a large number of obsolete packages which could use cleaning up. Examples of packages that may be cleaned up are: - packages that have been renamed or replaced - old and unmaintained developmental (cvs/svn/etc) packages This is where you can help. Post suggestions of packages in the AUR Cleanup wiki page (http://wiki.archlinux.org/index.php/AUR_CleanUp_Day). TUs will get together and go though the list in a couple of weeks and confirm which packages should be removed. Please do not remove suggestions from the wiki page but add a comment on why it should be kept instead. TUs will take great care not to delete any useful package. Cheers, Allan -- Allan McRae Arch Linux Trusted User

1 0

[arch-general] Status of linux 2.6.25 kernel
by Hussam Al-Tayeb 03 May '08

03 May '08

What's the status of the 2.6.25 kernel in testing? Any showstoppers left? Regards, Hussam Al-Tayeb.

1 0

[arch-general] Upstream bugs, patches
by Nagy Gabor 02 May '08

02 May '08

Hi! I'm new to this list, and my English is far from perfect, please tolerate it ;-) I am/was a big fan of ArchLinux, I'm using it from 0.5 version, I also made some little contributions to pacman, but now I noticed some tendencies which I cannot accept. So I would like to hear the official "standpoint" about a certain question, before I may drop my good old distro. I also think that this question is important to all end-users. (Aaron:) I know that I'm not popular here, but I hope that you won't answer "against me" ;-) Some foreword (sorry, maybe off, I would like to manipulate thoughts :-D): Basically I think that principles are _not_ rules. So things like KISS and "vanilla packages" are good for defining ourselves in one sentence (in wikipedia for example), but I don't really understand reasoning like "foo violates KISS" (IMHO the reasoning should say, _why_ it worth applying KISS here.). When I _describe_ myself as liberal, I won't deduce my acts from this "rule"... (theoretical example). So the question: Do/Should Archlinux packagers apply unofficial or merged-but-not-yet-released patches to fix an existing _bug_ of a released package? An example: http://bugs.archlinux.org/task/5861 This is quite an old bug, and we are just waiting and waiting... If the answer no, do packagers forward the bug to the official developer or the end-user should forward his discovered bug? An other small example, which is much less important; but I think this belongs to the same "category", the reasoning is much more mysterious to me, since the "patch" clearly cannot break anything here: http://bugs.archlinux.org/task/10307 This was closed 4 minutes after opening, so I couldnot discuss it (I wanted to revert my last sentence there, this is not true now, I didn't want to lie). Evince developers like that option, and they don't want to change it. (But I don't agree with them here, of course). I simply cannot imagine any reason for "won't fix" (apart from "lazyness" :-P). I'm pretty sure that "implementing" it has _no drawback_, and at least 6 users (from the number of requests) would like it. Again, it is a marginal issue (I put my evince.desktop to NoUpgrade of pacman), but I would like to understand the reason of close. Bye I hope, that I didn't hurt anybody, overall I think that AL is still one of best distros around, and I must say a big "thank you" for your work.

5 10

[arch-general] Info for tellico users
by Attila 02 May '08

02 May '08

Hi, i recognized that libxslt makes the step to 1.1.23 but if you use tellico (http://periapsis.org/tellico/) than there could be a problem with it: http://www.periapsis.org/archives/2008/05/01/tellico_not_showing_most_value… See this please only as an information because it seems that at the moment the author of tellico don't know what is the reason (tellico or libxslt). See you, Attila

1 0

[arch-general] test
by Eric 01 May '08

01 May '08

test -- Eric

2 1

[arch-general] Rename 'unstable' to 'developing'
by gan lu 01 May '08

01 May '08

As we know, many packages saying even firefox or openoffice in unstable repo don't mean "unstable", instead, they are quite stable. The name of repo simply doesn't reflect the fact, so how about a rename? It's harmless and may even bring some good point, at least from a marketing point, it may courage more devs or TUs to follow the upstream developing and put more packages there, in return attract more people who are interested in the package to do more (testing) work, which can eventually make the package better quality. Just my 2 cents.

5 8

[arch-general] Closing bugreports too fast?
by Gerhard Brauer 30 Apr '08

30 Apr '08

Hello, i thought about a "trap" in which myself are also fallen sometimes: I look at the bugtracker to see if someone filed already a bugreport for a problem. But i don't find it cause it is already fixed and thereby marked as closed. And without using advandced search functions all searches are only done on open bugreports. As an example the problem yesterday with kdelibs: In forum thread someone says: i write a bugreport (without posting the number ;-) It was #10312 tpowa provided a fixed package in a nice short time, quickly, and then closed the report (fixed). But users in the forum have had problems to find this report cause it was closed. If i look at the history of the report i see: Aaron reopened it, then we have user request for closing an Jan closed it finally again. On such reports (the maintainer knows that many users would/could have the problem, sometimes only during different mirror syncing) i would suggest **not** to close such a report too fast. Ok, it is fixed from developer side (and maybe available on ftp.archlinux.org) but users could run in the problem probably later or tommorrow. I see no problem with reports where the reporter says: ok, it worked, you could close it. And where the maintainer knows: it was maybe a local or a problem on a minor package. But in situations like above it would be helpfully if the report wasn't closed (as well it was fixed on developer side), but maybe in a status like: fixed, scheduled for closing. But the report is "open" and so found on searching. I don't know if the bugtracker have such a function to closed it automatically for ex. after 6 days. On the other hand the maintainer must do this (it's additional work, but i think it's worth). Regards Gerhard -- Don't drink and root!

5 5

[arch-general] funny colors startx
by Eric Dan 30 Apr '08

30 Apr '08

seeing funny colors momentarily, when starting or shutting down an X session. X itself behaves normally after that. using: [GeForce Go 7400] and nvidia 169.12-2 my "uname -a": Linux dirac 2.6.24-ARCH #1 SMP PREEMPT Sun Mar 30 11:40:06 CEST 2008 i686 Intel(R) Core(TM)2 CPU T5500 @ 1.66GHz GenuineIntel GNU/Linux any other users here having the same experience? Thank you -- Eric

2 1