Re: [arch-general] Rail Model font for coders
On 23/01/11 18:13, hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_hare_h...@lavabit.com wrote: .you're a troll and a spammer. Get the hell off my mailing list. Meeku: This attitude does not do the reputation of your o/s any good. If you don't want to use the font fine. just so you know, your silly overly long email address alone qualifies you for spamming and the first mail sent by your was immediately flagged as such. It also doesn't help that your messages appear somewhat like it was written by a spammer and the you proceed to argue about it as-if your original mail was relevant to this ML.
Re: [arch-general] PulseAudio in [testing]
It's probably because the masses of people who already know Pulse Audio will break their sound aren't bothering to try it. I have a whole IRC channel filled with people who, if they were to actually test this, would FLOOD this entire discussion with problems that would make the Arch devs reconsider this decision. dude! no-one cares what you think so quit spamming the mailing list with your nonsense already you clearly don't know what you're talking about so please spreading FUD you're just exposing your ignorance.
Re: [arch-general] How do AUR packages get new maintainers?
On 22/09/10 18:44, David C. Rankin wrote: On 09/21/2010 09:07 PM, Mario Figueiredo wrote: On 21-09-2010 23:17, Matthew Gyurgyik wrote: On 09/21/2010 04:53 PM, David C. Rankin wrote: Guys, I've seen recent Request to Ophan package XYZ posts, and I've found some fairly large AUR packages that are orphaned (like RPM5). But, how do AUR packages get new maintainers? Does somebody monitor the orphans and then divvy them out among those with write privileges in AUR or does somebody have to say I'll take package X on? http://wiki.archlinux.org/index.php/AUR Really dude? You've been using arch for how long and still have these elementary questions? Think about you questions and try to find answer before you post to the list. Alternatively hire an arch tutor. And who on earth are you? This is the whole problem that makes Arch so gd frustrating to work with. I ask a simple question and get nothing back but - dumbass RTFM. C'mon, WTF is a community mailing list for if not to ask questions about a distribution and how package assignment is handled. Think before you type works both ways. Yes, if there is an answer in the wiki that tells you what to do when you find orphaned packages in AUR - I should have found it. Regardless of whether it is there or whether it was overlooked, when somebody asks something on the list in an attempt to help Arch -- for God sake, don't kick them in the teeth. Common courtesy and civility goes a long way in life. don't let trolls get the best of you.
Re: [arch-general] 'Local mirror' page was removed from wiki
On 18/09/10 19:17, Stefan Erik Wilkens wrote: [...] Guus, I checked the current mirrorlist before replying, correct me if I'm wrong but I can't find any entry relating to the domain Nathan included in his mailing, nor is he listed as a tier1 on the developer's wiki. Maybe I've missed something painfully obvious here? -Stefan it's not *official* , when the new mirror scheme went into action I asked about it because from the docs it appeared that I needed to be an official mirror ad thus permission to sync from the Tier-1s, but I was told that that wasn't the case. I didn't and don't want to run an official mirror in the sense that the mirror appears in the mirrorlist but I run the mirror[1] for what I consider to be a useful purpose and until someone pisses me off or it becomes useless I will continue to run it. It doesn't serve any other mirrors and users aren't expected to use it as their daily mirror which is the reason I don't want it in any mirrorlist. [1] the mirror is at arm.konnichi.com, it primary idea is that it can be used to do a blanketed and hopefully seamless downgrade of all packages with `pacman -Suu` or downgrade to any single package. http://arm.konnichi.com/2010/09/19/ provides a mirror that behaves like any other mirror of the official repos except the packages are those synced on September 19th 2010. likewise http://arm.konnichi.com/2009/12/03/ is a mirror with files from December 3rd 2009. ARM syncs once per day so it can't cause much problems and as stated previously the daily average bandwidth is so low that if you're running a mirror then it's almost insignificant unless you have everyone syncing from you which is almost certainly not the case with the Tier-1s. Yesterday or Friday's sync took about 900MiB most of which was from sauerbraten, over 400MiB and some larger packages, today IIRC was less than 10 MiB.
Re: [arch-general] 'Local mirror' page was removed from wiki
On 19/09/10 17:26, Matthew Gyurgyik wrote: [...] As I posted on the forum... How hard is it to run rsync and look at the man page for rsync? rsync is the *only* command that is needed to create a local mirror. We want to discourage this behavior as much as possible and it is really quite trivial to setup a mirror. Setup a local mirror 1. rsync to local dir (look at the developer's wiki for mirrors and the proper rysnc arguments) 2. Set up webserver to serve local dir (if on a lan) 3. Set local mirror url in mirrorlist 4. Alternatively use Server = file:///mnt/media/mirror/$repo/os/x86_64 in pacman.conf or mirrorlist That is all that has to be done. If one is going to be creating a local mirror, he/she should really have this basic knowledge. This elitist attitude is what pisses me off most about the Arch community but I must admit that you sir just took it to the next level. I'll answer your question anyway. It's pretty easy to create a local mirror. But in your haste to show off your holyness you forgot that the issue isn't about creating a mirror, it's about doing it properly without causing issues for upstream. Your idea about throwing an rsync command at is does things like sync the entire mirror(as-is recommended in the NewMirrors wiki) which I'm sure isn't what you actually want if you're going to create a local mirror and this will undoubtedly just waste bandwidth for the mirror, after-all, if it's the packages you want then why would you go and sync the ISOs or even the sources? Now, I've stated my personal use-case and I' sure other have similar and other use-cases for having a local mirror, so I guess you have no argument against it other than it's something else that isn't useful to you so should be available to anyone else... Now, If you think it's a good idea to keep trolling as opposed to go and read what the actual issues are then please continue you are free to do so.
Re: [arch-general] 'Local mirror' page was removed from wiki
On 16/09/10 19:39, Matthew Gyurgyik wrote: [..] Ok a few things here 1. There are a *few* instances where having a local mirror is warranted not sure where you were going with that but i feel like you've left a bit off of that sentence. 2. There are many, many, many packages that are in the repos that *you* don't use! Every time you download one of these packages it is wasted bandwidth! you don't get to tell anyone how to use their bandwidth. 3. Mirror bandwidth is not free! Every time you are downloading unused packages you are wasting the mirrors money! Why waste money? (Keep point 1 in mind) since i already payed for that bandwidth and utilize it for other purposes it is in fact free. 4. @Fess you and a few other people do not make the community. not sure what point you're trying to make here 5. The majority of the community will agree that hosting a local mirror is silly considering that there are alternatives! the majority of people at least in the western cultures will agree that paedophilia is sick. the majority of these people don't know what paedophilia is. again not sure where you're going with that so i thought I'd make some wild pointless claims as well. 6. I am quite sure that mirror operators are not and will not be happy with users downloading gigs of data a month so they can have their own local mirror. when you become a mirror operator or bring actual evidence to the table you will have a say in this. 7. Remember, the local mirrors are generously mirroring for us. They are under *no obligation* to do so! Treat them with respect! this doesn't make any sense. 8. If point 1 applies, then those people should be more than capable of producing their own scripts. we are. but you see, the point you decided to side-step is that we're being told that the existing script was bad, now, if it was bad fair enough but no-one can(or will) tell us what was so wrong about it; result: you're now forcing everyone that needs to create their own script to do so and thus risk causing the same problems the old script cause because as I've stated multiple times - no-one is telling us(me) what the problems are with that script. it's all well and good to say this or that is bad but if you're not going to tell anyone what's bad about it then we'd all be better off if you hadn't opened your mouth at all.
Re: [arch-general] 'Local mirror' page was removed from wiki
On 16/09/10 20:10, Matthew Gyurgyik wrote: On 09/16/2010 02:59 PM, Nathan Wayde wrote: On 16/09/10 19:39, Matthew Gyurgyik wrote: [..] Ok a few things here 1. There are a *few* instances where having a local mirror is warranted not sure where you were going with that but i feel like you've left a bit off of that sentence. 2. There are many, many, many packages that are in the repos that *you* don't use! Every time you download one of these packages it is wasted bandwidth! you don't get to tell anyone how to use their bandwidth. 3. Mirror bandwidth is not free! Every time you are downloading unused packages you are wasting the mirrors money! Why waste money? (Keep point 1 in mind) since i already payed for that bandwidth and utilize it for other purposes it is in fact free. You most certainly do not pay for the Mirror's bandwidth! Just look at this article: http://lwn.net/Articles/178618/ my contract said I paid for it... [...] 6. I am quite sure that mirror operators are not and will not be happy with users downloading gigs of data a month so they can have their own local mirror. when you become a mirror operator or bring actual evidence to the table you will have a say in this. Again look here: http://lwn.net/Articles/178618/ or ask any admin in charge of bandwidth operations. Aaron if you are reading this, would mind sharing the bandwidth cost for the arch servers? [...] At first I typed out a reply but I deleted it because this thread is already dead so I will simply restate my question that no-one has an answer to. What were the issues with that wiki page and the script. I'd like to know so I don't cause these *problems* for Tier-1 mirrors I sync from as I have to implement my own script which is based on the bad script that was in the wiki.
Re: [arch-general] 'Local mirror' page was removed from wiki
On 17/09/10 00:21, Ng Oon-Ee wrote: On Thu, 2010-09-16 at 16:16 -0700, Steve Holmes wrote: On Thu, Sep 16, 2010 at 09:54:16PM +0200, Stefan Erik Wilkens wrote: On 16/09/10 19:39, Matthew Gyurgyik wrote: you don't get to tell anyone how to use their bandwidth. But can we at least say that grabbing packages without using them is wasting mirror bandwidth, and thus not something we want. In fact, something that should be frowned upon? It sounds like this Nathan fella doesn't grasp the concept that he pays for his own bandwidth and the mirror operator has to pay for the bandwidth used by the mirror server. Sure Nathan can squander his bandwidth however he wants but the mirror operators have to spread their bandwidth around for all of us to get our normal updates and of course, the cost has to be shouldered by someone. While my initial reaction to the thread was to do exactly this (point out that Nathan does not seem to understand that mirrors have to pay for bandwidth as well, and also that the linked article was obviously not read) I think its a bit out-of-line to dismiss him as this 'Nathan fella'. Where I come from such terms would only be used on a brat or delinquent, slightly derogatory in my opinion. Not a comment on the CONTENT but on the STYLE =). like I said, I'd deleted my reply but here I'll state it again... I already run a mirror for other purposes, if the Tier-1 has a problem with that then they should block arm.konnichi.com . since I already run that for other purposes I sync from arm.konnichi.com - in-case you didn't realise I own it. I'm a idiot, that much is no secret, so maybe someone can enlighten me... like I said already, I already run a mirror for other purposes, if I want to waste the bandwidth of my mirror that's my business because I already paid for it, but the important question is the one that's always ignored in favour of petty politics and that is: I want to know specifically what was wrong with that script so I as a mirror operator can take the necessary measures to make sure I'm not abusing the Tier-1 from which I sync.
Re: [arch-general] 'Local mirror' page was removed from wiki
On 09/09/10 14:11, Pierre Schmitz wrote: On Thu, 9 Sep 2010 15:55:35 +0300, Evangelos Foutras foutre...@gmail.com wrote: On Thu, Sep 9, 2010 at 3:40 PM, Fesskillall_hum...@lavabit.com wrote: Page Local mirros was removed from wiki by this reason: - It is generally frowned upon to create a local mirror due the bandwidth that is required. There is not a good reason to create a local mirror, since one of the alternatives below will likely meet your needs. - I think it's very useful ability, and why this page was removed... i don't know. It's silly. If anyone else think it must be return - maybe we should do it? P.S. A lot of guys agreed with me this morning, so i think many people want this article back. -- I agree with the reasoning, I disagree with the content removal. : D See https://bbs.archlinux.org/viewtopic.php?id=103987 The original article was just wrong and causing us problems. Feel free to add an improved one. If the script was broken or it caused problems it wouldn't hurt to state what these problems. Correct me if I'm something here but I have idea what these problems were. If the script caused problems then what stops someone creating their own script that works the same way? IMHO the text posted is likely worse than what was there before since it just makes a bunch of claims with no info.
Re: [arch-general] [PATCH 1/2] kill_everything: Reduce number of -f tests
On 09/09/10 16:19, Victor Lowther wrote: Thomas Bächlertho...@archlinux.org wrote: Am 08.09.2010 06:16, schrieb Victor Lowther: On Tue, Sep 7, 2010 at 10:47 PM, Dave Reisnerd...@falconindy.com wrote: Instead of checking for the existance of a file in /var/run/daemons on every iteration, handle the null case by setting nullglob. The shopt call is done inside a subshell as to not bother the environment since we may be going to runlevel 1 only temporarily. I thought about just enabling nullglobs and extglobs unconditionally in functions, but decided that was too likely to get objections no matter how unlikely breakage was. :) As for nullglob, I do think it is useful and enabling it might be useful in so many places - I didn't even know this option, it would have been useful for me before. I am in favor of enabling nullglob in function and dropping that subshell. Sounds good to me - nullglob is useful in general, and enabling it should not break anything else in the initscripts package. Do we need extglob anywhere? I don't think so. I will take a look. I don't see anywhere in the initscripts that has this issue but you might want to take a look at dotglob for the future, because with nullglob you break the behaviour of commands that work like ls. i.e `ls *.ext` etc. would result in ls being passed an argument '*.ext' in the event that *.ext doesn't match anything. With nullglob set, no argument gets passed and you end up with just `ls` which is likely to cause subtle bugs.
[arch-general] Makepkg $(srcdir) detection and false-positives
I'm not sure if this is the correct ML or not but whatever I'll post here anyway. I was just reading the ML where the quest? to finding why makepkg warns about $srcdir was brought up and a simple grep -R... seemed to be the method of detection. Anyway it reminded me of another message on the topic last week i think where someone said that it would warn on files with debugging symbols... TL;DR makepkg does a grep -q to decide if a package contains files that reference $(srcdir), this is inadequate as it causes a false-positive on files that contain debugging symbols. This can be eliminated by specifying the option `-I` a.k.a `--binary-files=without-match` to grep which makes prevents grep from matching binary files. Rationale: the only paths that binary files should contain based on buildtime setting are path such as '/usr/share/xyz'. If the pkgbuild *accidentally* uses a variable that resolves with $srcdir in it then I'd argue that the pkgbuild is broken and will most likely break the application in other ways and will be caught before sharing the pkgbuild. I can't be the only one that tests their packages before uploading to the AUR right? On another note, shouldn't there also be a check for $pkgdir. The only cases of this that I've ran into myself have been a reference to $pkgdir causing all sorts of nonsense such as broken symlinks and incorrect resource paths.
Re: [arch-general] [arch-dev-public] Large packages in repositories
On 18 August 2010 16:37, Pierre Schmitzpie...@archlinux.de wrote: [...] -- Sven-Hendrik You need to keep in mind that's its not just the disk space that might cause problems here but traffic and especially bandwidth are. E.g. the our mainserver has about 10mbit/d bandwidth including mirroring, website etc.. One important issue which hasn't been raised is the fact that the bigger the package the longer it takes to sync than 1 package. Today's sync for me took 53 minutes the previous highest time i can remember is about 20 minutes and that was with the recent push of KDE 4.5 beta? into testing. I'm lucky in that I don't suffer any issues yet, but I can imagine that for other with smaller mirrors with lower bandwidth during this period everything else on the server is slowed because of this 1 instance of rsync. Not only that, but some of us have contracts to abide by which restrict the use of long-running processes beyond reasonable use so while multiple syncs can be done as a work-around it'd be nice to at least discuss some sort of policy here, even if it's just that a notification should be done on arch-mirrors when exceptionally large packages are about to go into the repos. I'm aware this is a one-off but a few years ago I'd be saying the same thing large games being a one-off.
Re: [arch-general] Referencing $srcdir in PKGBUILD?
On 17/08/10 10:15, Allan McRae wrote: On 17/08/10 19:05, Magnus Therning wrote: Lately my PKGBUILDs result in a warning when building: == WARNING: Package contains reference to $srcdir It's a bit confusing, since PKGBUILD(5) has the following to say about $srcdir: srcdir This points to the directory where makepkg extracts or copies all source files. What should I do to get rid of the warning? /M grep your files in your package for $srcdir (the actual value...). If it is not in a config file or RPATH or the like, you can probably ignore it. Allan Please make sure you are 100% sure it can be ignored though. I've come across cases where symlinks in (e.g in /usr/lib) pointed to the $srcdir which cause confusing problems later on.
Re: [arch-general] New to Arch with problems with AUR
On 23/07/10 11:36, Florian Pritz wrote: On 23.07.2010 12:27, Mario Daniel Carugno wrote: First i present myself. My name is Mario and i was reading this list for a few weeks. I'm coming from Debian, [...] Welcome :) For instance, i couldn't compile shaman. Actually i can't compile aqpm or libaqpm, wich is a dependency of shaman, and it isn't in the pacman repositories. Try to find out what's wrong (Maybe it's as easy as changing pkgver because upstream already fixed the problem in a newer release. Always check that first!) and if possible fix it yourself. If you can't, try asking on IRC or write a comment on the package's page. Is it always so common to have problems in building AUR packages ? There is software that's buggy and troublesome, but also one that just works™. At least those packages I use work most of the time. in the shaman case. IIRC shaman et al. is a dead horse, and shaman2 and friends are not ready yet.
Re: [arch-general] Getting firefox to use the PDF I want?
On 22/07/10 23:31, Joe(theWordy)Philbrook wrote: It would appear that on Jul 21, Magnus Therning did say: After installing Gimp it became the default application for PDFs, something I didn't really want. snip How do I get firefox to use the correct application? It would appear that on Jul 21, Nilesh Govindarajan did say: Firefox-Edit-Preferences-Applications It would appear that on Jul 21, Magnus Therning did say: Ah, forgot to mention that I've looked there already. There is no mention of PDF there, and I can't find a way to add an entry to it. snip But where, and how do I change the settings? I used the search box inside Firefox-Edit-Preferences-Applications to pull up what to do with pdf and was then able to set it to okular. But then I no longer get the selection pop-up that would let me override the choice and use evince if I wanted to... And if I select always ask the pop-up doesn't offer okular except by clicking my way to the search box where I need to point or type the full path. IE: /usr/bin/okular rather than just okular So I decided to just set it and forget it. Hope this helps. why not just set it to xdg-open and be done with it?
Re: [arch-general] perl-authen-sasl: local (2.1401-1) is newer than community (2.15-1)
This is prolly a stupid idea but I'll suggest it anyway. Have anyone thought of simply adding another field in the pkginfo, say altver which if present would override pkgver. I'm pretty sure it would walk right around all this nonsense until(if ever) upstream starts using better version schemes. It would also fix? the issue with version dependencies of -svn(et al.) packages where the actual version is e.g 2.1 but the version in the pkginfo is 2432.
Re: [arch-general] ftp.gigabit.nu / ftp.archlinux.se shutting down
On 04/07/10 21:35, Rickard Eriksson wrote: Cut from the forum where my co-admin first put this up, however it got closed with reason trolling... This mirror will shut down in the upcoming days. Few funny facts: * We never got contacted by anyone before we got added in the official mirror list. We just posted this thread and all of the sudden it appeared. No verification of whom we were and what our intension were. * ArchLinux is fundamentally unscalable in the package manager aspect. * ArchLinux puts the trust in the hands of every mirror owner and their security. ftp.archlinux.se is the prime example of a machine vulnerable to all sorts of things. This affect YOUR security. This is why it's being put down. If the ArchLinux authors would start signing packages this would not be a risk to you. * We posted a suggestion of this in 2006. http://bugs.archlinux.org/task/5331 -- This is 4 years of insecurity. * We recommend all of you to switch to a distribution caring about user security and atleast signs their packages. Most RPM and APT based distros does this (Ubuntu, Debian, RedHat, CentOS, SuSE, OpenSuSE, etc etc etc). Have fun. :-) Yours, Mikael Rickard It's true, you are trolling.
Re: [arch-general] Catalyst-test
On 03/07/10 03:40, Martín Cigorraga wrote: @Nathan, Janno: Hi guys, thanks for your time and forgive me the lapse to post my comment but I'm literally out of time these days - personal things and such... I did follow wiki step by step just like I do allways with all the *excellent* Arch wikis and the only problem I found with this Catalyst 10.6.2 is composite effects are not active when loggin in - unlike with 10.4 which works ok giving me composite efffects from startup without the need to hit Alt+Shift+F12 twice in KDE SC. I only experience artifacts problems with xorg-server-backclear (main panel misspainted with black squares) and xorg-server-1.8-catalyst-maximize-fix which renders Kickoff menu and Yakuake unusable. Seems I have to wait to new Catalyst release this time :( Once again, thanks! I don't use KDE so I can't comment on the KDE issues specifically but the black square issue sounds like the rendering bugs introduced with the new acceleration which can be reverted with `aticonfig --set-pcs-str=DDX,ForceXAA,TRUE`
Re: [arch-general] VLC and Wine have been out-of-date too long.
On 26/06/10 08:28, Lauri Niskanen wrote: Hello, usually Arch Linux have had very quick updates to packages when the upstream bumbed a version. However, I am slightly annoyed by the fact that VLC [1] and Wine [2] have been out-of-date for a long time. VLC 1.1.0 was released about a week ago and Wine 1.2-rc1 was released on 2010-05-21. Now there is Wine 1.2-rc5. I should also note that regardless of the Wine being a release candidate it is as stable release as 1.1.x-versions including the currently packaged 1.1.44. The officially stable version is 1.0.1, but 1.1.x and 1.2rc are considered very stable, yet they are officially both development version. I agree with the one who packaged 1.1.x in Arch, it is stable enough for Arch and 1.0.1 is just too out date. Please update vlc to 1.1.0 and Wine to 1.2-rc5. [1] http://www.archlinux.org/packages/extra/i686/vlc/ [2] http://www.archlinux.org/packages/extra/i686/wine/ `abs`
Re: [arch-general] Catalyst-test
On 26/06/10 18:00, Martín Cigorraga wrote: Hi folks, first time at the list. I'm still using catalyst-test and haven't upgraded to new catalyst/kernel/evedev bacause some issues I never had before with Arch. Catalyst: I installed latest catalyst with xorg-server with the maximize-fix following instructions on the wiki posted by Nathan and while everything installed okay KDE SC is unusable because graphic glitchs all around (Yakuake is break as well as konsoles and most applications) and even Kickoff menu being unusable - it shows up only after trying to open it two/three times but can't navigate menus. new Xorg-sever / hal: I'm running a spanish speaking Arch and with these new versions of xorg-server and xf86-input-evdev I can't get KDM (KDE SC log-in manager) to handle correctly my spanish keyboard - /etc/hal/fdi/policy/10-keymap.fdi still set correctly to es but I read somewhere this file is deprecated in the new Xorg 1.8 Any feedback will be very appreciated! did you follow the wiki for new xorg: http://wiki.archlinux.org/index.php/Xorg#xorg.conf.d_.28Xorg_1.8.29 . I haven't done any of that yet myself but it works as usual. You may need to generate a new xorg.conf with `aticonfig --initial`
Re: [arch-general] Catalyst-test
On 23/06/10 11:39, Madhurya Kakati wrote: On Wed, Jun 23, 2010 at 4:04 PM, Heiko Baumsli...@baums-on-web.de wrote: Am Wed, 23 Jun 2010 15:50:37 +0530 schrieb Madhurya Kakatimkakati2...@gmail.com: Itsn't catalyst-test in AUR Catalyst 10.6? No, it's 10.4. You should use catalyst from AUR. It's 10.6. http://aur.archlinux.org/packages.php?ID=29111 Heiko O.K so what do i have to do? just install catalyst or remove catalyst-test and then install it? instructions are here http://wiki.archlinux.org/index.php/ATI_Catalyst#Catalyst.27s_repositories just pick your repo and `pacman -S catalyst` ...
Re: [arch-general] Catalyst-test
On 23/06/10 12:02, Madhurya Kakati wrote: On Wed, Jun 23, 2010 at 4:25 PM, Nathan Waydekum...@konnichi.com wrote: On 23/06/10 11:39, Madhurya Kakati wrote: On Wed, Jun 23, 2010 at 4:04 PM, Heiko Baumsli...@baums-on-web.de wrote: Am Wed, 23 Jun 2010 15:50:37 +0530 schrieb Madhurya Kakatimkakati2...@gmail.com: Itsn't catalyst-test in AUR Catalyst 10.6? No, it's 10.4. You should use catalyst from AUR. It's 10.6. http://aur.archlinux.org/packages.php?ID=29111 Heiko O.K so what do i have to do? just install catalyst or remove catalyst-test and then install it? instructions are here http://wiki.archlinux.org/index.php/ATI_Catalyst#Catalyst.27s_repositories just pick your repo and `pacman -S catalyst` ... Nathan Wayde Thank you. Was looking for a repo. didn't knew it existed. I should also note: some of us have issues with some app most notably xulrunner based apps like firefox and thunderbird wherein they fail to renedr correctly thus leaving large black or greyed out portions on the windows until they are exposed (move-over or switch tab etc). this appears to be a bug with the new acceleration in 10.6, if you are one of the unlucky you can force it to use the old method with `aticonfig --set-pcs-str=DDX,ForceXAA,TRUE` however you may then need to use a patched xorg-server that fixed a resize/maximize/... bug I use `pacman -S xorg-server-1.8-catalyst-maximize-fix` there is also a another fix for the same issues under xorg-server-backclear, don't ask me which works better I couldn't tell any difference.
Re: [arch-general] File Associations for firefox thunderbird :)^
On 15/06/10 09:19, Peter Lewis wrote: On Tuesday 15 Jun 2010 at 06:48 Madhurya Kakati wrote: I am a full time KDE user and I don't have GNOME or its libraries. Firefox and Thunderbird keep asking me to choose applications to open .pdf, .doc, .xls, http://, etc. Is there no package which can fix the file associations for FF and TB ? That's likely some xdg stuff. It usually works using gnome, KDE and xfce but nothing else. KDE probably has some preferences thing somewhere, otherwise you're pretty much as f. as everyone who doesn't use a big DE. Hurray for 'Desktop Integration'.. I don't think so. xdg-settings --list gives on default-web-browser. You can't use xdg-settings when you don't have one of the major DEs running, xdg-open falls back to a hardcoded array of browsers in that case. It's all quite awkward if you don't use gnome, kde or xfce. I know, doesn't really help with your problem.. Have you read the first line of my post properly ? I said I am a 100% KDE user. tried system settings? the file associations there i guess. I've come across this problem too. I've never managed to get Firefox to honour KDE's file associations (which is big negative IMO), but on one machine, it did remember what I told it to do. From memory, Firefox's file associations can be edited in Edit-Preferences-Content, but I'm not sure if Thunderbird has something similar, since I don't use it. So can Firefox use XDG? I was under the impression that it just managed its own associations. On another machine though, with an identical set-up, it continually asks for a binary to open the file with, and you have to point the file dialog to /usr/bin/okular or whatever. This is annoying, but I've no idea why it worked in one case by not the other. Pete. Have you tried simply pressin ok when it asks you? Mozilla apps have a nasty bug?/annoyance wherein the dialog pops up asking you to specifify the program to use when in fact it knows your last preference. Also, if in the case it works, you don't need, and prolly should enter the command that opens it, instead use xdg-open and your preferred program will be launch even after you change it.
Re: [arch-general] Equalizer
On 29/05/10 14:45, Nilesh Govindarajan wrote: Hi, I am looking for a global sound equalizer. It seems there is one for pulseaudio, but does it work fine if anybody is using it on this list ? Also, any other alternatives because I am using ALSA. Yes it works perfectly with PA, YMMV of-course.
Re: [arch-general] Burning From Command Line
On 26/05/10 16:59, Joerg Schilling wrote: Mauro Santosregisto.maill...@gmail.com wrote: Because I say so is not a valid backup for your claims, Earth used to be flat and the center of the universe because the experts of that time said so. This behavior gets people mad at you and invariably Good point! Since more than 3000 years men know that Earth is a spehere (from watching ships that appear on the horizon with their sails first). Since aprox. 2200 years men know the diameter of Earth with an error of 8%. Later, some religuous crowd came up and claimed that Earth is flat. I encourage you to just ignore those people who claim that Earth is flat and that there is a supposed legal problem with cdrtools. Jörg lol, you're obviously a troll...
Re: [arch-general] Recent telepathy-butterfly upgrade breaks MSN connection?
On 23/05/10 04:15, Ye Li wrote: Hi guys, Anyone met problems after the recent upgrade of telepathy-butterfly? In my box most of buddies are marked *offline* although they are actually online. Even oddly, downgrade telepathy-butterfly to 0.5.9-1 cannot solve the problem. So I'm wondering if this is a problem caused by the new butterfly package? Or something wrong else(e.g. MSN server problem). Thanks sincerely. Best Regards -- Ye LI if you downgrade you need to kill the daemons? otherwise you'd prolly still be using the old version. just look for telepathy- in the running processes, either kill it or a log-out/in should get rid of them.
Re: [arch-general] Arch shutdown because of firefox
On 11/05/10 13:59, Thomas Bächler wrote: Am 11.05.2010 14:56, schrieb Handsome Cheung: yes, I run hal, but don't use display manager. Your answer inspired me, and I will check something about hal immediately. Thanks! Even if the user is allowed to use hal to initiate a shutdown, it would still be necessary to exploit a security weakness in firefox that would allow an attacker to execute arbitrary commands. And a matching exploit would have to be on any website that triggers the shutdown ... this all sounds very unlikely. I'm willing to bet that this is no exploit ad in-fact a bug at some point in the stack. A couple years ago I found I could almost crash xorg at will with my questionable C code(I was just learning C) and a couple time the xorg crash resulted in a reboot/shutdown. Does it persist with another xorg driver?
Re: [arch-general] Err... Why is gvim now conflicting with vim?
On 07/05/10 15:48, Burlynn Corlew Jr wrote: On Fri, May 7, 2010 at 4:04 AM, Johannes Heldm...@hehejo.de wrote: http://www.archlinux.org/news/495/ * If you have gvim installed, the update will inform you that vim conflicts with gvim. This is the expected behavior. Installation of vim and gvim separately is no longer required, the gvim package now installs vim as well. -- Gruß, Johannes http://hehejo.de This is a rolling release, not an LTS. There is no excuse to not be updating regularly and reading the news. If its a production machine and you are worried about breakage maybe you shouldnt be running arch on it. The ML, forums, and irc are full of people who refuse to read the news or update regularly, and we all waste time answering questions that with proper arch maintenance would ensure that they never come up. Really dude? you complain about him wasting time when you could find the time to dig up some old mail that was answered ages ago to attack the guy for asking questions? I'm sure we can all agree that it's important for an Arch user to be more independent and put more effort into solving our own problem but did you know you can simply ignore any of these questions? It doesn't take any effort since the bulk of the issue was already in the title. To be honest I simply cannot take this kind of negativity. I would really like for this kind of attitude to stay away from Arch because it's not nice and it's the very thing I hate about the Linux community in general.
Re: [arch-general] Err... Why is gvim now conflicting with vim?
On 07/05/10 17:10, Burlynn Corlew Jr wrote: On Fri, May 7, 2010 at 10:54 AM, Nathan Waydekum...@konnichi.com wrote: On 07/05/10 15:48, Burlynn Corlew Jr wrote: On Fri, May 7, 2010 at 4:04 AM, Johannes Heldm...@hehejo.de wrote: http://www.archlinux.org/news/495/ * If you have gvim installed, the update will inform you that vim conflicts with gvim. This is the expected behavior. Installation of vim and gvim separately is no longer required, the gvim package now installs vim as well. -- Gruß, Johannes http://hehejo.de This is a rolling release, not an LTS. There is no excuse to not be updating regularly and reading the news. If its a production machine and you are worried about breakage maybe you shouldnt be running arch on it. The ML, forums, and irc are full of people who refuse to read the news or update regularly, and we all waste time answering questions that with proper arch maintenance would ensure that they never come up. Really dude? you complain about him wasting time when you could find the time to dig up some old mail that was answered ages ago to attack the guy for asking questions? I'm sure we can all agree that it's important for an Arch user to be more independent and put more effort into solving our own problem but did you know you can simply ignore any of these questions? It doesn't take any effort since the bulk of the issue was already in the title. To be honest I simply cannot take this kind of negativity. I would really like for this kind of attitude to stay away from Arch because it's not nice and it's the very thing I hate about the Linux community in general. First off it wasnt mail, it was headline archlinux.org news. Secondly, for me to expect people to use the resources Arch provides to resolve issues is not crazy, and this is one issue among many dealing with the same thing. If you refuse to read and stay updated why should any of us bother with helping? Its spam that could be avoided with proper practices. We are not here to babysit. If you dont like the principles arch runs with, use another distro. That is not negativity but an expectation that you are using the distro the way it is intended. congrats guys.
Re: [arch-general] gstreamer0.10-good-plugins need a whole load of GNOME stuff?
On 21/04/10 09:28, Ananda Samaddar wrote: On Tue, 20 Apr 2010 21:26:33 -0500 David C. Rankindrankina...@suddenlinkmail.com wrote: It still amazes me how people will take the position that all associated with Gnome must be 'crap'. No don't get me wrong, I have no arguments with your basic complaint that unnecessary dependencies need not be included with the gstreamer packages. In fact, I agree. However, that notwithstanding, the general premise asserted in the comment GNOME crap is just flat wrong. Now I was a KDE guy, did a lot of beta work with KDE4 and also enjoy enlightenment, the 'boxtops', windowmaker and recently Gnome. From first-hand experience, I can tell you gnome is not crap. It is a solid desktop built on the metacity wm that does a great many things right and a handful of things I would do differently if I wrote desktops and wm's, but on balance is an excellent desktop. Not to mention, it is just down right gorgeous: (152k) http://www.3111skyline.com/dl/img/ss/gnome/BlueNightII.scaled.jpg Oh well, at least the gstreamer packages stripped of unnecessary dependencies will be a great addition to AUR. Thank you for that. But no need to deride a desktop just because whoever packaged it last included a few unneeded dependencies :p Yes it was an unfortunate choice of words. I don't think GNOME is crap, I'm just not enamoured with the direction it seems to be headed in, i.e. GNOME Shell. I can do without shiny stuff like that. Previous to my switching to XFCE I was a GNOME user for a very long time. I reckon GNOME 3.0 will be just as much of a PR nightmare as KDE4 was and continues to be. It frustrates me that core technologies can depend on a long list of dependencies for another desktop environment. Try installing gstreamer0.10-plugins-good if you're not running GNOME and you'll see what I mean. Ananda Do you mind listing these Gnome dependencies, or at least your proposed PKGBUILD? I've looked at this and I can see only 2 (gconf and libsoup-gnome). Ofcourse that is based on the assumption that the pacma dependencies are correct(e.g good-plugins depends on x,y,z but only x is listed because it also depends only y and z).
Re: [arch-general] gstreamer0.10-good-plugins need a whole load of GNOME stuff?
On 21/04/10 10:52, Jan de Groot wrote: On Wed, 2010-04-21 at 10:35 +0100, Nathan Wayde wrote: Do you mind listing these Gnome dependencies, or at least your proposed PKGBUILD? I've looked at this and I can see only 2 (gconf and libsoup-gnome). Ofcourse that is based on the assumption that the pacma dependencies are correct(e.g good-plugins depends on x,y,z but only x is listed because it also depends only y and z). The GNOME dependencies involved: libsoup-gnome libgnome-keyring (gnome-keyring) gconf orbit2 libidl2 I don't consider this as a big problem, and I closed bugs about it before. The libsoup-gnome library adds proxy lookup and password lookup functionality to libsoup. GStreamer can work without it, but it will lose quite some functionality without it. The gconf*sink elements in GStreamer need gconf. Without this, there's no way to configure the audio and video element in a central place. Some applications even ask for this specifically. I listed the gnome-keyring dependency as optional, as it's a fake dependency added to libgnome-keyring. libgnome-keyring needs a keyring daemon, AFAIK the next version of KDE will also get one. In the future, GNOME applications using libgnome-keyring can read passwords from KDE password storage. Libidl2 isn't a big issue either, as firefox already depends on it. I haven't seen much Arch Linux desktop installations without firefox. Note that the hal plugin will get removed soon. The only application I know that could have benefit from this plugin is cheese, but that has been ported to libgudev since 2.30.0. I'm guessing that's still only 2 *direct* dependencies and the number of indirect dependencies is surprisingly low from what it sounded like. I guess I jut don't see the big deal(I prefer Gnome, but prefer programming in Qt more than Gtk et al.). This is somewhat similar to people raging that won't use xyz because it depends on Gnome, when the only dependency is glib(which is prolly on their system through Qt anyway).
Re: [arch-general] packman -S eterm [done] But: bash: eterm: command not found ????
On 20/04/10 03:56, Joe(theWordy)Philbrook wrote: Could be I'm missing something here... But shouldn't 'pacman -S eterm' put executable somewhere in the standard path??? This was done using a root shell in a konsole terminal under E17 on my recently updated Arch installation... I did search the wiki for eterm just in case there was something about eterm that requires more than a simple pacman install. Didn't find anything useful. Am I missing something obvious here??? Yeah, `pacman -Ql eterm | grep bin/`. The binary is Eterm (upper-case e)
Re: [arch-general] manage starting and stopping processes with less typing
On 13/04/10 20:50, Linas wrote:
David C. Rankin wrote:
Guys,
One thing I miss with Arch are init-script shortcuts for starting and
stopping
processes. rc-commands really help cut down on typing. For example, all suse did
was to create links to the files in /etc/rc.d/... with a naming convention of
rcinit script name. So, for example, instead of having to type:
/etc/rc.d/postfix
the shortcut was simply
rcpostfix
I have normally seen the sym-link shortcuts placed in /usr/sbin, but
/usr/local/sbin works fine as well. The convenience is addictive. If you manage
your box from the command line or want to, then you can give this setup a
testdrive. You can create the sym-links very easily with the following cut and
pasted to the command line (as root - all on one line):
for i in $(ls /etc/rc.d); do [[ -e /etc/rc.d/$i ]] [[ ! -h /usr/local/sbin/$i
]] ln -sv /etc/rc.d/$i /usr/local/sbin/rc${i}; done
No need to create one symlink per file.
You can just add rc() { /etc/rc.d/$*; } to the user profile to
automatically be able to do:
rc postfix start for any script you have or ever add.
To have autocompletion with your new command, also add:
complete -o filenames -W $(cd /etc/rc.d/ echo *) rc
here's my rc script, no need for completion IMO when you can just type:
`rc r l~pd` to restart lighttpd
#!/bin/sh
WC='~'
if [ $# -ne 2 ]; then
echo usage: OPERATION PATTERN
echoOPERATION can also be one of: k(stop), r(restart),
s(start)
echoPATTERN(grep -E ^PATTERN$) where $WC is replaced with .*
exit 1
fi
case $1 in
k) opr=stop
;;
r) opr=restart
;;
s) opr=start
;;
*) opr=$1
esac
if [ $opr = ]; then
echo error: no operation specified.
exit 1
fi
pat=$(echo $2 | sed s/$WC/.*/g)
rc=$(ls /etc/rc.d/ | grep -E ^$pat$)
mat=$(echo $rc | wc -w)
if [ $mat = 1 ]; then
sudo /etc/rc.d/$rc $opr
elif [ $mat = 0 ]; then
echo error: no targets found.
else
echo error: multiple targets found:
for t in $(echo $rc); do
echo$t
done
fi
Re: [arch-general] Apache dead after kernel update - make_sock: could not bind to address [::]:443 - (Solved by 2nd Reboot)
On 12/04/10 07:53, David C. Rankin wrote: Guys, I don't know what's up here, but I updated the system ( no [testing] ), and rebooted to load the new kernel, and http was dead. On start, the error said it couldn't bind to port 443 because it was already taken -- Huh? Here are what little details I could come up with: [23:28 nirvana:/home/david] # lsof -i | grep 443 I'm not sure what could have happened there but, to see what's running on a port, you'll want to use netstat instead: `netstat -ntpl | grep :443` you may need to run as root in order to see the process name but it should at least show you if something is listening on a particular port.
[arch-general] Xz, space savings and delta ... my findings
Here's one for ya. Decompress a gzip'ed package, say pacman. Now, recompress every file in that directory with `xz -1`, smile :) Result: the re-compression is faster than a tar+gz and in each case so far(kerne26, gcc, perl, pacman, kdelibs) is a little smaller as well. It doesn't approach the (much smaller) size of tar+xz but it does take less time to compress and is smaller than what we had before. I know, you're thinking why do that. I wanted to implement an idea for the A.R.M, which is basically to allow downgrade on a file-by-file basis, my theory is that most(many) of the files in 2 versions of a package (esp. when they are minor versions or pkgrel bumped) are often exactly the same. My test involved kdelibs-4.3.98-1 and kdelibs-4.4.0-3. I first decompress both, and remove the duplicates from kdelibs-4.4.0-3 which results in sizes of 59.5MB for the original kdelibs-4.3.98-1 and 35.5MB for the de-deduped kdelibs-4.4.0-3. Now recompressing with `xz -1` kdelibs-4.4.0-3 is brought down to 10.7MB. Comparing with the delta (between the original packages) which 5.3MB it's not a whole lot while allowing more flexibility(IMHO). Some more numbers for comparison, the tar+xz(level -6) for kdelibs-4.4.0-3(de-duped) was 8.4M in comparison to tar+gz which was 12.6MB the original tar'd sizes were 19.8MB for gz and 13.9MB for xz. I know I didn't test based on pkgrel or try gz(as opposed to xz -1) only nor did it very scientifically but I thought it was very interesting non-the-less. I also suspect that the similar results would be seen for a test with xdelta on each file but that's not very useful to me so I'll leave that one for another day.
Re: [arch-general] Xz, space savings and delta ... my findings
On 01/04/10 14:03, Dieter Plaetinck wrote: On Thu, 01 Apr 2010 13:54:56 +0100 Nathan Waydekum...@konnichi.com wrote: Comparing with the delta (between the original packages) which 5.3MB it's not a whole lot while allowing more flexibility(IMHO). I don't see the point. with binary delta's you get smaller packages and getting the non-changed files again doesn't really cause harm, does it? In other words: what useful things does this approach allow you to do that we cannot do right now? My use-case is for the downgrade scenario where you have upgraded, then later you realize there is some problem and you no longer have any old packages. Now, in theory I could simply rebuild the pkg with local files thus saving the large download. But what would be the point if I can simply get the files I need.
Re: [arch-general] Btrfs more than twice as fast compared to ext4
On 16/03/10 00:48, Shridhar Daithankar wrote:
[...]
But as far as file system performance goes, the overhead should be identical
for both the runs, no?
I'm not too sure about that. I'm guessing there is less seeking going on
with Btrfs. Some files systems (reiserfs + reiserfs4 IIRC) are very good
with many small files, better than the ext*fs, this may be another case
of that.
Besides, I need to run the comparison(rather verification of file contents)
many times over during the application life-cycle and I cannot afford to bring
in another copy from disk. The working set is expected to be 30-40GB at a
time, 3GB is just test setup.
With md5sum, I can store it in database and verify it on one copy only.
Fair enough.
And finally, it is terrible on timings. Running md5sum is lot faster, about 3
times in the best case.
[...]
wow, that's slow!
So when the source file system is btrfs, it is still couple of times faster at
least.
I still think you could achieve better times by not calling the external
command that many times.
Since you're already gonna store the checksums in a database, I'd just
write a proper program in python or something.
Or even just a shellscript, but you might wanna refrain from for .. in
`find .. , it's the slowest and that relies on the fact that your
filenames don't have spaces in them.
[[ky] ~]# }} time find /usr/bin -type f -print0 | xargs -0 md5sum /tmp/1
real0m3.633s
[[ky] ~]# }} time find /usr/bin -type f -exec md5sum {} \; /tmp/2
real0m10.196s
[[ky] ~]# }} time for i in `find /usr/bin -type f`;do md5sum $i;done
/tmp/3
real0m11.245s
this last version missed a file because it has spaces in its name and as
result the file 3 was inconsistent with files 1 and 2
[[ky] ~]# }} diff /tmp/{1,2}
[[ky] ~]# }} diff /tmp/{3,2}
3054a3055
0c5d8f10aa0731671a00961f059dc46e /usr/bin/New SMB and DCERPC
features in Impacket.pdf
that was a test against just 4008, so you can imagine time savings with
5+ files.
Re: [arch-general] A suggestion for the devs regarding rebuilds
On 10/03/10 20:03, clemens fischer wrote: [...] Ironically, if pacman was such a tidy package manager and devs were so keen to keep things that way, why is there ever any output in pacman -Qdt? clemens Could it be because you explicitly requested that? i.e `pacman -R pkgname` which removes that pkg and that pkg only, see `pacman -Rh`.
Re: [arch-general] svn packaging, abs = git ?
On 07/03/10 21:34, f...@kokkinizita.net wrote: On Sun, Mar 07, 2010 at 10:24:42PM +0100, Xavier Chantry wrote: [...] And in 95% of the cases, I do not need any history, I just need the last version to read/edit/rebuild. Yes, with git you get the full history. I've still not grokked why that is the only option... (except for Linus' motto: if in doubt, do the opposite of svn :-) Ciao, Maybe you're looking for `git clone --depth 1`
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit - tone it down
@Joerg Schilling This is not another attack against you so please to not try and make yourself appear as some kinda of victim here as well. I know it's none of my business replying here, but I feel I need to say something. It's not related to the original discussion, but your attitude. Now, I'll say it up front, I'm not a psychological professional, shrink or anyone qualified to discuss this, but I will put my foot in my mouth anyway. Over this entire thread, you have come off as very aggressive, maybe this has something to do with the language, maybe it's just your personality. You have, dare I say attacked others, presented others in a somewhat degraded light. You do all these things, as far as I can tell, without sufficient reason(e.g calling others hostile when that had nothing to do with the discussion, also see your comments about Arch as well...). Throughout, you have presented yourself as some sort of victim. This coupled with your defensive behaviour is not very good. It leads to you appearing as some kind of troll, or someone whose sole intent is to destroy cdrkit as opposed to getting cdrtools back into Arch. On 30/01/10 07:35, Joerg Schilling wrote: Steve Holmessteve.holme...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 I don't know much about the licenses differences and all that crap but I experienced a problem with cdrecord several years ago where it would not work with my CD burner. I kept getting wiere I/O errors or some such. When I asked around,some people told me about wodim and when I went out and installed wodim, I've been able to burn CDs and DVDs flawlessly ever since. My time with wodim has transpired over Slackware, Debian, and now Arch. I don't know today if cdrecord would still cause me those errors or not but for me, the drkit has been doing me just fine. As you do not give any facts, this is obviously nonsense. No, that doesn't make it nonsense and along with your other favourite words (such as hostile, attacked, victim) your use of it is very appears needlessly aggressive. This kind of attitude leads to bad/buggy software. I know of not a single case where cdrecord fails but wodim succeeds. Obviously you do not because you haven't tested every possible combination of software and hardware here. I can give you a real-life example, NetworkManager, it works great until I attemp to play games, I get a very noticeable lag every so often than ruins online games for me. This issue does not exist, now nor has it ever existed with any other networking tool(netcfg, wicd) some time ago I read about it being blamed on buggy drivers, yet it exists only because of the way NetworkManager does a periodic background scan. You are being introduced to a potential new case here, don't blindly dismiss it. Wodim is nothing than an onl version of cdrecord with bugs added by it't creators that never have been in the original. At this moment in time, I cannot upgrade xorg-xinit from the old 1.1.1-1 to 1.2.0-1 because some scripts breaks and I haven't bothered to look into it. By your logic, this is obviusly nonsense because the newer, less buggy xorg-xinit has no such regressions. If you would give evidence, it would be easy to prove that your alleged problem is not related to cdrecord. Jörg Again, no-one likes a victim. Try not to be so defensive. Look at Pidgin's xfire/gfire plugin, it suffers from bugs and possible security issues because the developers exhibited similar defensive behavior towards me, today I upgrade and fix those bugs as I like without even bothering to report them. Attitude like this drives people away, people with potentially valuable input.
Re: [arch-general] [signoff] kernel 2.6.32.4-1 [ Possible Problems... ]
On 20/01/10 16:51, David C. Rankin wrote: Tobias, all, After further testing with kernel 2.6.32.4-1, I have found two bugs: (1) the kernel upgrade kills WindowMaker (2) the kernel upgrade kills VirtualBox It was ironic, because I was using WindowMaker when I installed the kernel and then on reboot, WindowMaker attempted to start and then crashed back to the login screen. After the upgrade I successfully rebuilt the kernel module for vb with vbox_build_module, then started vbox and it hung with a small dialog spawning session. Let me know what information you want to see and I'll be happy to provide it or file a bug report. Thanks. I can't comment on the WindowMaker issue but the VirtualBox, at least the OSE version(virtualbox-ose 3.1.2-3) released today is fixed.
Re: [arch-general] speaking of Thunderbird 3.X - great new thread summary view
On 15/12/09 09:33, Ng Oon-Ee wrote: On Tue, 2009-12-15 at 09:25 +, Magnus Therning wrote: 2009/12/15 Ng Oon-Eengoo...@gmail.com: On Tue, 2009-12-15 at 07:46 +, Nathan Wayde wrote: On 15/12/09 07:40, Ng Oon-Ee wrote: Hmm, it just shows ... for me for all messages. top-left near the 'Subject' header, the button?/header with the icon that looks like a lower-case t, to the left of the star header - click it. You mean the 'expand thread' triangle? That's not it, that just expands the thread to a view identical to in Thunderbird2. I'm unable to get a '3-4 line preview' view on any of my mails, as in the picture by the first poster in this thread. Unexpand the thread, then click on the first message, it should result in that view. It does, but every line just shows like this:- Poster 1 Date ... Poster 2 Date ... And so on. I'm getting the correct view, what I'm not getting is the '3-4 lines' talked about. Oh, sorry I misread... It doesn't display '3-4' lines, it's the first sentence or so, you see 3-4 lines because of the screen width.
Re: [arch-general] speaking of Thunderbird 3.X - great new thread summary view
On 15/12/09 07:40, Ng Oon-Ee wrote: Hmm, it just shows ... for me for all messages. top-left near the 'Subject' header, the button?/header with the icon that looks like a lower-case t, to the left of the star header - click it.
Re: [arch-general] Making pacman check multiple repos
On 13/12/09 08:48, Ng Oon-Ee wrote: On Sun, 2009-12-13 at 03:31 -0500, Qadri wrote: So should it be a function of the program to make sure that happens? Or is a responsibility of the user? Should the functionality be programmed into pacman to make sure that happens, or should we be asking that users be aware of what repos they're using? Well said, I agree. I believe that if separate db and package downloads are implemented it should not be so users can be 'up-to-the-minute' in packages, but for greater security. In fact, now that I think about it, having two dbs (one on the mirror with all packages as available on that mirror and one 'master' with a list of authoritative checksums) would make sense, as it fulfils the security aspect well while avoiding the problem of db/package mismatch. The 'master' db would have to have a history of previous checksums as well. One possible alternative to explicitly storing a history of checksums is to checksum the dbfile, and name it as such. instead of core.db.tar.gz, you'd have have core.[checksum].db.tar.gz and these would be stored for some time on the master. In order to make it secure the standard checksums would have to be upgraded to something with less collisions than md5. Of-course this also raises the question of 'what happens when the master goes down?'.
Re: [arch-general] [OT] What is wrong with DBus anyway?
On 03/12/09 18:14, Arvid Picciani wrote: [...] I'll add some additional points: - it's implementation is large broken. how so? - most software depending on it, will crash when dbus file bug reports and get developers to write proper software. crashes, or fail to start uncracefully, or behave unexpected. i've honestly never seen dbus crash but then again i've experienced almost none of the issues people often complain about with Linux - some systems are actually not supported by hal while they are by udev and have system-v IPCs. got nothing to do with dbus - reinventing the wheel and calling it super-boat-2000 isn't going to help anyone. Instead of fixing problems, people constantly create new ones. lol - FDO is hierarchic and polical level. what Dbus is hierarchic on technical level. FDO wishes to provide a better experience to users by integrating all software nicely into one global truth. The Foss ecosystem is not hierarchic. The Foss ecosystem does not require a single truth to rule them all. The Foss ecosystem does not require to be competitive with OtherOs. what does any of that have to do with dbus in a technical sense? -- Arvid Asgaard Technologies
Re: [arch-general] [OT] What is wrong with DBus anyway?
On 04/12/09 02:27, Arvid Picciani wrote: [...] Let me illustrate the problem here by construction an argument with a similar flaw: The mouse is inflexible and should be deprecated, as a stylus has the advantage of being cordless. All modern pointing devices should be cordless and i think these mouse users are just from the 60s. You do realise that your argument makes no sense right?
Re: [arch-general] peaceful suggestion to clarify the arch way to avoid this to happen AGAIN
On 03/12/09 23:49, Arvid Picciani wrote: Heiko Baums wrote: Show me a more minimalist distribution than Arch and Gentoo. I guess you won't find one. And if you did I suggest you switching to this distro. This is the entire reason i want arch to officialy state that these users are not welcome. I want to move on, so we can split up the user bases. Ultimately so both sides can continue their life without the constant (and i'm meaning constant. this isnt the first time this discussion exploded) need to reevaluate if arch should do this or that. If Arch doesn't fit your needs then choose another distro or build one by yourself. It's done. All i want is to settle this in a useful way. I originally identified you as a poisonous person and you just keep confirming my theory.
Re: [arch-general] Another rant on arch way abuse and false promises
On 02/12/09 07:38, Arvid Picciani wrote: Ray Kohler wrote: What I personally am in support of, in the general case, is suckless.org-style minimalism, rather than following upstream's direction. So if upstream changes the default to enable the hal and dbus bits, I will then be in favor of Arch disabling them, and we'll be in disagreement then. (That said, if that actually does happen, I won't asking the Arch devs to implement my wishes, since they'd clearly be in violation of the Arch way.) Indeed. As brought up by others, forcing minimalism is as much violation as forcing bloat. However, arch has been built around the idea that users are capable of customizing packages to non-upstream settings. I urge you to do exactly that. I have posted and will continue to post various bugs to the tracker to restore upstream defaults in favor for minimalism. If these reverts get rejected in favor for bloat, the clear bias is a disregard of the very core ideas of arch, and I will eventually fork arch entirely, given enough support. Either way, i'd welcome if you contribute, in order to get the user experience you (and others including me) desire. That is, either contribute packages to aur, to fix insane upstream defaults, or contribute to an eventual fork to restore upstream defaults. Will you? :) Let me just leave this right here. http://www.youtube.com/watch?v=-F-3E8pyjFo
Re: [arch-general] conclusion: Another rant on arch way abuse and false promises
On 02/12/09 09:55, Arvid Picciani wrote: Thanks to enough input i have learned two things of this thread: 1) The problem IS upstream related. Some packages do enable dbus when it is available, for the convenience of those users who do not understand what dbus is and hence need it. Archs philosophy dictates, that if the upstream is retarded, so shall be the package. I used this as argument, and i shall comply to it equally. 2) I am in fact the minority, not those who see linux as a free windows copy. Hence i should 2.1) stfu and obey the will of the mass 2.2) find or found a distro that is not based on the will of the mass The combination of 1 and 2 invalidates everything i have said in this thread. Jan did a great job at packaging clearly broken packages in the least harmful way for the majority of users, who happen to have a microsoft windows background. Sorry about being too ignorant to see these in the first place. I'll go do 2.1 or 2.2 now. have a nice day. lol, i didn't see that one coming.
