Re: [arch-general] Eclipse won't start any more
I also have this problem. I am using gnome, and from the menu, eclipse stop at the startup screen and eat 100% cpu. while I run eclipse from command line, it works without a problem. Regards. On Tue, 20 May 2008 22:26:29 + (UTC) Juergen Starek <[EMAIL PROTECTED]> wrote: > Hello everybody, > > a few days ago, my Eclipse installation (which had worked fine for some > months before that) stopped working. Eclipse will start, but only to the > end of its initialization routine. The splash screen does not disappear. > > I realize this is no Eclipse support list, and hence will just point to > my more detailed error description on Eclipse's newsgroups [1]. However, > I'm out of ideas at the moment regarding possible causes for that error. > So I'd like to ask here whether anyone thinks that any updates to Arch > that appeared in the last three weeks or so might cause problems with > Java programs in general, or more specifically with SWT. Perhaps someone > even noticed the same problem? > > I'd be thankful for all hints. > > Regards, > > Jürgen > > [1] > http://www.eclipse.org/newsportal/article.php? > id=23901&group=eclipse.newcomer > > -- GANBARE! NIPPON! Win your ticket to Olympic Games 2008. http://pr.mail.yahoo.co.jp/ganbare-nippon/
Re: [arch-general] About Arch pkg compress format
On Wed, May 21, 2008 at 7:45 PM, Arvid Ephraim Picciani <[EMAIL PROTECTED]> wrote: > Yes you are allowed to link dynamicly, now read if you are allowed to run the > linked program. Not speaking of actually distributing it. Strange, why would it be allowed to link and not to run the linked program? It doesn't make sense. -- --- Denis A. Altoe Falqueto ---
Re: [arch-general] About Arch pkg compress format
On Thursday 22 May 2008 00:13:27 Tobias Kieslich wrote: > On Wed, 21 May 2008, Denis Alessandro Altoe Falqueto wrote: > > It seems that LZMA lib is licensed with LGPL and has an special > > exception that permits to link (statically or dinamicaly) without > > being bound by the LGPL terms. > > I thought LGPL permist statically linking anyways, which is why WXwidgets > eg is using it. > The LGPL is intentionaly hard to read and confuses a lot of people aparantly. Grats for that FSI. Yes you are allowed to link dynamicly, now read if you are allowed to run the linked program. Not speaking of actually distributing it. Oh and btw, the copyright law of the country of the author applies, which makes it just about a gazillion times more complex. Somone adding that exception indicates they actually read it and found they just want people to link it without consulting a lawyer. But uuuh hopefully people won't go bezerk now and check all the packages in the repo that violate copyright laws. Its about one third. Please keep at least this part of archlinux intact . Arch folks never gave a shit about those things. well until cdrecord -- best regards/Mit freundlichen Grüßen Arvid Ephraim Picciani
Re: [arch-general] About Arch pkg compress format
On Wed, 21 May 2008, Denis Alessandro Altoe Falqueto wrote: > > It seems that LZMA lib is licensed with LGPL and has an special > exception that permits to link (statically or dinamicaly) without > being bound by the LGPL terms. I thought LGPL permist statically linking anyways, which is why WXwidgets eg is using it. -T
Re: [arch-general] Any way to decrypt hashes set by ssh HashKnownHosts?
On Wed, 2008-05-21 at 16:12 -0500, Aaron Griffin wrote: > On Wed, May 21, 2008 at 3:52 PM, Dimitrios Apostolou <[EMAIL PROTECTED]> > wrote: > > The fact that fears me is that by hashing the known_hosts > > file information is lost, in particular the information that binds the > > IP address to the hostname. > > You are more than welcome to change the config settings. In all my > history with arch, we have always pointed fingers at the end user for > not paying attention to their config files, and I seriously have no > idea why this is a big deal now, a year after this change was made. > Sure it could have been more visible, but we have always held that the > config files are _your_ job. Hey No Problem. I have changed most of my config files a year ago, I just grab the opportunity to discuss that now that it's hot. My main point is that it should have been hot a year ago. I'm also struggling to figure out why I disliked this change that much back then. :-s Dimitris
Re: [arch-general] Any way to decrypt hashes set by ssh HashKnownHosts?
On Wed, May 21, 2008 at 3:52 PM, Dimitrios Apostolou <[EMAIL PROTECTED]> wrote: > The fact that fears me is that by hashing the known_hosts > file information is lost, in particular the information that binds the > IP address to the hostname. You are more than welcome to change the config settings. In all my history with arch, we have always pointed fingers at the end user for not paying attention to their config files, and I seriously have no idea why this is a big deal now, a year after this change was made. Sure it could have been more visible, but we have always held that the config files are _your_ job.
Re: [arch-general] Any way to decrypt hashes set by ssh HashKnownHosts?
On Wed, 2008-05-21 at 17:44 +0200, Xavier wrote: > On Wed, May 21, 2008 at 4:50 PM, Dimitrios Apostolou <[EMAIL PROTECTED]> > wrote: > > Hi, > > > > Was this change forwarded to the OpenSSH developers? I am sure that if > > it is indeed better security-wise to hash the known_hosts file, they > > would change the default configuration upstream. I'm also sure that they > > would give very good reasons for not wanting to do so. > > > > > > So I just went googling about this stuff. I saw this option got > enabled years ago on Debian, and after that a few users complained > about that change, but without any real reasons. (so a bit like what > is happening here now :)) > Anyway, there was a huge thread on debian mailing list, I finally > found one mail which partially answers your question : > http://lists.debian.org/debian-devel/2005/07/msg00041.html Thanks but I had read that before posting, as I had also been reading the openssh source code to understand how known_hosts matching is being performed. I have also read the same answer in 2005 on the openssh-dev ML, "it will probably be the default really soon". Still it is 2008 and it is not the default, that's why I asked what I asked. Why isn't it the default in OpenSSH? I have some fears that it *might* be a security threat to have a hashed known_hosts file, however I didn't want to say it publicly since I'm not sure at all. The fact that fears me is that by hashing the known_hosts file information is lost, in particular the information that binds the IP address to the hostname. With unhashed known_hosts they are both recorded on the same line. With hashed known_hosts each one is independently recorded on different lines. I am only speculating here, I haven't fully understood how openssh does its checks. We should be careful about *security* choices we make. Especially these choices should be made on vast community majority, not on the personal decision of a package maintainer. I am talking about general arch policy here, I have tried to raise discussion on other security issues too but got the feeling of being ignored by the devs, and that discuss on their private list and mostly announce here. Lastly, FYI I don't consider debian an example of good security policy. They keep changing things to satisfy their project's bugzilla but they keep being bitten by the fact that upstream doesn't always agree with them. Dimitris
Re: [arch-general] About Arch pkg compress format
On Tue, May 20, 2008 at 5:14 AM, Jan de Groot <[EMAIL PROTECTED]> wrote: > The > downside is that LZMA is not supported by libarchive, and won't be > supported officially either, because libarchive is BSD licensed and LZMA > is GPL licensed. Hi, It seems that LZMA lib is licensed with LGPL and has an special exception that permits to link (statically or dinamicaly) without being bound by the LGPL terms. See http://www.7-zip.org/sdk.html Maybe libarchive could be modified to support lzma also. -- --- Denis A. Altoe Falqueto ---
Re: [arch-general] About Arch pkg compress format
On Wed, 2008-05-21 at 19:39 +0200, Jan de Groot wrote: > What's the memory usage when unzipping an LZMA file? Is it much higher > than the needs of gzip? We already have problems supporting low-memory > systems with our installer, adding a compression algorithm that eats > more memory will cause even more problems for these systems. Yes it eats more memory in comparison to gzip, at least when high compression is chosen. But still the memory it uses is not much. From the official site of the LZMA utils: http://tukaani.org/lzma/benchmarks RAM usage on decompression gzipbzip2 lzmash lzmash -e 1 <1 MB 1 MB 1 MB- 2 <1 MB 2 MB 2 MB- 3 <1 MB 2 MB 1 MB1 MB 4 <1 MB 2 MB 2 MB2 MB 5 <1 MB 3 MB 3 MB3 MB 6 <1 MB 3 MB 5 MB5 MB 7 <1 MB 3 MB 9 MB9 MB 8 <1 MB 4 MB17 MB 17 MB 9 <1 MB 4 MB33 MB 33 MB The memory usage of lzma stays competitive with bzip2 when files have been compressed with "lzmash -6" or with a smaller option. The files compressed with the default "lzmash -7" can still be decompressed, even on machines with only 16 MB of RAM, but sometimes you don't have even that much memory available. If you compress with "lzmash -8" or "lzmash -9", you should think if the users need to be able to decompress your files also on "ancient" computers. I fully understand the license problem and personally I am pretty happy with the gzip algorithm, I am just pointing facts so that a technically correct conclusion is reached. Dimitris
Re: [arch-general] Eclipse won't start any more
On Mittwoch, 21. Mai 2008 14:23 Juergen Starek wrote: >> http://bugs.archlinux.org/task/10066 > > Thanks a lot, that was my problem! Luckily, I don't rely on Firefox > because I generally use Konqueror, so removing the Firefox package was > no problem for me. However, I'll look into this more deeply over the > weekend, perhaps I can find out something helpful. At the end of this bugreport adam reports that eclipse works (i test only Strg+Space) if you start it from the konsole instead of from the kde menu and this is true. Later he suggest to replace "/usr/share/eclipse/eclipse" with "eclipse" in the start menu settings and this works too. Completly strange but you can give it a try if you want firefox back. See you, Attila
Re: [arch-general] Security updates & packages in testing
On Tue, 20 May 2008, Grigorios Bouzakis wrote: Hi, there has been some security updates for packages in Core that have been upgraded and have been lying in Testing for a long while. The ones that come to mind are bzip2 and openssh but there might be more. Is there any reason those havent moved yet? As far as i can see bzip2 is missing some signoffs since April. One month+ is a lot of time for such packages to stay in Testing IMO. Someone should move them quick. Greg They were forgotten. openssh has been moved to core. Tonight I'll signoff and move bzip2 to core (if the package is OK). I intended to do a testing cleanup. There are more packages waiting for signoffs and some others that has been in testing for months. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: [arch-general] About Arch pkg compress format
Aaron Griffin wrote: That's actually not entirely true. Dan and I investigated this. The previous low memory issues were caused by the entire install system never leaving the initramfs, and remaining entirely in RAM - which soaked far more than pacman ever will. Additionally, with the dynamic package patch (dunno if this is in the master branch yet), memory usage sank by leaps and bounds. Yes it is, go go Dan :) http://toofishes.net/blog/valgrind-330-and-new-massif/
Re: [arch-general] About Arch pkg compress format
On Wed, May 21, 2008 at 12:39 PM, Jan de Groot <[EMAIL PROTECTED]> wrote: > On Wed, 2008-05-21 at 18:47 +0300, Dimitrios Apostolou wrote: >> Hi, >> >> On Tue, 2008-05-20 at 10:14 +0200, Jan de Groot wrote: >> > Pacman itself is ready for .tar.bz2 package files. The whole issue >> > with .bz2 files is that compression and decompression times increase a >> > lot without giving the same amount of size reduction back. We've done >> > some recent tests with LZMA, which compresses just as good as bzip2 at >> > the lowest compression rate, but does it at the same speed as gzip. >> >> About LZMA I should add that when using higher (actually the default) >> compression rate, compression is much better than bzip2 but takes more >> time/memory. Decompression however, which is what really matters in a >> packaging format, is kept fast and lightweight. > > What's the memory usage when unzipping an LZMA file? Is it much higher > than the needs of gzip? We already have problems supporting low-memory > systems with our installer, adding a compression algorithm that eats > more memory will cause even more problems for these systems. That's actually not entirely true. Dan and I investigated this. The previous low memory issues were caused by the entire install system never leaving the initramfs, and remaining entirely in RAM - which soaked far more than pacman ever will. Additionally, with the dynamic package patch (dunno if this is in the master branch yet), memory usage sank by leaps and bounds.
Re: [arch-general] About Arch pkg compress format
On Wed, 2008-05-21 at 18:47 +0300, Dimitrios Apostolou wrote: > Hi, > > On Tue, 2008-05-20 at 10:14 +0200, Jan de Groot wrote: > > Pacman itself is ready for .tar.bz2 package files. The whole issue > > with .bz2 files is that compression and decompression times increase a > > lot without giving the same amount of size reduction back. We've done > > some recent tests with LZMA, which compresses just as good as bzip2 at > > the lowest compression rate, but does it at the same speed as gzip. > > About LZMA I should add that when using higher (actually the default) > compression rate, compression is much better than bzip2 but takes more > time/memory. Decompression however, which is what really matters in a > packaging format, is kept fast and lightweight. What's the memory usage when unzipping an LZMA file? Is it much higher than the needs of gzip? We already have problems supporting low-memory systems with our installer, adding a compression algorithm that eats more memory will cause even more problems for these systems. > > The > > downside is that LZMA is not supported by libarchive, and won't be > > supported officially either, because libarchive is BSD licensed and LZMA > > is GPL licensed. > > Can't this problem be circumvented by spawning the lzma command line > utility, and piping all data to it? I understand that this perhaps > negates the purpose of libarchive, but the overhead should be small. libarchive can't spawn external commands to unzip archive files. bsdtar can, but as pacman is a binary with libarchive integrated, I don't see this happening.
Re: [arch-general] Any way to decrypt hashes set by ssh HashKnownHosts?
On 5/21/08, Thomas Bächler <[EMAIL PROTECTED]> wrote: > The point is, without any notice, we provided a different configuration > file than the upstream configuration file. That's not how we do it, we > always provide the upstream configuration file. wrong. We provide 'sane defaults'. I consider security to be sane. I guess you don't. That is fine, for you. > If someone thinks that having unhased known_hosts is a security problem, > then he/she can change this configuration option on his/her system, that is > how Arch works. If someone thinks that having unhashed known_hosts isn't a security problem, then he/she can change this configuration option on his/her system. That is how arch works. See what I did there? > But now that hashed known_hosts silently became the default, > I cannot revert back. Sure you can. 1. copy the known hosts file to a backup location. 2. Change the option (set it in your .ssh/config. This file overrides the defaults if you were not aware), and remove the known_hosts file. 3. Connect to hosts. When an entry is made, do a hash compare if you are concerned that the remote keyprint might have changed (ssh-keygen can output a known_hosts hash for a non hashed known hosts file). Also.. fyi.. knownhosts hashing option does not automagically convert an unhashed known_hosts file. It would simply add hashed elements to the file, resulting in a mix of hashed and non hashed. You would have had to run ssh-keygen on the known_hosts file to get a full conversion. So if all you have are hashed files, then you must have at some point: - done a reinstall - nuked the file and rebuilt it - converted it manually yourself - never actually cared about the change until you were slightly inconvenienced.
Re: [arch-general] Any way to decrypt hashes set by ssh HashKnownHosts?
eliott schrieb: Just because you can't see it doesn't mean it doesn't exist. unhashed known_hosts *is* more unsecure. If someone gets access to your account, they would get a) your key b) a list of hosts that the key is valid for hey! great! Compund this with the fact that many people use keys without a passphrase (a bad practice), someone can 'harvest' known_host data, and worm out to other hosts.. here is the kicker ... in a way that is easily automated. The point is, without any notice, we provided a different configuration file than the upstream configuration file. That's not how we do it, we always provide the upstream configuration file. If someone thinks that having unhased known_hosts is a security problem, then he/she can change this configuration option on his/her system, that is how Arch works. But now that hashed known_hosts silently became the default, I cannot revert back. signature.asc Description: OpenPGP digital signature
Re: [arch-general] About Arch pkg compress format
On Wed, May 21, 2008 at 5:47 PM, Dimitrios Apostolou <[EMAIL PROTECTED]> wrote: > > Can't this problem be circumvented by spawning the lzma command line > utility, and piping all data to it? I understand that this perhaps > negates the purpose of libarchive, but the overhead should be small. > That indeed totally defeats the purpose. We currently have a neat and transparent way to access all kind of different archives supported by libarchive, without any hacks.
Re: [arch-general] Any way to decrypt hashes set by ssh HashKnownHosts?
On Wed, May 21, 2008 at 9:50 AM, Dimitrios Apostolou <[EMAIL PROTECTED]> wrote: > Hi, > > Was this change forwarded to the OpenSSH developers? I am sure that if > it is indeed better security-wise to hash the known_hosts file, they > would change the default configuration upstream. I'm also sure that they > would give very good reasons for not wanting to do so. It's not a patch, it's a config file setting that we switched from "off" to "on"
Re: [arch-general] network manager cannot connect to AP with a hidden ssid
Marc Deop i Argemí wrote: On Tuesday 20 May 2008 19:43:13 metin wrote: any ideas? Are you using iwl3945? If so, don't bother trying it because is a known problem. my wireless card: 02:03.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02)
Re: [arch-general] About Arch pkg compress format
Hi, On Tue, 2008-05-20 at 10:14 +0200, Jan de Groot wrote: > Pacman itself is ready for .tar.bz2 package files. The whole issue > with .bz2 files is that compression and decompression times increase a > lot without giving the same amount of size reduction back. We've done > some recent tests with LZMA, which compresses just as good as bzip2 at > the lowest compression rate, but does it at the same speed as gzip. About LZMA I should add that when using higher (actually the default) compression rate, compression is much better than bzip2 but takes more time/memory. Decompression however, which is what really matters in a packaging format, is kept fast and lightweight. > The > downside is that LZMA is not supported by libarchive, and won't be > supported officially either, because libarchive is BSD licensed and LZMA > is GPL licensed. Can't this problem be circumvented by spawning the lzma command line utility, and piping all data to it? I understand that this perhaps negates the purpose of libarchive, but the overhead should be small. Thanks, Dimitris
Re: [arch-general] Any way to decrypt hashes set by ssh HashKnownHosts?
On Wed, May 21, 2008 at 4:50 PM, Dimitrios Apostolou <[EMAIL PROTECTED]> wrote: > Hi, > > Was this change forwarded to the OpenSSH developers? I am sure that if > it is indeed better security-wise to hash the known_hosts file, they > would change the default configuration upstream. I'm also sure that they > would give very good reasons for not wanting to do so. > > So I just went googling about this stuff. I saw this option got enabled years ago on Debian, and after that a few users complained about that change, but without any real reasons. (so a bit like what is happening here now :)) Anyway, there was a huge thread on debian mailing list, I finally found one mail which partially answers your question : http://lists.debian.org/debian-devel/2005/07/msg00041.html
Re: [arch-general] Any way to decrypt hashes set by ssh HashKnownHosts?
Hi, Was this change forwarded to the OpenSSH developers? I am sure that if it is indeed better security-wise to hash the known_hosts file, they would change the default configuration upstream. I'm also sure that they would give very good reasons for not wanting to do so. Thanks, Dimitris
Re: [arch-general] Eclipse won't start any more
David Rosenstrauch wrote: > Juergen Starek wrote: > >> a few days ago, my Eclipse installation (which had worked fine for >> some months before that) stopped working. > > I'm not experiencing this problem, but a bunch of people started > running into another problem with Eclipse since the upgrade to Firefox > 2.0.0.14. > > http://bugs.archlinux.org/task/10066 Thanks a lot, that was my problem! Luckily, I don't rely on Firefox because I generally use Konqueror, so removing the Firefox package was no problem for me. However, I'll look into this more deeply over the weekend, perhaps I can find out something helpful. It's just really strange that I seem to have been the only one getting this particular exception; at least, googling for it did not show any other forum or usenet posts about it... Regards, Jürgen
Re: [arch-general] thunderbird 2.0.0.14: Don't see attachments anymore
Xavier wrote: On Tue, May 20, 2008 at 1:44 PM, Allan McRae <[EMAIL PROTECTED]> wrote: I can confirm it does not happen with the official binaries, although the icons do not show but that could be because I ran it from my home directory. I have also rebuilt via abs to get branding and that does not help. Time for a bug report And if anyone has the time, what happens when building a vanilla thunderbird, that is, without these 12 patches? :) I just built it with absolutely minimal patches (one is needed to add -X11 to LDFLAGS), and there is still a problem. Looks like the latest thunderbird does not play nice with one of our libraries. To track this down will require building with most of the --enable-system- options removed from the mozconfig. Allan (CCed bug report)
