- Arch-general - lists.archlinux.org

[arch-general] SSH Tunnel doubts
by Daniel. 19 Jul '11

19 Jul '11

I have some doubts about traffic forwarding Supposing that my IP is 192.168.1.100 and the remote is 192.168.1.200 is this -> ssh -R 1000:192.168.1.200:22 the same as this: ssh 192.168.1.200 ssh -L 1000:192.168.1.100:22 ??? -- *"Do or do not. There is no try"* * **Yoda Master*

7 10

Re: [arch-general] [arch-dev-public] dropping tcp_wrapper support
by Thomas S Hatch 19 Jul '11

19 Jul '11

> > > I would say the same, but a todo list isn't a to-done list, so keep > that in mind. He also pointed out that I got little to no feedback > when I asked about this both a year and six months ago, so > expectations are pretty low this time around. I'm sure if there were > serious objections people would raise them and we could address them. > > This is worthy of a news article once we move packages to core only > because it could expose some services people didn't previously expect > to need to protect. > > -Dan > As far as feedback goes, I have used tcp-wrappers a great deal in the past, but not for many years. And the fact that it needs to be so heavily patched suggests that we should not be using it anyway. I agree that we should not have to maintain it anymore, it is an outdated security system that usually gets in the way, and Arch is the only distro I use that turns it on by default. +1

15 27

Re: [arch-general] virtualbox additions package naming
by Kwpolska 19 Jul '11

19 Jul '11

On Jul 19, 2011 4:12 PM, "Ionut Biru" <ibiru(a)archlinux.org> wrote: > > I've been criticized a lot because I choose poorly the name for guest additions. > > Right now the packages are like this: > > virtualbox-addtitions - contains the iso with guest additions for linux/windows/etc and is installed on host > virtualbox-guest-additions - contains guest additions only for an arch linux system as guest. > virtualbo-guest-modules - modules only for an arch linux system as guest. > > Now that virtualbox 4.1 is released I need help choosing this names. > > > -- > Ionuț I'd suggest: * virtualbox-additions-iso * virtualbox-additions-guest * virtualbox-additions-guest-modules -- Kwpolska (sent from Android)

2 1

Re: [arch-general] [arch-dev-public] Fwd: Move kdelibs3 to [community]
by Calvin Morrison 19 Jul '11

19 Jul '11

On 18 July 2011 12:57, Calvin Morrison <mutantturkey(a)gmail.com> wrote: > ---------- Forwarded message ---------- > From: Calvin Morrison <mutantturkey(a)gmail.com> > Date: 18 July 2011 12:50 > Subject: Re: [arch-dev-public] Fwd: Move kdelibs3 to [community] > To: kb9vqf(a)pearsoncomputing.net > > > On 18 July 2011 06:36, Thomas Bächler <thomas(a)archlinux.org> wrote: >> Am 18.07.2011 12:25, schrieb Stéphane Gaudreault: >>>> Sergej offers to maintain it so I thought we can move it in [community], but >>>> if you are interested you can adopt qt3 and kdelibs3. >>> >>> Maybe we could follow the kdelibs from Trinity [1]. I have no experience with >>> this project, but they seems to be active. Or at least their svn repos [2] >>> could be searched to find useful patches. >>> >>> Stéphane >>> >>> [1] http://www.trinitydesktop.org/ >>> [2] http://websvn.kde.org/branches/trinity/kdelibs/ >>> >> >> This sounds like a good idea, better than trying to build the broken >> kdelibs3 code like we do now. >> >> Hey Guys, I am a developer and member of the Trinity Desktop team. I wanted to clear up a few points here about what the differences between old kde and trinity are as far as you are concerned. Kde3 and Trinity are NOT the same. At this point our sources and contributors have changed completely. One of our goals is to pull all of the disparate Qt3 patches to create a central, up-to-date Qt3 repository that can then be extended as necessary, and we are ready to provide upstream support for qt3. Even with our patches and addons, our qt3 is fully compatible with any qt3 programs, no API breakage whatsoever. I think it would be a great id Link to webgit of qt3: http://git.trinitydesktop.org/viewgit/index.php?a=tree&p=Trinity%20Desktop%… Kdelibs3 on the other hand won't be so simple. There have been significant changes in the API, because we have written a abstraction layer for the Qt3 code to work with "TQt". The TQt interface will allow us to continue using the trinity desktop with newer versions of Qt. We currently are underway porting it to Qt4 too keep up to date. However for arch that means it is likely that some programs would not compile unless patched against the tqtinterface. Therefore I must recommend you do not use our kdelibs3, because we are currently unstable until the next release (due sometime in the fall) What I think would be best for everyone, is that once we release our next version, arch should look into switching to the Trinity Desktop provided kdelibs3, kdebase, kde* packages. They are more up to date and stable. I think the fact you are having trouble building old kde3 shows that it might be time to start considering other options. As far as Qt3 goes, we are completely ready and happy to provide upstream support for all distros, especially my favorite Arch. :) On behalf of the Trinity Project, Calvin Morrison

2 1

Re: [arch-general] [arch-dev-public] DNS and SSL Cert
by Matthew Monaco 18 Jul '11

18 Jul '11

On Mon, Jul 18, 2011 at 4:46 PM, Aaron Griffin <aaronmgriffin(a)gmail.com> wrote: > Two things are coming up here, and I just want to bring this > discussion up again. > > * DNS > > Our everydns account is going away. According to their site > (http://www.everydns.com/) we have 43-ish days to get everything moved > off. > > We have a handful of options, some free, some not. > > a) https://pointhq.com/ - I use this personally. Maybe not the > snappiest DNS servers in the world, but the interface is easy. > b) http://reflected.net/ could host our DNS, but we'd need to manually > contact people to change things > c) Use our registrar (godaddy) > d) Other? > > * SSL Cert > > Our StartCom cert is expiring. I need to reconfirm my identity with > them, but I can get to this as early as tomorrow. Have we had any > major issues with using a cert from these people? Now would be the > time to switch, if so. > > Cheers, > Aaron > I'm really happy with my dyndns service.

1 1

Re: [arch-general] News draft for dropping tcp_wrappers
by Grigorios Bouzakis 17 Jul '11

17 Jul '11

Dan McGee wrote: > Dropping tcp_wrappers support > > Due to upstream not having released a new version since April 1997, we > are dropping `tcp_wrappers` support from all packages and removing the > package from `[core]`. In addition, newer daemons and applications are > inconsistent in their support for libwrap, leading to confusion as to > whether an application supports the library. > > If you currently use `/etc/hosts.allow` or `/etc/hosts.deny` for > security or logging purposes, you will need to adjust accordingly and > use another tool such as `iptables`. > Why has this been announced since it hasnt happened yet? Isn't that the point of news? Announce something thats taken place. But this is still in testing which isnt a news worthy place. Greg -- () against html e-mail | usenet & email communication netiquette /\ www.asciiribbon.org | www.netmeister.org/news/learn2quote.html

2 2

[arch-general] OK so HARDWARECLOCK="localtime" is "strongly discouraged" BUT???
by Joe(theWordy)Philbrook 16 Jul '11

16 Jul '11

It would appear that on 2011-05-02, www.archlinux.org/news/initscripts-update-1/ did say: > We now strongly discourage the use of HARDWARECLOCK="localtime", as this > may lead to several known and unfixable bugs. However, there are no plans > to drop support for "localtime". And it would appear that /etc/rc.conf now does saith: > # HARDWARECLOCK: set to "UTC" or "localtime", any other value will result > # in the hardware clock being left untouched (useful for virtualization) > # Note: Using "localtime" is discouraged. Since I multi-boot AND do keep my hardware clock set to local time, I'm a little bit concerned by this statement. It gives me two questions. 1) just what "Known" bugs that this could lead to are "UNFIXABLE"??? 2) While putting something like 'HARDWARECLOCK="DoNotMessWithMyLocalTime"' would evidently result in the hardware clock not getting overwritten by the system time on shutdown, How would any value except 'HARDWARECLOCK="localtime"' tell Arch not to expect the hardware clock to be set to UTC on startup??? I guess I could install ntp and put ntpd -qg & in rc.local with the above non-standard rc.conf HARDWARECLOCK definition to nearly simulate the previous NON-NTP localtime behavior where the hardware clock was read {at start-up} AND written {at shutdown} BOTH with a conversion from/to local time... In that it while it would {I think} incorrectly initially set system time on boot by interpreting the hardware clock's value as UTC, it would then use ntp to correct itself to approximately the same time as was indicated by the local time value that was already in the hardware clock. And then go away. Then since HARDWARECLOCK wasn't set to either "UTC" nor "localtime" It shouldn't actually overwrite the hardware clocks localtime with UTC... My hardware clock may need to be manually reset a little more often But that's no big deal. The problem is if for some reason I should boot up when the internet isn't accessible, there would be no ntp server to correct Arch's misconception that the hardwareclock was already in UTC which would result in bogus timestamps on any files I modified during that time (not to mention bogus clock displays...) -- | ~^~ ~^~ | <?> <?> Joe (theWordy) Philbrook | ^ J(tWdy)P | \___/ <<jtwdyp(a)ttlc.net>>

9 15

[arch-general] anyone success with compilation of cyanogenmod7?
by dejfson 16 Jul '11

16 Jul '11

Hi All, has anyone success to compile CM7 under Archlinux? I'm new to Arch, before user of Gentoo, so I'm still in learning phase. In my case the issue seems to be missing perl's "Switch.pm" module. Looking for arch package on the web was of no success. Any help appreciated d.

3 5

[arch-general] docs in Octave package?
by XeCycle 16 Jul '11

16 Jul '11

Hello, I read from the package database that Ronald van Haren maintains the package "octave", but I cannot contact him, so I'm asking here. I need the documents of octave, but it's not in the current octave package, so I need to compile it manually after each update. However the compilation is very time and power consuming, it can drive my CPU to 100 degrees --- which is not very fine for a laptop. Could you please build a separate "octave-docs" package? -- Carl Lei (XeCycle) Department of Physics, Shanghai Jiao Tong University OpenPGP public key: 7795E591 Fingerprint: 1FB6 7F1F D45D F681 C845 27F7 8D71 8EC4 7795 E591

4 6

[arch-general] [signoff] lvm2/device-mapper 2.02.86-1
by Eric Bélanger 16 Jul '11

16 Jul '11

Hi, lvm2/device-mapper 2.02.86-1 are in testing for an upstream update. Please test and signoff. Signoff from users are welcomed. Eric

1 1