- Arch-general - lists.archlinux.org

[arch-general] Wavpack support in Sox
by Kyle 30 Mar '11

30 Mar '11

Having recently migrated from Ubuntu, I notice that while Ubuntu's Sox package didn't support encoding to mp3, it did support Wavpack encoding and decoding, whereas in Arch, it supports mp3 encoding, but Wavpack seems to be unsupported. Am I missing an add-on that will make Sox support Wavpack, or do I need to rebuild the package with Wavpack support? ~Kyle

4 5

Re: [arch-general] Port 80 is shown open in port scan without any web server running
by Simon Perry 30 Mar '11

30 Mar '11

On Wed, 30 Mar 2011 14:06:48 +0530, Partha Chowdhury wrote: > Output from lsof: >> sudo /bin/lsof -i >> COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME >> pdnsd 1207 nobody 4u IPv4 2434 TCP localhost:domain >> (LISTEN) >> pdnsd 1207 nobody 5u IPv4 2435 UDP localhost:domain >> pdnsd 1207 nobody 8u IPv4 81232 UDP >> 172.16.37.164:40131->AS-20144-has-not-REGISTERED-the-use-of-this-prefix:domain >> linc 1214 root 5u IPv4 2448 UDP *:55089 >> ntpd 1216 root 16u IPv4 2451 UDP *:ntp >> ntpd 1216 root 17u IPv4 2455 UDP localhost:ntp >> ntpd 1216 root 18u IPv4 2456 UDP 172.16.37.164:ntp >> X 1377 root 1u IPv4 2964 TCP *:x11 (LISTEN) >> gweather- 1538 partha 18u IPv4 78973 TCP >> 172.16.37.164:53421->a125-56.222-11.deploy.akamaitechnologies.com:http >> (CLOSE_WAIT) I think you're confused. That's essentially a netstat, I can't see where you have 80 open on your IP of 172.16.37.164. It just shows you have a connection *to* port 80 to an Akamai host (a common provider of localised content used by many companies). -- Simon Perry (aka Pezz) [ s a n x i o n . n e t ]

2 3

[arch-general] inefficient handling of bug reports?
by Angus 30 Mar '11

30 Mar '11

When I file a bug report with the Flyspray web interface, why can't I specify the package it concerns? Having that option should make it possible for the package maintainers to be immediately and automatically notified of the report. The way it works now seems to be that I have to wait for some generic bug janitor to manually assign my report to the maintainer of the package (correct me if I'm mistaken). For example, I filed a bug report nearly two days ago, but apparently no janitor (or any other maintainer) has looked at it jet, which means all that time is wasted for hardly any reason (and no, I won't specify which bug. It's irrelevant to the issue I'm addressing here.) I believe the coders among us appreciate efficiency and automation, so maybe we can improve this system?

7 11

Re: [arch-general] Port 80 is shown open in port scan without any web server running
by Simon Perry 30 Mar '11

30 Mar '11

On Wed, 30 Mar 2011 16:18:47 +0530, Partha Chowdhury wrote: > initially I wanted to know why port 80 is shown open on my machine > and i gave the lsof output to show that no service was listening to > port 80 on my machine. The nmap output of the ip - that is my public > ip at the moment ( got that by visiting whatismyip.com) shows port 80 > as open when it should be blocked according to my iptables > configuration. > > Basically i was afraid some rootkit/malware was running web server on > my machine by making it invisible ! So your machine is 172.16.37.164, which you have to configure and tell your ISP because they NAT externally from 115.187.45.97 to many internal 172.16.37.* users? Therefore more than one person could have an external address of 115.187.45.97 mapping back to their 172.16.37.* IP? Even though only one person could have 115.187.45.97:80 mapped back to them? Are you sure about how this works? -- Simon Perry (aka Pezz) [ s a n x i o n . n e t ]

1 0

[arch-general] New Kernel - Virtualbox VM kernel crash on shutdown
by David C. Rankin 30 Mar '11

30 Mar '11

Guys, kernel26-2.6.37.5-1 running in a virtualbox vm is causing a kernel crash on shutdown. The full screen of the crash is here: http://www.3111skyline.com/dl/arch/bugs/kernel/vbox-crash-on-shutdown.jpg The Call Trace: shows the likes of: shrink_dcache_for_unmount_subtree shrink_dcache_for_unmount generic_shutdown_super <snip> I'm not great at reading the screens, so if you are interested in the full error, it is shown in the link about. Has anyone else found a workaround? -- David C. Rankin, J.D.,P.E.

6 8

Re: [arch-general] Removing network utilities from base group?
by Grigorios Bouzakis 29 Mar '11

29 Mar '11

Daniel Isenmann wrote: > Hi, > > I have a feature request (https://bugs.archlinux.org/task/22481) since > January which stated that rp-pppoe should be removed from the base > group. Described in the details he stated that every network package > should be removed from the base group and should only be in core. > > I'm not really have a opinion to that topic, so what do you think about > it? For me we can leave it as it is and do nothing at this topic, then I > will close this feature request as "won't implement". > > -Daniel > My own plan, originally brain0's but i adopted it and probably extended it as well, has been fully implementing https://bugs.archlinux.org/task/12890 Nevermind that its closed now, its only half done as far as i am concerned. Eventually make every package of core, besides the library dependencies, be part of a group, like base, base-networking etc. I dont know how much of a realistic plan it still is today, but i intend to look at it at some point. And that was part of the reason i opened those feature requests (theres similar ones for ppp, wpa_supplicant and dash as well). The core repo keeps growing and growing. Bootloaders, file system support utilities, dependencies like libedit get added. Yet the installer has only 1 package selection dialogue with all the applications. That works fine for packages in base and base-devel which are tagged as such, but not so much for the other packages which dont belong in a group, and especially libraries which are nothing more than dependencies to other packages. The installer has changed lately and from what i've read it includes the description of the packages.I had opened https://bugs.archlinux.org/task/12942 at the time about adding a seperate selection dialogue for each group, but i havent seen the new installer in action so i dont know if any of the above still apply, but that was my initial motivation from what i can remember. ---- Greg

1 0

Re: [arch-general] [arch-releng] Partition tools in AIF (was: Default Bootloader for AIF)
by KESHAV P.R. 29 Mar '11

29 Mar '11

On Tue, Mar 29, 2011 at 15:07, David Campbell <davekong(a)archlinux.us> wrote: > Excerpts from Dieter Plaetinck's message of 2011-03-28 12:06:21 -0400: >> Hmm, and does it have a proper UI in ncurses or something? to replace >> cfdisk in aif? > > It will when cparted is proper. Whether cparted will be ported to > use libparted directly, rather than using Python bindings, is yet > to be seen. I certainly prefer writing/maintaining Python code > over C though, and I don't see any benefit to translating it into > C other than avoiding Python as a dependency. > Instead of duplicating efforts, you can try hacking on http://www.gnu.org/software/fdisk/ which uses libparted as backend (fdisk and cfdisk present but no sfdisk though). That project is inactive but not discontinued. >> I know about the newt-based nparted but I'm told it's badly maintained. > > As far as I could tell, nparted is dead. > -- > David Campbell > Regards. Keshav

1 0

[arch-general] [signoff] kernel26-2.6.38.1-1
by Tobias Powalowski 28 Mar '11

28 Mar '11

Hi guys, please signoff 2.6.38 series for both arches. It's a security update too so it would make sense, to move in .38.1 to [core] soon. Upstream changes: http://kernelnewbies.org/LinuxChanges Features included: - latest stable patches - disabled /dev/kmem - added AMD_IOMMU support - kernel image is now xz compressed - NUMA is enabled on x86_64 - AUTOSCHED (aka the wonder patch) is enabled - aufs2.1 latest snapshot - added additional i915 patch - added radeaon kms fix greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

4 3

Re: [arch-general] inefficient handling of bug reports?
by Simon Perry 28 Mar '11

28 Mar '11

On Tue, 29 Mar 2011 00:18:14 +0800, Ray Rashif wrote: > There is no problem. What are you talking about? Anyone is free to > mention in the report what package they think is related. Which eludes to the original issue - instead of a wrangler, or team of wranglers, who have to deal with everything, let users do the initial assignment, then if it needs to go somewhere else, the team it's been assigned to can throw it back to the "wranglers". I digress, I think... > What information? You have a tracker, you know it's Flyspray, if you > can file a feature request with at least a demonstrated logic if not > a > PHP patch. If it's easy to implement, we might do it. Else, you can > go > upstream. > > Now, let's not get into why we use Flyspray in the first place. You > can ask the rest of the OSS world why they use what they use. I understand, but look, this is the first time I've ever commented on this list. Even though the button name makes no sense, I'll go back to lurking. -- Simon Perry (aka Pezz) [ s a n x i o n . n e t ]

3 3

Re: [arch-general] inefficient handling of bug reports?
by Simon Perry 28 Mar '11

28 Mar '11

On Mon, 28 Mar 2011 16:07:12 +0300, Ionuț Bîru wrote: > instead we chose to have some style but not everyone use it. I don't understand why people can't tell other people where they think the bug is. If it's not right, let the wrangler handle it. I think if someone is prepared to even consider submitting a bug report in an environment as intimidating as Arch, give them a go. Hell, I'm shit-scared about sending this e-mail. >> I believe the coders among us appreciate efficiency and automation, >> so >> maybe we can improve this system? > > only if we use bugzilla. Sorry if I'm wrong-top-posting or whatever, I'm using Roundcube. I've had an account on bugs.archlinux.org for a while, I still can't even see the "new bug" button, it doesn't exist as far as I can see. I don't see why being able to say "this bug is in package X" is such a problem, given that only the chosen people are able to create bugs in the first place. You always say you want people to help, but it seems so hard to do so, even when the information you have is easy to convey. -- Simon Perry (aka Pezz) [ s a n x i o n . n e t ]

5 6