Re: [arch-general] opinion request about Firefox add-ons
On Sun, 31 Jan 2016 19:25:56 +0100 Ralf Mardorf wrote: > For me duckduckgo is completely useless. You never use '!archpkg firefox' or '!archwiki firefox'? The nice thing about duckduckgo is the use of bangs (and for me that i don't need to remember the original url :) ). > However, I'm not talking about the Google search engine, but about > "safe browsing" and other Google features used by Firefox. If you want to spend some time with reading: http://www.ghacks.net/2015/08/18/a-comprehensive-list-of-firefox-privacy-and-security-settings/ See you, Attila
Re: [arch-general] Shutdown and reboot not working after last weekend update
Hi, I am not familiar with the problem, but I think the easiest way (if you are not against graphical tools) is to grab a live cd (or "live usb dongle") containing gparted (it's not a bad thing to have, anyway), but I am not an expert at this. What really surprises me is that you use your system as root !?! I would not dare to do that. I tend to add my user to various groops according to the arch wiki documentation where neeeded, and for the other commands I think I can safely run as root I alias them to be 'sudo ', and I maintain this list of safe commands in /etc/sudoers (edited by visudo (you can change the editor of it, just google it)), so that these commands can be executed without entering the password all the time... Maybe not the best thing still, but I guess it's OK with me. Regards, Attila 2012/6/12 Victor Silva : > Folks after the last upgrade I can no longer shutdown nor reboot my machine > (I'm using it as root). The command simply hangs and nothing happens. > I was asked to perform a fsck which failed.It reported /dev/sda5 was > mounted. Is there any proper way I should use to call fsck? I did create a > /fsck file on / is there other more appropriate command to do it? Problably > you asked for my fstab expecting an error like this right? Would it be > better to run fsck from a livecd? > > regards, > > Victor
Re: [arch-general] Change Arch's default crond
On Fri, 08 Apr 2011 00:34:42 +0200 Sven-Hendrik Haase wrote: > cronie also appears to be the nicest migration choice for users who > are not used to fcron. It seems to support anachron features, cron.d, > daily/weekly/etc, is able to actually keep time and works just like > expected whereas fcron has fcrontab with a slightly different syntax. > We could actually make cronie replace dcron. I agree with this instead i'm a fcron user. But because it is say so much often, is there really anyone who have something in /etc/cron.d? See you, Attila
Re: [arch-general] Change Arch's default crond
On Thu, 7 Apr 2011 00:29:36 +0200 Heiko Baums wrote: > > cronie extends the original vixie cron package so the syntax, core > > feature set, etc are stable > > cronie implements advanced security hooks as well and can integrate > > with SELINUX (I am saving the "include SELINUX support in base for a > > latter date") > > Well, is SELinux really a default? Does SELinux run on Arch at all? Is > this really an argument regarding the decision which cron shall be the > default. Only for the stats, this is shown from the fcron configure: --with-selinux=yes|no Use (or not) SELinux (default: yes). Okay, now only the size and the "/etc/cron.d" support is on the list. :) See you, Attila
Re: [arch-general] Dropping Oracle OpenOffice
On Wed, 9 Mar 2011 02:01:25 -0500 (EST) Jude DaShiell wrote: > libri-openoffice-supported and all oracle-openoffice packages > oracle-openoffice-unsupported. Debian at any rate has a playground > area Before doing this i suggest to name it: needless_sh**_for_non_latex_users_bought_from_the_dark Sorry your your assist was too good :) See you, Attila
Re: [arch-general] knotify4 is eating 90%+ of the CPU in gnome - can it be reniced or something?
On Wed, 02 Mar 2011 16:37:30 -0600 "David C. Rankin" wrote: >Running Gnome, knotify 4 is killing my system. From top, it is > taking over 90% of the cpu: > > 13123 david 20 0 155m 40m 17m S 91 1.3 60:06.32 knotify4 > >Can this 'feature' be turned off when I'm in a desktop other than > kde4? > It is a service (see /usr/share/kde4/services/knotify4.desktop) which should be possible to control from systemsettings. I'm not sure if it is possible to deactivate it only then if you use another WM because a lot of kde apps writes their information over this interface and this could be more the reason that it starts. But on the other side if i see your cpu load than deactivating could be even better.-) See you, Attila
Re: [arch-general] kde4 loads kde3 parts -- is this a packaging issue?
On Sat, 26 Feb 2011 13:17:14 +0100 Lukáš Jirkovský wrote: > Just a guess – maybe the cache is shared for both KDE 4 and Trinity > and it results in loading the session of both. It should be in > /var/tmp, maybe there is something in /tmp too. There be even directories from kde3/4 in /tmp and in /var/tmp. But starting with runlevel 3 and delete all kde things in both directories could never be wrong. :) See you, Attila
Re: [arch-general] [trinity-devel] x86_64 kdesktop.kcrash [SOLVED - it is glibc]
On Thu, 24 Feb 2011 11:38:42 +1000 Allan McRae wrote: > If this is virtualbox specific, I'd try qemu-kvm. If you want to do this than this can save your time: http://blog.bodhizazen.net/linux/convert-virtualbox-vdi-to-kvm-qcow Personally i would use qed with the new qemu-kmv 0.14.0 instead of qcow. But the handling with virtualbox is easier so David see this only as an information and not as an suggestion. See you, Attila
Re: [arch-general] vi dependency mailx - why not mailx-heirloom?
At Donnerstag, 17. Februar 2011 21:30 David C. Rankin wrote:
> Just a quick question on the vi dependency of mailx. Why not mailx-
heirloom? It
> provides a great deal more capability with attachments, and flexibility as a
cli
> mailer. The issues is down in the noise, but why drive a pinto if you can
drive
> a jag?
Okay, i'm not a dev, but mailx-heirloom provides mailx "provides=('mailx')" and
therefore all shoould be fine. I myself ask me more why there is not conflicts
array in the PKGBUILD of mailx-heirloom. :)
See you, Attila
Re: [arch-general] is udev-164 a safe solution at the moment
At Donnerstag, 20. Januar 2011 10:38 Thomas Bächler wrote: > Some people actually tracked down the kernel bug that is causing this, > but nobody opened a bug report about it upstream. If this is the same > bug I heard about, a workaround is deleting /lib/udev/ata_id. Thanks for the hint and i move ata_id to another place. I think the biggest problem for writing a bugreport is that this happens very, very seldom. See you, Attila
[arch-general] is udev-164 a safe solution at the moment
Hi, still again after every 20 or 30 new boot udev-165 hangs both pc's with archlinux. So my question is that if i step back to udev-164 will there be problems with the initscripts or any other plans what you the devs have in the near future? If yes than i can (or have to) live with this because it is very seldom and therefore very hard to find out what is the problem. See you, Attila
Re: [arch-general] When will Arch switch to Upstart
At Mittwoch, 19. Januar 2011 22:45 Ionuț Bîru wrote: > We should really stop this. The OP doesn't have any interest to > participate to the discussion. In 12 hours he didn't replied to any of > your ideas, clearly he is a troll. Only for the stats: If he, the OP, has asked before work (or a business date) to have the answer(s) if he is back than 12h be not very long.-) See you, Attila
Re: [arch-general] kernel 2.6.37 BKL
At Samstag, 8. Januar 2011 01:17 Karol Babioch wrote: > You shouldn't let this any gamer hear, although most of them are > properly using windows for that ;). I don't think that using UDF with DVD-RAM is only important for gamer.-) See you, Attila
Re: [arch-general] Testing kills shm and pts
At Montag, 13. Dezember 2010 23:07 jesse jaara wrote: > Reproducing is as simple as just rebooting the pc and the permissions > are broken and shm is mounted whit beautiful size of mere 10 mb and it > used to mount whit a size of 1.4G :D (it broke my chromium profile :( as it > didn't fit in there ) The permissions makes me wonder because with my line devpts /dev/pts devpts defaults 0 0 the permissions of /dev/pts looks like this # ls -l /dev/pts/ insgesamt 0 crw--w 1 user tty 136, 0 14. Dez 06:02 0 crw--- 1 user tty 136, 1 14. Dez 07:28 1 crw--- 1 user tty 136, 2 14. Dez 07:28 2 crw--- 1 user tty 136, 3 14. Dez 07:41 3 [root ~] # ls -l -d /dev/pts/ drwxr-xr-x 2 root root 0 14. Dez 06:00 /dev/pts/ # grep pts /proc/mounts devpts /dev/pts devpts rw,relatime,mode=600 0 0 > Il try to add those options and the size option too to the fstab and see if > that helps, hopely this won't eat my chromium profile again :D Only as an info for an alternative: I never used /dev/shm for this and prefer to do such things in /tmp to seperate it and here my lines in the fstab: shm /dev/shm tmpfs defaults,rw,nosuid,noexec,size=32m 0 0 tmpfs /tmp tmpfs defaults,rw,mode=1777 0 0 All my favorite browser (opera, firefox and chromium) have their cache inside of /tmp but i don't use a script for copying the profile. Good luck, Attila
Re: [arch-general] [arch-dev-public] nilfs-utils moving in core
At Mittwoch, 8. Dezember 2010 05:45 Loui Chang wrote: > Ask Microsoft to support every filesystem in existence on their standard > install CD and core system and maybe us poor Archers with our limited > time and budget can also rise to your stratospheric expectations. Bad example because MS offers only two filesystem and a better example of a bad installer from a big company is the one from redhat (+ the forks of it) because with this you can't format all filesystems (and more worse it is that the default kernel don't support this filesystems too). The archlinux installer do in this case a very good job from my memory. At the time of installing archlinux i have had the choice of all what i want and to have the *utils from the filesystem on the cd too would be very nice. And just my 2c about the example of btrfs: Without a fsck i would never take a look at it instead of the very good reports about it be very attractice. See you, Attila
Re: [arch-general] [arch-dev-public] [extra] repository cleanup
At Sonntag, 14. November 2010 22:07 Eric Bélanger wrote: > There's already RSS feeds with that information (maybe not as compact > as you want) : > > http://aur.archlinux.org/rss.php > http://repos.archlinux.org/wsvn/packages/?op=rss&isdir=1 > http://repos.archlinux.org/wsvn/community/?op=rss&isdir=1 Thanks a lot. I don't know about number 2 and 3 but this informations be very helpfull ( and more than i want but i said 'without too much extra cost' :) ). See you, Attila
Re: [arch-general] [arch-dev-public] [extra] repository cleanup
At Samstag, 13. November 2010 17:32 Heiko Baums wrote: > And I have nothing against cleaning up a repo. But this should be done > more considered. Means only unimportant, unpopular packages or packages > which don't run anymore should be moved to AUR or removed completely but > not packages which likely belong to the most popular ones. +1 For to consider more. With only a message with the link to a wiki list it is very easy to oversee something and more important there is no information about to what for a certain time it will be done. I have not anything against having more (or less) applications from aur but i was a little bit surprised as my favorite editor for the console joe get throwed out of extra. So i ask for the possibility of having a RSS Feed (or a web page) with at examples such lines 2010-11-10 joe -> OLD REPO: EXTRA NEW REPO: AUR 2010-11-10 appXYZ -> OLD REPO: EXTRA NEW REPO: NULL 2010-11-12 libXYZ -> OLD REPO: COMMUNITY NEW REPO: EXTRA Is there any change that this could realize without too much extra cost? See you, Attila
Re: [arch-general] Opencl/Cuda headers
At Freitag, 12. November 2010 18:34 Stéphane Gaudreault wrote in gmane.linux.arch.devel: >> It seems the Cuda/OpenCL/vdpau headers are back in nvidia-utils version >> 260.19.21-1. >> >> Stéphane is happy again :-) > > Sorry for the noise, I was misled by a post on the Nvidia forum. The changelog > still say (see bellow) that the headers are no longer packaged with the > driver. The only headers which be included in 260.19.21 are the opengl headers and the default is to not install them: --opengl-headers Normally, installation will not install NVIDIA's OpenGL header files; the OpenGL header files packaged by the Linux distribution or available from http://www.opengl.org/registry/ should be preferred. However, http://www.opengl.org/registry/ does not yet provide a glx.h or gl.h. Until that is resolved, NVIDIA's OpenGL header files can still be chosen, through this installer option. And i can't find (vdpau.h and vdpau_x11.h) or (cuda.h, cudaGL.h, cudaVDPAU.h, cl.h, cl_gl.h, cl_platform.h) if i extract the NVIDIA installer. I think your plan is so good as before and the README be right. See you, Attila
Re: [arch-general] Replace dcron once again?
At Freitag, 12. November 2010 02:26 Alex Matviychuk wrote: > This is from a Linux From Scratch readme here: > http://www.linuxfromscratch.org/hints/downloads/files/dcron.txt I would prefer this info: http://www.gentoo.org/doc/en/cron-guide.xml Here you can see that dcron is the first option in gentoo too and so the decision of installing it from the arch devs seems okay. If there is a bug than this could happens in every application and should be only a problem if there is no solution for it. And again i'm a satisfied fcron user but i enjoy that we have the choice in arch linux ... which is not normal because some distributions ships only one cron and only this one could discuss about replacing. :) See you, Attila
Re: [arch-general] Replace dcron once again?
At Donnerstag, 11. November 2010 20:16 Sven-Hendrik Haase wrote: > So, not a mail since a while. Can we replace dcron now? :) What i don't understand is this "replace" here because fcron (or incron) is only one "pacman -S" away. And i say this as an fcron user. :) See you, Attila
Re: [arch-general] New nvidia driver - video mode not recognized - remove vga= from kernel line?
At Freitag, 29. Oktober 2010 22:36 David C. Rankin wrote: > Do you (all) think this needs a bug opened? There must be a reason why, but > given the lack of chatter I have seen about it, it must be fairly rare. Dunno if > it is worth chasing. Arch-dev thoughts? More for upstream than for achlinux and perhaps it will very hard to find it. Some time ago i switched from 791 to 0x317 because of the same reason as you now. It seems for me normal user that one of this 2 ways works even better than the other. I would say that you can save your time and enjoy that it works now again. See you, Attila
Re: [arch-general] New nvidia driver - video mode not recognized - remove vga= from kernel line?
At Donnerstag, 28. Oktober 2010 13:19 Heiko Baums wrote: > And you need to decide whether you want to use KMS or not. If you want > to use KMS you need to remove the vga kernel parameter. Otherwise you > need to add the two kernel parameters vga and nomodeset (both of them) > to the kernel line of your bootloader. I don't have nomodeset but "blacklist nouveau" in one of the files from /etc/modprobe.d. This works too. See you, Attila
Re: [arch-general] Screen goes black after installing latest nvidia driver
At Montag, 25. Oktober 2010 22:24 Ionuț Bîru wrote: > maybe you misunderstood me or i suck at explanations. Not all cards are > affected and even the same chipsets. In some situations, no idea what > are those, the new nvidia driver doesn't work. > > for example there is one guy with sony vaio laptop in the forum which > has 8400 GT and has black screen. Others that have 84000 GT doesn't have > this issue Okay, if this is the hardware than the only thing what i can help is to say that this cards makes no problem for me: 6200, 7600GS, G210 and GT220. But this is not good because the 8400 is a nice card und should be supported from nvidia in a better way. > i'm too lazy to search for black screen now but is not on the front page > as this issue was reported since the beta I was hoping you have the link because for using the search function of the nv forum i even have to search my glasses.-) See you, Attila
Re: [arch-general] Screen goes black after installing latest nvidia driver
At Montag, 25. Oktober 2010 15:51 Ionuț Bîru wrote: > congrats, you found a bug in nvidia driver. I've saw a lot of users > having this issue on nvidia forum but not a single reply from nvidia devs. I don't have this problem so saying it is "only" a bug of the driver sounds too easy for me. Perhaps it would be better if people with this problem compare their configurations. > take a look yourself: http://www.nvnews.net/vbulletin/forumdisplay.php?f=14 And where is one of this reports? Sorry, but posting no url would be better in this case.-) See you, Attila
Re: [arch-general] Shouldn't pacman restart dovecot after update?
At Samstag, 7. August 2010 23:07 Guus Snijders wrote: > In that case, try: > lsof | grep " DEL " Okay, with the update of util-linux-ng checking of the deleted files makes sense because a lot of files use /lib/libuuid.so.1.3.0. I create this MINI script for this: # cat /usr/local/bin/scan_deleted_files.sh #!/bin/sh # list of deleted files echo 'COMMAND PID USER FD TYPE DEVICE SIZE/OFFNODE NAME' lsof -n | grep ' DEL ' See you, Attila
Re: [arch-general] Shouldn't pacman restart dovecot after update?
At Samstag, 7. August 2010 23:07 Guus Snijders wrote: > In that case, try: > lsof | grep " DEL " > > Note the spaces before and after DEL. > After checking it again, i noted that lsof uses caps for the type, so we > can drop the -i from grep. This idea is better and now i have to wait for an update which will use deleted files. Only for the stast it is not unusually that apps use deleted files: # lsof -n | grep ' DEL ' firefox1832 arpad DEL REG0,4 1998849 /SYSV kwin 3815 arpad DEL REG0,4 0 /SYSV The way of an rpm based system with using RPMDELETE as the flag seems easier to find out such files. Is there a analog way possible for pacman? I never take a look after an update with pacman. See you, Attila
Re: [arch-general] Shouldn't pacman restart dovecot after update?
At Samstag, 7. August 2010 01:26 Guus Snijders wrote: > Well, you certainly do have a point; finding out which apps are using > the updated libraries etc would be nice. Here is a example of the output and what it is behind: http://www.kriyayoga.com/love_blog/post.php/1207 How more i search in the web what is behind i found out that it seems that "zypper ps" run this only for the list of the updated packages and not for the whole system. This makes it very hard for myself to find out how i can get the same under archlinux. > After thinking about it for a moment, it seems one solution would be > very simple. Just run "lsof | grep -i DEL". It seems that you don't use KDE because i get a big list of '*kdelibs*' entries.-) One other human used this "lsof -n | grep -E 'RPMDELETE|;|path inode='" under opensuse before zypper get this feature. But RPMDELETE won't be there under archlinux. > I'm pretty sure that this could be much optimized, but i hope the idea > is clear If you find something for this this would be very, very nice.-) See you, Attila
Re: [arch-general] Shouldn't pacman restart dovecot after update?
At Dienstag, 3. August 2010 23:50 Heiko Baums wrote: > I hadn't had any post-update maintenance nightmares yet. Well, not > nightmares. I want to know what is done and what happens on my system. > Otherwise I would recommend a different distro. But to be honest I had > a lot more post-update nightmares with SuSE, because YaST has always > overridden my configurations. This can't happen with Arch due to > the .pacnew files. Only for the stats: In the case of updating packages Yast, and im suprised that you use this more than zypper, don't touch changed config files because opensuse, and every other rpm basesd distribution, do the same as archlinux with *.rpmsave and *.rpmnew files. As i said in the other posting, i don't think that any packager on this planet do mistakes with intent but they be even possible because we are all only humans. -) See you, Attila
Re: [arch-general] Shouldn't pacman restart dovecot after update?
At Dienstag, 3. August 2010 22:59 Mario Figueiredo wrote: > An argument can be made that this approach makes a rolling release less > attractive to users who have invested heavily in the supported > repositories. I heard this much just recently from a former Arch user; > The possibility of an an unpdate resulting in a post-update maintenance > nightmare to get the machine up and running again can be a little scary. I don't think that the principle of rolling releases support such mistakes more than as you use another distribution. You only move the timepoint more in the future but if such a distribution do the step from at example A to B than you have to do this "nightmare" search of changed config files for all packages. That's all because mistakes are even possible instead no one wants to make them. I think, and this is more my experience, that you will get a lot of more stories about updates in archlinux which runs without a problem instead the list of packages was enormous. See you, Attila
Re: [arch-general] Shouldn't pacman restart dovecot after update?
At Dienstag, 3. August 2010 22:35 Heiko Baums wrote: > That's a common and necessary task of a Linux admin which doesn't need > and in my opinion shouldn't be done by the package manager, because the > package manager can't decide which config files I need or want to > adjust and when I can and want to restart which daemon. Restarting > daemons automatically by the package manager can break a lot and can do > a lot more harm. Here i'm be with you but this problem with restarting daemons has more to do that we all enjoy this rolling releases under archlinux. In a case of a distribution which does this not you can do this without a problem in a lot of cases. > And there are definitely no messages from the package manager needed. Before i saw this feature with the warning in zypper i would say here yes too but now i found this very useful because in the case of gui apps or the gui itself it is not even clear for me what for libs been used. I'm running opensuse on my laptop too and i'm often suprised after an update what for litte apps use what for libs. But no question, it would more say it is nice if it is there but not a thing what is absolutely necessary or that it is unacceptable that we users do this by ourselves. See you, Attila
Re: [arch-general] Shouldn't pacman restart dovecot after update?
Okay, i recognized that i wrote too much under this little thread so set it on read if this is too much for you.-) The best compromise what i have seen is what zypper (package management tool for opensuse) do in a case if libs or a daemon get changed. After upgrading in such a case you get a warning that some apps point to deleted files and that with a "zypper ps" you can get the list of them. The list itselfs looks like this (from my memory): PID | user | file | libs 101 | user1 | app1 | PATH/lib21.so.21 ||| PATH/lib22.so.22 99 | daemon | daemon | PATH/lib11.so.11 ||| PATH/lib11.so.11 201 | root | app2 | PATH/lib31.so.31 ||| PATH/lib31.so.31 So the nice thing is that you even know if a logout or a restart of a daemon or a reboot solves it. And the best is that you get the information not as the output of the 73'st package from 125 packages, you get it at the end where the attention could (or should be) the best. I don't know if the rpm database helps here more than the one from pacman or how this is realised. But at the end the most important point (which is even valid): The question is even how much is the effort to realize such a "luxury" solution and is it this worth. That is why i never wrote a feature request instead i think this idea is very nice.-) See you, Attila
Re: [arch-general] Shouldn't pacman restart dovecot after update?
At Dienstag, 3. August 2010 11:14 Peter Lewis wrote: > I have to admit that the recent dovecot update caught me out too for a few > minutes, until I realised that I'd had no new email for an eerie amount of > time. This is not nice no question but how will you solve changes in the config file which be not backward compatible? In such a case it would be better to stop instead of restart the daemon. I think nothing would be better than to look what for updates be there and to stop a daemon manual or in the case of KDE step to runlevel 3 before the update. But this be nothing more than my 2c. See you, Attila
Re: [arch-general] Shouldn't pacman restart dovecot after update?
At Dienstag, 3. August 2010 08:00 David C. Rankin wrote:
> Well sometimes the stupid ones among us don't always catch that
dovecot is
> being updated when it is one of 73+ updates that take place. But we 'do'
always
> catch the failure to copy to sent -- later :p
If the count of updates is your problem than this idea could be something for
you:
# cat /etc/cron.daily/pacman.updates
#!/bin/sh
{
/usr/bin/pacman -Sy
echo
/usr/bin/pacman -Sup
} | /usr/bin/mail -s "$(hostname -s): Arch Updates" YourUser
No question, this is more simple than perfect. -)
See you, Attila
Re: [arch-general] Shouldn't pacman restart dovecot after update?
At Dienstag, 3. August 2010 06:39 Tavian Barnes wrote:
> Because of KISS? Pacman is a package manager, not a system administration
tool.
This has nothing to do with package manager or not because dpkg or rpm can do
this without a problem.
> Imagine the story with a different daemon: SSH. You ssh into your
> box, su, and pacman -Syu. Halfway through the upgrade, openssh gets
> updated, which automatically restarts the server, which SIGHUPs
> pacman, which is left in an inconsistent state.
I have never had problems with a ssh session if i update ssh on my opensuse
server and the specfile has this inside:
%postun
%restart_on_update sshd
%{insserv_cleanup}
It is okay if you say KISS is the goal but inside of a *.install file you could
do the same as in a specfile of a rpm package and no one would call rpm a
"system administration tool".-)
And before one of the arch devs could misunderstood my lines: I can live
perfectly that we the users do this by ourselves instead that the packaging
comsumes more and more time.
See you, Attila
Re: [arch-general] makepkg creates symlink to the package file
At Samstag, 26. Juni 2010 07:38 Ray Rashif wrote: > [1] http://www.mail-archive.com/pacman-...@archlinux.org/msg03794.html Thanks for this information. It seems that at no point it was thought about a config variable and therefore we have to live with it. See you, Attila
Re: [arch-general] makepkg creates symlink to the package file
At Freitag, 25. Juni 2010 08:29 Ray Rashif wrote: > In what kind of situation would someone have something against that symlink? If you don't ordered it? -) Okay without joking: I think everyone will have something against a thing what he never needs and i'm surprised that no one recognize this very simple answer. > Anyway, you should direct your idea(s) to pacman-dev. I think it is too late to change it and still again if this helps the devs than it is okay for me. I start only this thread because at first i thought that i have overseen something in the config file. See yoou, Attila
Re: [arch-general] makepkg creates symlink to the package file
At Donnerstag, 24. Juni 2010 20:06 Andres P wrote: > ...but that's the whole point of bash/zsh completion. Do you put links to $HOME > in /etc or use CDPATH? I mean, modern shells have facilities so let's use them. You be right and if you look at my other posting my favorite is that pacman can run namcap right after a successfull packaging without the need of a symlink. The extra advantage in this case could be that you have all in one logfile ... but before someone else said it: it is very easy to write your own logfile. > Joining the list of people that think these links are unnecesary. I'm only not on this list because i found an advantage for me and if this symlink helps the devs than it is okay. And in the case of this aur builder scripts it shouldn't be hard to integrate the deleting of the symlink. Perhaps it could be helpfull that the pacman devs give the information which line is to be comment out in makepkg if you don't wants it and all is fine.-) And here is my very simple suggestion from user to user: LOGFILE="build-$(date --iso-8601).log" /usr/bin/makepkg -c 2>&1 | tee $LOGFILE /usr/bin/namcap *.pkg.tar.xz 2>&1 | tee -a $LOGFILE rm -v *.pkg.tar.xz 2>&1 | tee -a $LOGFILE There is room to optimize it with test statements and so on.-) See you, Attila
Re: [arch-general] makepkg creates symlink to the package file
At Donnerstag, 24. Juni 2010 14:39 Hilton Medeiros wrote: > Just remove it: rm -f goddamn-symlink.so > What is exactly the problem with it anyway? Your hint is not very productive because you confound cause and effect. The problem is not to delete this file because i think everyone here can use rm. For me this link is now a good help (and memory) to run namcap which i forgot in the most cases and therefore i found my peace with it. But i can understand the wish for a config variable if some don't need this. See you, Attila
Re: [arch-general] makepkg creates symlink to the package file
At Mittwoch, 23. Juni 2010 14:20 ProfessorTomoe wrote: > Is there a way to disable the symbolic link creation? I install aur > packages using makepkg -ci, but the -ci switch combo does not delete > the symlink. I don't want them created in the first place, so can I > somehow turn off this behavior? I start using a shell script for running makepg. At the moment i have no better idea to delete it. But for running namcap right after makepkg this symlink is an advantage. See you, Attila
Re: [arch-general] makepkg creates symlink to the package file
At Mittwoch, 23. Juni 2010 07:26 Allan McRae wrote: >> Or do you mean that a "makepkg -c" will clean elder invalid symlinks? > > This one. Is there a way to delete not only elder symlinks and the destination too? Could be very nice but is not a must.-) See you, Attila
Re: [arch-general] makepkg creates symlink to the package file
At Mittwoch, 23. Juni 2010 06:06 Dan McGee wrote: > It is also a very helpful symlink for those of us that like to run > namcap after building to check the package. I must correct myself and have a from my view better idea for this. I suggest a new option "-n" (or "--namcap") which runs namacp after a successful build of a package. If "makepkg -cn" is used the symlink gets even deleted (or not created) and in the other cases it can stay at this position. Another question: Is there a way to delete this symlink and his target in one step on the command line? Than this symlink could be a bigger help because you get remembered that there is a older package in your repo. At the end i must say that this symlink is not a problem for me and there be advantages too so i can live with it. So please don't see my points as criticism. See you, Attila
Re: [arch-general] makepkg creates symlink to the package file
At Mittwoch, 23. Juni 2010 06:06 Dan McGee wrote: > It is also a very helpful symlink for those of us that like to run > namcap after building to check the package. That is an advantage ... because i forgot in the most cases to run it and now the motivation to do it is higher.-) See you, Attila
Re: [arch-general] makepkg creates symlink to the package file
At Mittwoch, 23. Juni 2010 05:48 Allan McRae wrote: > Possibly... I do not use "makepkg -i" as I use "makepkg -sr" so it > removed the makedepends that will be unneeded in the future. Using > "makepkg -c" clean up the dangling symlinks. I even use "makepkg -c" too and the symlink is still there. And i never install my own packages with "pacman -U" because i have my own repo on the server. Therefore i use "pacman -S" because than i can install it from my other pc too. Or do you mean that a "makepkg -c" will clean elder invalid symlinks? See you, Attila
[arch-general] makepkg creates symlink to the package file
Hello together, since the new pacman a makepkg run creates a symlink to the package file in the directory of the PKGBUILD. Example: # ls -l *.gz opera-snapshot-10.60-6378.2ah-i686.pkg.tar.gz -> /server/work/archlinux/repo/opera-snapshot-10.60-6378.2ah-i686.pkg.tar.gz My differences to makepkg.conf.pacnew be this: MAKEFLAGS="-j2" CFLAGS="-march=i686 -mtune=generic -O2 -pipe -fomit-frame-pointer" CXXFLAGS="-march=i686 -mtune=generic -O2 -pipe -fomit-frame-pointer" BUILDENV=(fakeroot !distcc !color !ccache) OPTIONS=(strip !docs libtool emptydirs zipman purge) PKGDEST=/server/work/archlinux/repo PACKAGER="Attila " PKGEXT='.pkg.tar.gz' [/server/work is a cifs mount point] Have i overseen something in the makepkg.conf to control this or does no one have this problem ... or is this a new feature which have to be so? See you, Attila
Re: [arch-general] [signoff] mpfr-3.0.0-1, gcc-4.5.0-6 and libmpc-0.8.2-2
At Samstag, 12. Juni 2010 14:53 Pierre Schmitz wrote: >> Was that ever fixed in our gcc? > > No, the last working gcc was 4.4 ... > I guess it will be fixed when some mainstream distros switch to gcc 4.5 I hope nobody is getting angry about it but i have one question: Is there a additional benefit that we stepped even "very" early to the next gcc? >From my feeling, which is not an analyze, with every gcc update something >breaks and there be at example such disadvantages: 1. Without the bigger distros, which have more manpower, everyone here has to create the patch by himself. At the first look this sounds as that you will do this only if you have too much time.-) 2. I think that the most application or toolkit developpers use at the moment gcc 4.4 and so it would be not a wonder that their own tests been perfect with this version and not 4.5. Or to ask it in another way: What is the disadvantage in the case of gcc to wait until the bigger player in the market makes the step too? Is there realy one or more application which benefits from it or can be compiled only with this newer version of gcc? For me it would be enough to have 4.5 in a gcc-next package and make the step with the other distros. But this be only my 2c. See you, Attila
Re: [arch-general] Cannot install shaman from AUR
At Sonntag, 6. Juni 2010 03:13 Daniel J Griffiths (Ghost1227) wrote: > It's been discussed before and rejected. If you want to know reasons and > logic, search the forums or the MLs. No sense in beating a dead horse. In principle this is okay but the question is was this rejected before or after the support for splitted packages in pacman? At example for this a GUI would be even better: pacman -Ss kdeplasma-addons -) If there is a chance that shaman get stable enough to step to extra this would be very nice but it is not a problem if not. See you, Attila
Re: [arch-general] [signoff] udev 157-1, initscripts 2010.06-1, mkinitcpio 0.6.5-1
At Donnerstag, 3. Juni 2010 23:59 Thomas Bächler wrote: > Actually, network rules are an exception, they still work. The removal > of NAME= only applies to /dev nodes. Thanks for this information and this sounds better for me as my first understanding of it. See you, Attila
Re: [arch-general] [signoff] udev 157-1, initscripts 2010.06-1, mkinitcpio 0.6.5-1
At Donnerstag, 3. Juni 2010 14:57 Thomas Bächler wrote:
> udev is an upstream update with mostly bugfixes, but some changes in
> behaviour. Most importantly, NAME= rules are being ignored now, you can
> not change the kernel's predefined device name anymore.
Is there a hope to get "NAME= rules" back in the future or is there a nice
upgrade path for at example network rules? I can't believe this because i do
this for my usb sticks too.
Can i replace this
KERNEL=="eth*", ATTR{address}=="MAC", NAME="lan", OPTIONS="last_rule"
with a Symlink
KERNEL=="eth*", ATTR{address}=="MAC", SYMLINK="lan"
and would this works in the rc.conf?
See you, Attila
Re: [arch-general] This is the "arch"-general list - Was Burning From Command Line
At Donnerstag, 27. Mai 2010 16:25 Gaurish Sharma wrote: > Joerg does has few odd things maybe because he is wrong or we are > wrong but either way; we shouldn't be rude to him.he is the reason we > have working cd/dvd burning support on Linux. AFAIK, he is working on > cdrtools since 1995, much before I was knew what OSS was. he gave us > his full source code & efforts for benefit for community much like > other free software devs. lets give him credit for that. +1 > Also the truth is one person cannot be responsible for 50+threads. > other people are replying to as well, so should be Joerg be blamed > alone? if you want to ban, he should not be only one. +100 and if you ban someone than you have to ban me because i'm the startpoint of this underthread ... a little cue in this case would be helpfull.-) See you, Attila
Re: [arch-general] Burning From Command Line
At Mittwoch, 26. Mai 2010 19:18 Mauro Santos wrote: > If the debian people are just spreading FUD as you say they are, then > prove them wrong once and for all with hard evidence regarding the > legal matters, then let people make up their own minds instead of > wanting people to believe something because you say so. This is not a one direction way because i must not believe the words of debian too.-) Sorry to say but until there is no decision from a law court i see this only as a interpersonal problem and therefore i prefer to discuss about technical things. Perhaps this is because i'm a former OS/2 user but what i really don't understand is the support for software which is a fork of old software and which don't support the same count of platforms as the original. Aside of this juristic discussions from laypersons i can't recognize for what the world need cdrkit. See you, Attila
Re: [arch-general] Firefox graphics licensed under MPL
At Montag, 3. Mai 2010 09:02 Allan McRae wrote: > If we want to use the official branding, then we have to ask permission. > And we would need to re-ask for permission every time there is an > update or if we have a minor patch to build against a new library etc... This is not very useful if you have to ask for every minor patch. If you want to ask the maintainer of the packages from opensuse if this is really such a MUST than i can send you his email address or you can take a look in the source rpm(s) from here to find it: http://ftp5.gwdg.de/pub/opensuse/repositories/mozilla/openSUSE_11.2/src This is only an information and not a feature request.-) See you, Attila
Re: [arch-general] Firefox graphics licensed under MPL
At Montag, 3. Mai 2010 09:07 Jan de Groot wrote: > lands on upstream FTP. With the approval policy, it will take days or > even weeks before we can package a new firefox version. The opensuse repository get sometimes updated 3 or 4 times in one week. Have them another policy? But no question what you and Allan said is not a productive way. See you, Attila
Re: [arch-general] Firefox graphics licensed under MPL
At Sonntag, 2. Mai 2010 19:31 Ionut Biru wrote: > They don't want us to modifying anything without asking for permission. > For us that will never happen because we have shared xulrunner, we use > system libs(they don't like that at all). opensuse has "enable-official-branding" in their specfile and use system libs with a shared xulrunner too. So from my view you can ask them but i'm not an expert of it because i use my own package (kde integration). Perhaps this is more a problem for Debian than for archlinux. See you, Attila
Re: [arch-general] Open Konsole Here ???
At Freitag, 19. März 2010 12:02 Nilesh Govindarajan wrote: > How to make that action appear in context menu of the file manager (rt. > click) ? It is in the submenu "Actions" (i hope this is the word in english version because i use german) and can run for a selection too. If you use the konqueror as filemanger instead of dolphn than you can choose the shortcut by yourself. if you want another terminal than you can do this in the systemsettings under standard components. Have fun with it, Attila
Re: [arch-general] pacman.conf: can I use wildcards?
At Freitag, 19. Februar 2010 12:01 Heiko Baums wrote: > Right, that's what NoUpgrade in pacman.conf does. ;-) Thanks for the smiley at the end because i was very silly (oder anderes gesagt die Leitung auf der ich stand ging mindestens zweimal um die Erde -) ). See you, Attila
Re: [arch-general] pacman.conf: can I use wildcards?
At Donnerstag, 18. Februar 2010 23:29 Heiko Baums wrote: > 2. What will happen if someone will use it accidentally wrong? Nothing > except, that there will be many .pacnew files in this directory which > can simply be renamed. So there won't be any serious bug. Oh, so if someone use 'usr/lib/*' than the lib of every new or updated package will get installed with the '.pacnew' ending? Than there is no risk that is true and i'm wrong. Sorry for thinking too much complicated in this case. See you, Attila
Re: [arch-general] pacman.conf: can I use wildcards?
At Donnerstag, 18. Februar 2010 19:30 clemens fischer wrote: > Not likely. Files named like something/other*, with the star being > a literal instead of a glob are very, very rare. There is no guarantee that this will be used in this way.-) > On the contrary, people have provided good examples where wildcards are > useful. That is true and every example was a good example. But there is a little risk that you got lazy if you don't document what you have done and than including a complete directory with a lot of files could end in a bugreport where people search a longer time because no one is thinking that it was "simple mistake". That is all what i want to say and myself wouldn't have a problem with it. See you, Attila
Re: [arch-general] pacman.conf: can I use wildcards?
At Donnerstag, 18. Februar 2010 02:13 Dan McGee wrote: > No, we don't support globbing in these options. Question to the list- > does it make sense to do so? Instead this makes something easier i must say that this could be dangerous too because it could end in some strange questions in the support area. Perhaps it could helps if you makes it possible to use a include file for this because than appending a file in this file is easier as to edit pacman.conf. This "harder way" for NoUpgrade has the advantage that you even know which file is the reason why you edit it because sometimes i don't know weeks or months later what i have done ... but this be more my self-critical 2c.-) See you, Attila
Re: [arch-general] Multiple Kernels
At Montag, 1. Februar 2010 23:45 Muhammed Uluyol wrote: > cp `ls -1 /var/cache/pacman/pkg/kernel26-2.6* | tail -n 1` ./ > > Is it really that hard? You have over read that i don't have this problem because i have own kernel packages (one optimzed which includes the BFS Scheduler and one stable). I said only my opinion about this wish to have multiple kernel versions. See you, Attila
Re: [arch-general] Multiple Kernels
At Montag, 1. Februar 2010 23:57 Heiko Baums wrote: > It's contrary because these cases are so seldom it would make too much > work to keep and maintain several older versions and it would cost much > more disk space and traffic on the mirrors. +1 I speak about this seldom cases and the only one what i propose to have multiple versions is the kernel package. Perhaps the devs see more but not me.-) > See Gentoo with its USE flags, slots, multiple versions in the portage > tree etc. All these features are quite nice and supposedly flexible. > But in fact I like the feeling of having lost all this ballast on Arch. I tried gentoo in the past but this USE flags confused me more than they helps me because i don't know enough about what for apps need what to use it in a constructive way. > And the two cases in which I needed the previous version I was lucky > with the pacman -U option. We both are not so much different in our opinions (perhaps we should try it in german -) ) but instead of you i don't see the cache on my local disk as a backup. That is why i use own kernel packages to be on the safe side.-) See you, Attila
Re: [arch-general] Multiple Kernels
At Montag, 1. Februar 2010 22:08 Heiko Baums wrote: At first i want to say that i'm not interested for that the devs have to have too much work. > And if you really need to downgrade the kernel or another package just > do it with pacman -U /var/cache/pacman/pkg/-. I know this is the No.1 hint but this solution is not very well from my view because instead the hardidsk getting bigger and bigger it sounds unlogical to keep a lot of files in the cache and only a few one could be important for seldom cases. One of them which is important be the kernel. So if pacman would have the option to install a certain version of a package than the user need only to know if there is more than one version in db. So perhaps this coould be solved at example for a search of all by a "pacman -Ss --allversions ^kernel". Last not least repo-add and repo-remove must have the possibilty to do this too. Than the devs could decide for what for packages they think it is worth to have an downgrade option and it doesn't matter what is in the cache of everyone. I think all other ways makes too much work for seldom cases but this is only my view and not a feature request. On the other side i think it is even worth to have an own kernel package and the PKGBUILD of kernel26 makes it very easy to do this. See you, Attila
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
At Freitag, 29. Januar 2010 18:55 Joerg Schilling wrote: > BTW: cdrecord in this mode is unsafe as it does not manages the fine grained > privileges but would need to give up cap_dac_override before it tries to open > other files. If you don't give up cap_dac_override, cdecord can read any > local file. Thanks for the warning that is unsafe but how longer we discuss about doing the same with capabilities how more i like to stay with the gold old solution.-) See you, Attila
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
At Freitag, 29. Januar 2010 14:10 Pierre Schmitz wrote: > Finally some interesting discussion came out of this. I am not an expert on > linux capability support, but Thomas has posted two blog entries about this in > Arch: http://archlinux.me/brain0/2009/07/28/using-posix-capabilities-in-linux- > part-one/ and http://archlinux.me/brain0/2010/01/05/using-posix-capabilities- > in-linux-part-two/ Nice informations, thanks. > In general this should work fine. The only problem is that bsdtar did not > support storing those information (don't know if future versions support this) > so one has to use install scripts to adjust the permissions after install. I must say that using install scripts is from my view for permissions or setcap even the better way because than i don't need to be root to create a package. See you, Attila
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
At Freitag, 29. Januar 2010 11:39 Joerg Schilling wrote: Thanks for your nice informations and with this line for setcap cap_dac_override,cap_sys_rawio,cap_ipc_lock,cap_sys_nice,cap_net_bind_service+ep a "cdrecord --scanbus" works as normal user without a problem. > As long as there is no support code in Linux distros to set > capabilities without making the target program suid root anyway, > I see no other possibility than to stay with > > chown root cdrecord cdda2wav readcd > chmod 4711 cdrecord cdda2wav readcd This is definitive easier and there is no risk if something will changes for capabilities. There is only one thing which i find better and it is that i prefer "chmod 4710" with a special group to not allow everyone to run cdrecord. Okay, i'm not an expert but this looks safe enough for me ... provide that i have to look every time at the manpage of capabilities.-) See you, Attila
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
At Donnerstag, 28. Januar 2010 20:38 Gerardo Exequiel Pozzi wrote: > I did nothing about group, only root perms ;) Keep the group ;) Ah okay that is the difference. But is this really necessary because this way sounds like "i have to know things what i never wants to know".-) See you, Attila
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
At Donnerstag, 28. Januar 2010 10:22 Joerg Schilling wrote: I don't find the most of your sugestions in "man 7 capabilities". > file_dac_read Permission to open any device file = cap_dac_readsearch ?? > sys_devices Permission to send anc SCSI command Nothing found. > proc_lock_memory Lock into memory = cap_ipc_lock > proc_priocntl Increase priority Nothing found. > net_privaddrAllow ports < 1024, needed for RSCSI cap_net_bind_service Is it really such a problem to stay with "chmod 4710"? See you, Attila
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
At Donnerstag, 28. Januar 2010 08:35 Gerardo Exequiel Pozzi wrote: > Hi, don't need all root privileges/capabilities. Only cap_sys_admin, > cap_sys_rawio for some special SCSI commands and cap_sys_resource for > incresing resource limits. > > setcap cap_sys_admin,cap_sys_rawio,cap_sys_resource+ep /usr/bin/cdrecord If i do this than i cannot open '/dev/sg1' and therefore i will stay with my way instead it is obsolete. Thanks for the hint, Attila
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
At Donnerstag, 28. Januar 2010 00:14 Gaurish Sharma wrote:
> Anyone,
> How can we setup cdrtools to completely replace cdrkit so that other
> programs like k3b can use seamlessly ? Any guides, I didn't find
> anything on ArchLinux Wiki which is kinda strange.
The hard way only for your system:
pkgname=cdrecord
_pkgname=cdrtools
...
conflicts=('cdrkit' 'cdrtools')
provides=('cdrkit')
...
I have no cdrkit here because i don't need it and i don't need the sysmlinks
inside of the package.
> One more thing
> cdrtools required it to be run as root, isn't that dangerous. any
> method by which we give the required permissions to normal user?
I change the permissions in the install file in this way:
/bin/echo "Change Owner, Group and Permission to root.optical (4710) ..."
for n in /usr/bin/cdrecord \
/usr/bin/readcd \
/usr/bin/cdda2wav;
do
/bin/chown -v root:optical $n && /bin/chmod -v 4710 $n;
done
/bin/echo "done.
Than the user has only to be in the group optical. It works but perhaps a
expert
should say if this is okay.
See you, Attila
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
At Mittwoch, 27. Januar 2010 22:47 Ray Rashif wrote: > It started off with a simple cautious question: evidence, please? ... Was it right that you answer to my comment? For me the story is over and i wish Joerg the best to get statements from a laywer which he can publish. One of the biggest advantage of archlinux is that you can easy create your own package and therefore i'm not interested for statements like "the archdevs have to do this and this". It would be very nice if cdrtools comes back but this is not my decision and this thread shows that it seems not easy to decide. Until than i do the same as everyone and use my personal favorite. See you, Attila
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
At Mittwoch, 27. Januar 2010 20:59 Joerg Schilling wrote: > I am in contact with several lawyers but if you don't pay a lawyer, you get > help but not the permission to publish the statements. Good luck for it and i hope this story could find his end. And i want to take the opportunity to thank you for cdrtools which i use now under linux and in the past under OS/2. See you, Attila
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
At Mittwoch, 27. Januar 2010 12:51 Allan McRae wrote: > Please provide a report from a single laywer showing that there is not. > This has been repeatedly asked of you I'm with you because it would be very nice to have this report but because in life all have two sides in the most cases i have to ask you for the same: Where is the report from a single laywer which supports the arguments of debian? Sorry ,if i makes you angry because this is NOT my intention. But what i really miss during this most useless discussion about a software for linux is that no one of both sides hire a laywer and see what happens in reality inf front of a court instead of voting. This would be better for everybody of us than this kind of confrontation. See you, Attila
Re: [arch-general] KDE 4.3 no power functions ?
At Mittwoch, 27. Januar 2010 15:59 Bram Schoenmakers wrote: > cd ~ > ln -s /usr/share/themes/QtCurve/gtk-2.0/gtkrc .gtkrc-2.0 I don't think that this is a good idea and if you want a to create a symlink it is more recommend to do this in /etc/gtk-2.0: http://slackbuilds.org/repository/12.2/desktop/QtCurve-Gtk2/ For a ~/.gtkrc-2.0 i suggest more to include this line include "/usr/share/themes/QtCurve/gtk-2.0/gtkrc" because than you can append lines for your prefered font or another gtk-icon- theme. I recognized that for me the look of the fonts is better if i choose the same font with 1pt lower for gtk apps. See you, Attila
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
At Montag, 25. Januar 2010 03:55 Sven-Hendrik Haase wrote: > I know this is a going to be a probably tiresome discussion revived but > I'd like to get this over with. I've been meaning to do it for a while now. I support your opinion and use an own package for cdrtools but for me there was a realy showstoper what i have read in a discussion on the forum: There is no one who wants to maintain a cdrtools package. So for me everyone has the right to have his own opinion and if there is no dev who wants to maintain cdrtools than we risk to discuss a theoretic thing. > My issue is that the cdrtools substitute cdrkit that Arch currently > officially provides is not actively developed (current to last stable > was around a year) and is technically inferior to cdrtools. cdrkit still > does not generate proper iso-level-3 file systems and has trouble with > big file support. This makes proper blu-ray creation hard. My upstream > bug report on their mailing list was completely ignored, for example [1]. This is another reason to stay with the original. Thanks for this information. See you, Attila
Re: [arch-general] building x86_64 packages under qemu?
At Mittwoch, 13. Januar 2010 01:43 Damjan Georgievski wrote: > he is not using kvm (and kvm will not make a virtual 64bit cpu on a 32bit guest) Thanks for this hint. I thought he is using kvm because the binary has the same name. This was a mistake of mine. See you, Attila
Re: [arch-general] building x86_64 packages under qemu?
At Dienstag, 12. Januar 2010 12:27 Chris Brannon wrote: > Yes, I've noticed that the ./configure step is especially painful, > because of all of the little test programs that it compiles. > Running ./configure for a small project took the good part of half an hour. Do you use virtio in your vm? http://www.linux-kvm.org/page/Boot_from_virtio_block_device If you use disklabels in your vm (menu.lst, fstab) than you have only to change your start script. This helps a lot but sure it can't replace fast hardware. See you, Attila
Re: [arch-general] Quoting of E-mails
At Dienstag, 12. Januar 2010 06:27 Loui Chang wrote: > I also find mutt's 'T' helps. It hides the quoted text. Very nice feature. Does anyone knows if this is possible in knode too? See you, Attila
Re: [arch-general] Kernel 2.6.32 Broken
At Donnerstag, 31. Dezember 2009 03:51 Chris Brannon wrote: >> If you, too, don't use [testing] and get kernel panics then this is >> because there is at least one important package update which is needed >> by kernel26 2.6.32.2-2 missing in [core]. I guess it's mkinitcpio. If >> you update your system to [testing] then it works again. > > I'm running 2.6.32.2-1 just fine on a box that has never had [testing] > enabled. +1 I think it would be better to search too the reason at another place than only mkinitcpio. And yes, i don't use testing too. Good Luck Steve and perhaps it would be a good idea to use an own kernel package for 2.6.31.x to have this as fallback and therefore better possibilies to find out why 2.6.32 don't works for you. See you, Attila
Re: [arch-general] [arch-dev-public] Xorg changes / DRM modules
At Dienstag, 22. Dezember 2009 12:59 Andreas Radke wrote: > We would also like to do this. Would mean much less work for us. i can understand this reason but please don't forget if something goes wrong than everybody includes you have more work as with seperate *-git packages. > Sadly not all part move at the same time and distributions have to > decide whether to package old stuff that isn't supported upstream > anymore or more recent and sadly buggy stuff. Sorry, this is an option for a private repo but not for a distribution from my view. Again, i can understand you and your problems but if mainstream stops offering stable versions and offers only git version than this is the mistake of the mainstream and must not be repeated by us. I would not have a problem with waiting until mainstream have all under controll and offers a stable solution. > We will try to fix all known issues in testing before we move stuff to > core/extra. I believe that you and the other arch devs will gives all. Thanks for this work. See you, Attila
Re: [arch-general] [arch-dev-public] kernel 2.6.32-1
At Samstag, 5. Dezember 2009 09:56 Hussam Al-Tayeb wrote: > Isn't it against Arch philosophy to split packages it binary and header > packages? First the headers from the kernel package was even a reduced amount and if you look in the PKGBUILD only for the cases if you build some packages for yourself. Second is that this discussions about what is the arch way here in public get a religious touch instead of what it has to be: First the arch devs should decides (and discuss) this and second the pragmatical way is even better than the academical way. Just only my 2c. See you, Attila
Re: [arch-general] [arch-dev-public] Qt 4.6.0
At Mittwoch, 2. Dezember 2009 10:51 Raghavendra Prabhu wrote: > Qt 4.6 works fine for me And you you have a vertical LCD? But no problem if not because this sounds nice and i hope it will give KDE some speedup. See you, Attila
Re: [arch-general] [arch-dev-public] Qt 4.6.0
At Mittwoch, 2. Dezember 2009 16:15 Gerardo Exequiel Pozzi wrote: > No 19" CRT monitor 1280x1024 @ 96x96 DPI + nvidia 190.42. Oh, sorry for the question.-) > Seems that is the forum topic is unrelated, talks about font curruption. Here fonts are OK, the only difference is that are a bit bigger (Y) and a big more condensed (X). I must say that the new version for the fonts looks better for me but this be only my 2c. See you, Attila
Re: [arch-general] [arch-dev-public] Qt 4.6.0
At Mittwoch, 2. Dezember 2009 05:03 Gerardo Exequiel Pozzi wrote: > Installed here (i686 at this moment). Font looks a bit bigger than with > previus qt. Do you have a vertical LCD display perhaps? I ask because of this elder discussion about problems in qt 4.5.0 with fonts and certain monitors: http://bbs.archlinux.org/viewtopic.php?id=67031 I hope this will not be the same story.-) See you, Attila
Re: [arch-general] pam settings INSECURE
At Mittwoch, 18. November 2009 14:07 Xavier wrote: I hope this could be a help for someone who knows how to configurate pam.-) > And I am curious to know what the pam settings of other distro are > (debian,fedora,gentoo,..). Opensuse with the KDE43 repo has no /etc/pam.d/kde file and they used for configuration of the common files an own tool with the name pam-config. Here be the content of login and the common files: /etc/pam.d/login: #%PAM-1.0 auth requisite pam_nologin.so auth [user_unknown=ignore success=ok ignore=ignore auth_err=die default=bad] pam_securetty.so auth includecommon-auth account includecommon-account password includecommon-password session required pam_loginuid.so session includecommon-session session required pam_lastlog.so nowtmp session optional pam_mail.so standard /etc/pam.d/common-auth: authrequiredpam_env.so authrequiredpm_unix2.so /etc/pam.d/common-acount: acount requiredpam_unix2.so /etc/pam.d/common-password: passwordrequisite pam_pwcheck.so nullok cracklib passwordrequiredpam_unix2.souse_authok nullok /etc/pam.d/common-session: session requiredpam_limits.so session requiredpam_unix2.so session optionalpam_umask.so Perhaps it could be a good idea to compare what other distributions do and optimize the files from archlinux. See you, Attila
Re: [arch-general] kde4 tip - quicklaunch in your panel -- convenience at your fingertips!
At Mittwoch, 11. November 2009 15:04 Robert Howard wrote: > Have you guys ever heard of krunner? It really makes doing things and > launching apparently easy. You don't really need icons to launch programs. Krunner is very nice but for me it is more a replacement for katapult which i used under kd3 than something extra. > Also, I don't understand all of the dolphin detractors. I think dolphin is > near file manager perfection. Always felt that konquorer was like a big > incoherent blob. Dolphin will be feature complete soon and it will have paid > off to start over. If i will get even 1 Dollar for every "but with the next release all will be complete" in combination with KDE4 than this will be very nice for me.-) One question about dolphin: Why is F4 hardcoded to the Terminal Emulator instead of as before (or still now) with konqueror? Without konqueror and without kde3 perhaps dolphin could be good file manager but in comparison to it for me never.-) Just for the stats (and to say some positive thing too): Now at the moment the Perfomance of KDE4 is realy good. See you, Attila
Re: [arch-general] google wave
2009/11/1 Trav : > Sent nomination for both muhammad.a.qa...@gmail.com and francz...@gmail.com! Thank you, I really appreciate it. Attila
Re: [arch-general] google wave
2009/11/1 Celti : > I would love an invite, if someone has one to spare. Me too. I've been wanting to play with this ever since I saw the intro video about it. So if anyone has a spare invitation, please drop it to francz...@gmail.com Thanks in advance, Attila
Re: [arch-general] We have lost the desktop war. The reason? Windows 7.
At Montag, 26. Oktober 2009 11:57 RedShift wrote: > an nVidia FX5500. My laptop suffers from this sluggishness as well. On top of > that, lots of things annoy me in KDE 4.3, see the end of this post for my top > annoyances. Yesterday I had to reboot to my Windows XP installation on this > computer and I was shocked when I arrived in XP's userland. Everything was You don't have to go to another OS because i was positive shocked as i switched to lxde on my laptop. And i still use the most kde applications but the gui is so much faster which remembers me as my good old kde 3.5. > Last week I also had the chance to check out Windows 7, and I was stumped. I was > genuinly impressed by Windows 7's GUI. It feels fast, works fluently, it has > nice effects which just work and work FAST. When browsing around it felt like a > very solid desktop environment. I am jealous. I really am. The thought of That a big firm as MS can learn from his deseaster named Vista is a good sign.-) > So when should we have started working at a better desktop environment for > Linux? At one side you be right but on the other side i miss the positive thing: The choice. Because at example your favorit Mac OS X comes only with one gui und celebrates centuries after X (or Workplace Shell for OS/2) to have virtuell desktops. Instead i can understand your lines i must say that the other ones cooks only with water too.-) > Yet we did have a second chance in 2007. Microsoft obviously screwed up with > Windows Vista, we had the chance to win back alot of terrain here until the > release of Windows 7. So what did we come up with? KDE 4. Yes, a big > dissapointment. We still don't have something that's comparable. The miss of one project is even the chance for another project. The biggest problem with KDE is that 4.x is not the follower of 3.5 because it is "only" plasma 0.x (here i speak from the gui and not from the apps). I don't mean this too much critical because i test the other gui's after i see what i will get with 4.x and at the moment i use on the desktop pc still again KDE ... but only because i lost the chance to compile 3.5 with the newer gcc. > So basically, where are we at? > KDE 3.5 is Windows XP > KDE 4.3 is Windows Vista > ??? is Windows 7 Funny summary.-) > If we are comparing enterprise desktops, there's no going around Red Hat. The > current Red Hat desktop (5.4) ships with KDE 3.5, while its succesor RHEL 6 will > be, if looking what Fedora brings now, shipped with KDE 4.2 or 4.3. That means > KDE 4.2/4.3 will be the main desktop for enterprises for at least the next 3 > years. A disgrace if you ask me. Users will be comparing desktop environments > and they will find Windows 7 or Mac OS X to be better. After the damage RHEL 6 > will have done to the reputation of the Linux desktop, it will take again as > many years to rectify the damage done. Granted if we will have a solid desktop > environment comparable to Windows 7 by the time RHEL 7 gets released. Which I > can't help but doubt. Don't underrate the devs of redhat or suse because they can't discuss about useless things, the have to sell it and so they have to get it stable. So if MS can learn from his mistakes why not the bigger player in the linux market can do the same. > * I get a full 10 minutes of extra runtime on my laptop when I switched back to > 3.5 Really, give another gui a chance and you will see more time what you get. Perhaps using openbox instead of kwin can helps too ... but the KDE gui without kwin looks very bad and my suggestion is to use another gui. > * Power management is buggy in KDE 4.3 and sometimes powerdevil just loses > its settings The laptop-tools can do the same job. I was a fan of KDE until 3.5 but i'm a bigger fan of "the better wins". If you like black humor than you can see KDE 4.x as a good motivation to reconsider your configuration and to take a look at the other gui's. For me this is the most positive thing about 4.x because now i know that the other one have execellent solutions too. Instead i'm not lucky about this days of testing other guis i must repeat the biggest advantage: the choice. See you, Attila
Re: [arch-general] DE
At Donnerstag, 10. September 2009 20:12 Sergi Pasoev wrote: > Does anyone have installed LXDE on Arch Linux? Yes, not active at the moment because i want to give kde4 a longer try. But before stepping from kde3 to kde4 i config LXDE to have something in the backhand. It is fast, it is great and i'm missing only little things. The wiki from archlinux says the most to get it run and it is absolute painless to give it a try. There is a blog (http://blog.lxde.org/) which has nice informations about it too. See you, Attila
Re: [arch-general] Maximum JFS file (not filesytem) size
On Tue, 8 Sep 2009 09:27:05 +0200 wrote Anders Bergh: > I just checked, and the max file size in JFS is 4 petabytes. Seems > like you have another problem. Yes, that is what the information from here said: http://en.wikipedia.org/wiki/JFS_(file_system) Perhaps it would be a good idea to give star a try: http://aur.archlinux.org/packages.php?ID=27135 See you, Attila
Re: [arch-general] proportion between qoutes and lines
Hello together, this thread looks more as a contest who has the lowest percentage of own words or who has the highest percentage of qoutes.-)) If possible it would be nice (and more readable) to stop this 90/10 for qoutes/lines. If not, no problem, this is a free world and it is only a suggestion from mine. See you, Attila
Re: [arch-general] introducing kernel26-lts
At Mittwoch 26 August 2009 20:46 David C. Rankin wrote: > Now where in the arch boot process could I put a script that > basically says > if uname -r is the lts kernel switch to nv and vice-versa? /etc/rc.local: if [ $(uname -r) = "2.6.27-lts" ]; then # do what you need to use nv fi But i think this will only works if you start kdm from the inittab ... or better to say, i don't know if this will works in the other case. See you, Attila
Re: [arch-general] Howto adjust font scaling in Arch? All fonts look a bit big and fat?
At Montag 24 August 2009 21:43 David C. Rankin wrote: > Is there somewhere that some type of scaling is done that I can tweak to try and fix this? The effect of the larger scaling makes everthing from the kmail message list to the basket notepad fonts look cramped. Any thoughts? Compare the content of /etc/fonts/conf.d incl. the file ~/.fonts.conf. Perhaps this gives you the answer but it is possible too that opensuse use another (and/or other patched) version of fontconfig. Good luck, Attila
Re: [arch-general] '*' in PKGBUILD for the conflicts array
On Donnerstag, 13. August 2009 07:06 Allan McRae wrote:
> I just replied in the bug report but for those that are interested
> something like:
>
> conflicts=("kdebase-*")
>
> may be achieved using
>
> conflicts=$(pacman -Ssq kdebase-)
As i said in the bugreport this is a fantastic solution.
> I would not recommend the general use of that
Me too ... but for own packages with own risk it is enough.-)
Thanks again, Attila
Re: [arch-general] '*' in PKGBUILD for the conflicts array
On Mittwoch, 12. August 2009 09:52 Allan McRae wrote: > No, that will not work. Perhaps in the future? If not, no problem and i don't want to force you to say me a release date.-) See you, Attila
[arch-general] '*' in PKGBUILD for the conflicts array
Hello,
since there starts a new splitting game with the kde/kdemod packages i have a
question for own packages. Would it be possible to use this
conflicts=("kdebase-*")
if i want to use a variation of the kdebase package which includes all. I know
that than i have to fill up the provides array with the full names if this is
necessary.
Comment: Thanks for the pacman support of splitting PKGBUILDs.
See you, Attila
Re: [arch-general] [arch-dev-public] GNOME 2.28 - changes ahead
On Dienstag, 11. August 2009 19:20 Cainã wrote: > That's why i'm using OSS for that kind of matters. Do you speak about oss 4.1_1052b-1 from Community? Another thing what i recognized during searching this on the web page: Could it be that the package searching pages be under construction at the moment? For 'oss' i get a exception on if i click on "svn entries". See you, Attila
Re: [arch-general] Latest updates messed up kdemod3 libjpeg.so.62?
On Dienstag, 28. Juli 2009 23:08 Thomas Bächler wrote: > Given the popularity of kdemod, it is sad that they can't seem to keep > up with Arch's development. I think the problem is more kdemod3 because the packages were built with the older gcc and if they really want to rebuilt them than this could be a very hard work. So from my view using the libjpeg6 from aur would be the best compromise. See you, Attila
Re: [arch-general] Where can I find the "boot" log to find out what failed on boot?
On Montag, 27. Juli 2009 18:10 Damien Churchill wrote: > Is that pretty much the same as adding "single" to the kernel line? > Least that's how I normally do it. Runlevel 3 is Multi-User Mode with Networking and do start daemons. See this for a first overview: http://en.wikipedia.org/wiki/Runlevel See you, Attila P.S.: Do you like your keyboard or why do you don't use '1' instead of 'single'.-)
Re: [arch-general] emacs-cvs do not run after libjpeg updated
On Mittwoch, 15. Juli 2009 19:27 Florian Pritz wrote: > Get the old libjpeg package, extract it and copy the .so file to > /usr/lib. Linking is a no-go. The best solution for working around seems this package from AUR: http://aur.archlinux.org/packages.php?ID=28427 See you, Attila
Re: [arch-general] emacs-cvs do not run after libjpeg updated
On Mittwoch, 15. Juli 2009 22:50 Stefan Husmann wrote: > no, that might break a hundred of other packages you might have > installed. The best way would be to wait for the mirror syncing or to > rebuild emacs-cvs using abs. First, i'm not waiting for emacs-cvs.-) My problem is that i don't know what will happens with my own kde3 packages if i will do this big upgrade. Therefore i'm looking for the best workaround. I don't understand what will be the problem if i make a package which include only libjpeg.so.62.0.0 plus his symlink libjpeg.so.62 and which i can install parallel to the new libjpeg package. For me non-profi this sounds good if i don't take the include files from the old package but i will be even thankfull if you tell me something about the possible problems what i have overseen. Second, waiting is not a problem because at the moment i have enough to do compiling my kde3 packages with the news gcc ... perhaps this is the reason why searching the web for patches is not my first option.-) See you, Attila
