- Arch-general - lists.archlinux.org

Re: [arch-general] PPPoE broken on upload
by LoneVVolf 25 Apr '14

25 Apr '14

On 22-04-14 02:49, Wayne S wrote: > No answers on previous post so starting new topic. > > Recent updates have caused problems with my PPPoE FIOS link. The upload speed has been reduced to near zero. > > I "was" using arch linux box as a firewall router. I have a verizon fios connection that still uses the old pppoe. Recently the pppoe connection upload bandwidth went down to < 50kbps (normally it is >25Mbps), however the download bandwidth is still around 58Mbps. > > There was a recent thread about recompiling PPP to 2.4.6, however, whatever this change did in recent updates, has broken my router PPP connection upload speed. What was the previous version of ppp that did work ? > During boot pppd 2.4.6 is started and the message RP-PPPoE plugin version 3.8d compiled against pppd 2.4.6. I see no errors. latest rp-ppoe version in repos is 3.11.5 , have you tried with that version ? please post a complete log of a boot. > I switched over to using the Verizon actiontec fios router and it works OK. I switched over to an archlinuxarm on a Utilite computer, and it works OK. what version of ppp /rp-ppoe does the archlinuxarm system use ? Have you compared the arm PKGBUILDs with the x86_64/i686 PKGBUILDs ? > I built a new arch based firewall router on a different computer, and it has the same problem with the latest Arch on my existing router. Which leads me to conclude that something went wrong with pppoe after the recompile to 2.4.6. > > Any help would be welcome on what is going on, or how to diagnose. > > Wayne > > > > Was the new arch based fw router a fresh install, or an existing system ? Note : I know a bit about the ppp/rp-pppoe protocols but next to nothing about it's practical use. My questions are intended to get information that will help troubleshooting this. Lone_Wolf

2 2

[arch-general] [Classroom] Intro. to PKGBUILD class - April 19th
by fsckd 23 Apr '14

23 Apr '14

Hello, There will be a class on PKGBUILDs by CalimeroTeknik. It will cover the basics of packaging and how to write a PKGBUILD. Everyone is welcome to attend. The only prerequisite is an interest in the topic. Here is a list of topics that may be covered. You can vote for those which interest you. The ones with the most votes will get more attention in the class. https://pad.riseup.net/p/pkgbuild-class-apr2014 Dates and times: Saturday, April 19, 2014 9:30AM UTC (~7:30PM in Brisbane AU and ~10:30 in Wellington NZ) 4PM UTC (~12 noon in New York and ~9am in Vancouver) CalimeroTeknik is a bash hacker and a student. He is a longtime Arch Linux user (since about May 2008) and released http://ctkarch.org/ in 2009.

7 8

Re: [arch-general] PPPoE broken on upload
by Ralf Mardorf 23 Apr '14

23 Apr '14

On Tue, 2014-04-22 at 22:14 -0400, Wayne S wrote: > I'm not sure how to downgrade to them to test. https://aur.archlinux.org/packages/downgrade/ JFTR I'm using PPPoE too, but don't do uploads and tend to use oldish linux-rt kernels, so I can't say anything about the upload issue.

1 0

[arch-general] How do I preserve changes to okular.desktop?
by Chris Moline 23 Apr '14

23 Apr '14

Hi, every time I upgrade okular chrome starts opening two instances. One has a dialong saying it couldn't find '%I' and the other has the document I want. All I have to do to fix it is to remove %I from the .desktop file. How do I preserve this change across upgrades? Alternatively, how do I get the '%I' to be expanded properly? Sorry if this is asked a lot. My search-fu was not up to the task.

4 3

[arch-general] CONFIG_TCP_CONG_VENO on Wifi link with a laptop
by Olivier Langlois 23 Apr '14

23 Apr '14

does anyone had a positive experience with this TCP congestion avoidance method with this particular setup?

2 2

Re: [arch-general] PPPoE broken on upload
by Felix Yan 22 Apr '14

22 Apr '14

On Monday, April 21, 2014 20:49:58 Wayne S wrote: > I "was" using arch linux box as a firewall router. I have a verizon fios > connection that still uses the old pppoe. Recently the pppoe connection > upload bandwidth went down to < 50kbps (normally it is >25Mbps), however > the download bandwidth is still around 58Mbps. I'm having a same problem. Just tried to either use linux-lts or downgrade linux to < 3.14 (like, 3.13.8) and it works properly. Could you confirm this? Regards, Felix Yan

1 0

[arch-general] Qt4 / Qt5 package naming
by Jerome Leclanche 22 Apr '14

22 Apr '14

Hi With Qt5 becoming more and more available throughout Qt apps (especially as KDE progresses into the switch), I think it's time to consider adopting an updated naming scheme. IMHO: - Qt4 apps should use the -qt4 suffix - Qt5 apps should not use any suffix or prefix - Qt libraries should probably use a qt- prefix. (eg what is currently qt5-base, qt5-doc etc should become qt-base, qt-location). Or alternatively, no prefix at all and use upstream naming scheme (qtbase, qtlocation, ...) Thoughts? J. Leclanche

2 1

[arch-general] PPPoE broken on upload
by Wayne S 22 Apr '14

22 Apr '14

No answers on previous post so starting new topic. Recent updates have caused problems with my PPPoE FIOS link. The upload speed has been reduced to near zero. I "was" using arch linux box as a firewall router. I have a verizon fios connection that still uses the old pppoe. Recently the pppoe connection upload bandwidth went down to < 50kbps (normally it is >25Mbps), however the download bandwidth is still around 58Mbps. There was a recent thread about recompiling PPP to 2.4.6, however, whatever this change did in recent updates, has broken my router PPP connection upload speed. During boot pppd 2.4.6 is started and the message RP-PPPoE plugin version 3.8d compiled against pppd 2.4.6. I see no errors. I switched over to using the Verizon actiontec fios router and it works OK. I switched over to an archlinuxarm on a Utilite computer, and it works OK. I built a new arch based firewall router on a different computer, and it has the same problem with the latest Arch on my existing router. Which leads me to conclude that something went wrong with pppoe after the recompile to 2.4.6. Any help would be welcome on what is going on, or how to diagnose. Wayne

1 0

[arch-general] How to track packages dropped from the repos?
by Lorenzo Bandieri 21 Apr '14

21 Apr '14

Hi list, Sometimes packages are silently dropped from the repos. This happened for example in the last few days with mash 0.2.0-3, which apparently I installed as a dependency for gnome (I guess it is no longer required). I follow arch-general, arch-dev-public and aur-general, and as far as I know, this change wasn't announced in any of these lists. I recall other examples in the last 2-3 years (this is roughly the time I've used arch consistently), but now I don't remember the packages involved. Currently I try to keep track of these changes by running e.g. "pacman -Qm" and "pacman -Qdt" once in a while, so it's no big deal. However, I think it would be interesting to know from a more "official" channel when a package is dropped and why. This would allow users to be aware of the change and decide whether the package is still needed (and act accordingly, e.g. if the package is dropped to AUR, one could subscribe to comments or check for updates) or can be safely uninstalled. I searched without finding anything decisive (e.g. these threads [1] [2] suggest possible workarounds in the form of scripts). I wonder if better methods to track dropped packages exist; if not, would it be feasible to implement a solution, e.g. a list where dropped packages are announced, similar to "last rites" in gentoo? Thanks for your time, Lorenzo [1] https://bbs.archlinux.org/viewtopic.php?id=147574 [2] https://bbs.archlinux.org/viewtopic.php?id=125665

4 5

[arch-general] GHC 7.8.1 packaging decisions for Arch Linux
by Thomas Dziedzic 21 Apr '14

21 Apr '14

Hello all, With the arrival of ghc 7.8.1 [0], I would like to address the following problems with a restructuring of how we treat haskell packages in archlinux: Problem 1: Updating any haskell package has been delayed until we bump ghc. Explanation: ghc is unable to produce a library that has a stable abi. In other words, if a library gets rebuilt (even if it's the same exact source), we will need to rebuild all package that depend on it, and this would in turn a messy rebuild for any kind of rebuild. Problem 2: Users are confused whether they should install packages from the repos or using cabal-install. This in turn sometimes causes them to install some packages from official repos, some from the aur, and some using cabal-install Explanation: Packages should ideally be installed from one place, either using repos/aur or cabal-install. Said that, it is entirely possible to use both repos/aur and cabal-install but for simplicity, one source is preferred. Problem 3: Our repos are unable to package every haskell package Explanation: hackage has over 5000 haskell packages in it currently. There is no way we will be able to support that many packages in our official repos without some kind of automation. And even if it would be possible, it would not necessarily be desirable. In addition, it is entirely possible to have multiple versions of the same package installed at the same time. Cabal has a very elaborate dependency solver in order to find versions that will work for all package versions installed. In addition, cabal-install 1.18 (the latest released) has added support for sandboxes, meaning that when developing haskell programs, you are now able to setup a sandbox environment that will only contain the haskell packages you want. I would like to propose the following changes to address the mentioned problems and having the ability to use sandboxes to isolate development environments. Change 1: Move every haskell related package out of [extra] into [community] except ghc and cabal-install. This includes the following 8 packages: haskell-http, haskell-mtl, haskell-network, haskell-parsec, haskell-random, haskell-text, haskell-transformers, haskell-zlib Explanation: These packages are only required to build cabal-install. Since we converted the cabal-install package to use the bootstrap script that comes with it, we no longer depend on these packages for anything in [extra]. Change 2: Make a news item stating that cabal-install is now the recommended way to install haskell packages. This wouldn't pollute the filesystem since cabal-install installs packages to the ~/.cabal directory by default. We might need to include a tip sheet about how you would handle ghc updates since it requires extra user steps. Change 3: Support users who are unable to install haskell packages that do not compile under archlinux. This would require working with the user and upstream to open up tickets and write patches for programs. At the very least we can work with the user if they do not to open up upstream bug reports and track them in our own bug tracker. There might be some packages which we would probably consider unsupported like bindings to packages that are not in the supported repos and packages that have no upstream activity and ones that are effectively unmaintained. Hopefully with the proposed changes, we can improve our user experience with using official tools to maintain haskell packages. I realize that some changes might be controversial especially change 3. This is why I posted this here in order to discuss the possibilities. I would also love to hear some opinions from vegai since he has some previous experience package haskell and has had similar thoughts in the past. Also if you're not a developer or trusted user, I would also like to hear your opinion since it would affect you also. Thanks for your time, - Tom [0] - https://github.com/ghc/ghc/releases/tag/ghc-7.8.1-release

6 8