- Arch-dev-public - lists.archlinux.org

Re: [arch-dev-public] [arch-dev] Getting to New Arch SCM Layout and Repo Management
by Paul Mattal 29 Apr '07

29 Apr '07

Dan McGee wrote: >> 6) The system will allow anyone with SCM access to register as a >> maintainer for a package. > > So if I read this right (or at least the way I was thinking), there > can be multiple maintainers for a package? I think this is the right > route to take- strict ownership of a package seems unnecessary. This is correct, though when I re-read this goal I realized I need to make that clearer! The idea is that anyone with SCM access can register as a maintainer (really a "regular contributor") on this package, so that when group thinking or decision making needs to happen for the package, you know who to coordinate with. This encourages more people to become involved in more packages that interest them. It also discourages people from holding onto ones they have grown tired of, which I believe is an equally important effect. > One of the things I noticed after being "inducted" as a dev was the > sparsely documented and slightly cobbled together toolchain. I think > if we are switching to a new system and layout, we should do it right > from the beginning and make the tools easy to understand, documented, > and able to work anywhere- not just on gerolde. In addition, pacman, > developer, and server side tools should work in harmony. Exactly my intent. You are a perfect fit for a developer on this project. The goal is, indeed, to make this the seamless equivalent of pacman for doing the other half. In fact, I was thinking we might want to call the most visable commandline tool "repoman". Very glad to have someone active on pacman development aboard, since the two really are halves of the same puzzle. My goal for next week is to get the box up and running, and to continue to flesh out some thoughts. My sandbox for this so far for this is at: https://subzero.elys.com/svn/repoman/trunk/ If you would like commit access, send me (privately) an htpasswd -n line. Welcome aboard! - P

1 0

Re: [arch-dev-public] [tur-users] Ion3 trademark infringement
by Thomas Bächler 29 Apr '07

29 Apr '07

Tuomo Valkonen schrieb: > The package "ion3-darcs" [1] on AUR is infringing on the Ion3 > trademark. It is not Ion3 anymore, as it modifies the installed > program in such a manner (by applying the Xft patch), that it > can not be considered the original product anymore, but a > competing one. The package must be renamed so that it can not > be confused with Ion3(tm), or the Ion project. If this is not > done, there may be legal repercurssions. > > [1]: http://aur.archlinux.org/packages.php?do_Details=1&ID=10622 This thread has just been brought to my attention and I am posting this to the tur and arch development mailing list. I suggest that we drop the modified ion version from AUR. I also strongly suggest that we remove ALL ion-related packages from AUR and official repos, as well as all other packages that have been released by the author. Arch always tries to provide the best and latest for its users. In doing so, we cannot afford getting sued. So if a package author THREATENS us, then there is no place for his/her software in our distribution and the only possible response is to not provide it any more, no matter how good it is. I am really disappointed that people have to resort to these kinds of actions, and I am sorry that I feel obligated to the proper reactions.

1 0

[arch-dev-public] Building and uploading with pacman 3
by Dan McGee 28 Apr '07

28 Apr '07

This is just a quick note for devs regarding pacman 3 (specifically makepkg) package naming. We eventually are switching to a scheme where the arch is tacked on to the package name, and makepkg 3 names packages this by default. However, this breaks backwards compatibility with pacman 2.9.8 and down, so we cannot do this in the official repos yet. Here is one way to quickly fix this (as a bash function): makeoldname() { mv $1 "${1%-*.pkg.tar.gz}.pkg.tar.gz" } JGC also suggested that you can just edit makepkg for now and have it output the old-style name. Finally, what is a good timetable for changing the uploaded package names? If we treat pacman a bit special and always name it without an arch, people will always be able to upgrade to it, and from there do a full sysupgrade. -Dan

1 0

[arch-dev-public] Sizes of repos and maintainers
by Dan McGee 25 Apr '07

25 Apr '07

First, let's get a few numbers out there. Sizes of official repos: current: 563 extra: 2019 community: 1196 Number of "maintainers": Devs: 27 TUs: 25 The second set of numbers is harder to pin down. For devs, I took the number from the devs page; someone who has been here longer could better state the breakdown between architectures or between active and passive. For TU's, I grabbed it from the AUR front page, once again not knowing how many are active. Given the above numbers, and this repeats what has been stated elsewhere by Alexander, devs have roughly 95 packages each ((563+2019)/27) to maintain if the load was distributed evently. Because we know it is not, Alexander came up with a figure of 16 active maintainers, giving each dev 156 packages. Thats a lot, and it leaves very little room or time for devs to do anything besides package maintenance. Compare this to the TUs workload. Each TU should have roughly 48 packages to maintain, a much more reasonable number and either 1/2 or 1/3 of what a dev is expected to do. This also gives them some time to patrol the AUR and check packages that haven't made it into community. Two proposals to let sit in the pot: 1. Downsize extra to a more reasonable size, and move some of the maintenance to TU's by shifting packages to community. This would likely require a few more TUs being "hired on". 2. Redefine what it means to be a dev. Have a three-tiered system of sorts, with increases in permissions to change things as you move up the ladder. This would basically stick another group between Devs and TUs that could help maintain the huge number of packages we have in extra. This would likely require a few more TUs being hired and some TUs shifted to higher levels of responsibility. Yes, radical ideas, but don't shoot me for them. Comments appreciated. -Dan

4 5

Re: [arch-dev-public] Fw: OpenSSL 0.9.8e has serious bug
by Tom K 25 Apr '07

25 Apr '07

David Rosenstrauch wrote: > Tom K wrote: >> David Rosenstrauch wrote: >>> Tom, >>> >>> I use EncFS pretty extensively, so I can assist you with testing if >>> you need. >>> >>> DR >>> >> >> Thanks David. >> >> Get it here for now: >> http://www.archlinux.org/~tom/packages/openssl-0.9.8e-3.pkg.tar.gz >> PKGBUILD and patch here: >> http://www.archlinux.org/~tom/packages/openssl/ >> >> I've asked the original reporter for details on the known >> OpenSSL/Blowfish problem, for inclusion in Arch News etc. >> >> T. > > Hi Tom. I just upgraded and tested. > > It's basically like Valient's mail said - the encrypted directory that I > made with the broken version of openssl-0.9.8e was now unreadable with > the new fixed version: > > [darose@davidrlin pr]$ encfssh .d2 d2 > EncFS Password: > Error decoding volume key, password incorrect > encfs failed > > But, like I did when we upgraded to the broken version in the first > place (http://archlinux.org/pipermail/arch/2007-March/013925.html) I > just deleted the bad encrypted directory and then recreated it. (I keep > the contents in a RCS, so it's easy for me to just pull them from there > again.) In retrospect, hat wasn't necessarily the correct thing for me > to do. Other people commented that they just remained downgraded on > openssl-0.9.8d. That avoided the bug, and let them keep using their > existing encrypted directories. But since recreating the directory was > no big deal, that worked for me. > > Anyway, after I whacked and recreated the directory, encfs seems to be > working fine. I'm able to unmount the encrypted directory and then > mount it again without a problem. > > So I think the fix is fine. Only caveat is that, like Valient said, > anyone who's created any encrypted directories using the broken version > will need to whack them and start again. You might want to reference > Valient's email and/or this Arch email thread > (http://archlinux.org/pipermail/arch/2007-March/013924.html) in whatever > communication you send about the issue. > > Hope this helps. Any further questions, or need me to do any more > testing, please feel free to write back. > > DR > > Many thanks for the comprehensive reply, David. I'm still waiting to hear from Valient regarding his tests, but I'll put the fixed package into testing anyway, with appropriate accompanying messages. T.

1 1

[arch-dev-public] Fwd: Consensus on network scripts
by James 24 Apr '07

24 Apr '07

oops, this one didnt make the ML, my bad. Anyone got any other comments? If I put these to a poll everyone would vote for their inclusion? Otherwise.. please say :) It's unfair otherwise if I don't get a chance to fix problems or respond to complaints. James ---------- Forwarded message ---------- From: James <iphitus(a)gmail.com> Date: Apr 21, 2007 8:32 AM Subject: Re: [arch-dev-public] Consensus on network scripts To: David Rosenstrauch <darose(a)darose.net> On 4/21/07, David Rosenstrauch <darose(a)darose.net> wrote: > James wrote: > > Yes, laptops are moved between wireless networks, but this does not > > mean that static configuration is inappropriate. My laptop for > > example, has long moved between home, and school/uni and a coffee shop > > I frequent. Three, unchanging networks. Most users of wireless have > > networks they frequent often like this. > > > > Look at my scripts, they're not as complex and error prone as you'd > > think. Most distros *do* have wep support in their scripts, and I see > > no reason why wpa shouldn't be afforded that same level of support. > > Arch is a different distro to "most other distributions". > > > > NetworkManager is not a solution. It's gui dependent. To use it, means > > loading up either KDE or Gnome. This is a ridiculous dependency for > > network connectivity. Developing a command line based client would > > be... nice. But, I don't have the experience to develop it, and arch > > needs better network scripts two years ago. > > Hi James. Was just reading through your email with interest. > > I also use my laptop for roaming ... and often start up the network from > the command line, instead of a UI. > > But I'm just wondering: what do you feel is wrong with arch's current > wifi network scripts? I use them (i.e., with /usr/bin/netcfg --menu) > and they don't seem to give me any problems. The current scripts: - Messy codebase, as features have been hacked in over time, without much plan or thought to the big picture. - Config syntax is messy and inconsistent. - All the logic and code is in netcfg, so nothing can be used outside of it. - As a result of the last, netcfg is *big*. Having everything in one file, as anyone knows, is nasty. - Using bash files as a configuration mechanism can be awkward, take a look through and you'll see lines of mass 'unset's trying to clear out variables. - Negligible error checking. You get failed connections that uh don't fail? - Are very difficult to track down why a profile has failed, and what could cause connection problems. - netcfg only deals with simple wireless configurations, these scripts are generic and can tackle any type of connection, given a lib/netcfg/connection/ script is written for them. My scripts are based on the current ones, but the above are all fairly big problems, albeit, many internal, so fixing and improving them, ended up becoming a rewrite of the scripts. There's other things I thought might be best to change too, like moving all network scripts to a separate package, and separating out the initscripts. > I usually just use knetworkmanager for connectivity. But on the > occasions that I need to use it from the command line, netcfg seems > quite adequate. I just set up a new profile, and then select it from > the netcfg menu. > > What do you think needs to be urgently improved about this process? It's a fine process, I just hope to bring our network scripts to a higher level of functionality, make them easier to use, more reliable, and easier to deal with when things go wrong. James -- iphitus // Arch Developer // kernel26beyond // iphitus.loudas.com -- iphitus // Arch Developer // kernel26beyond // iphitus.loudas.com

1 0

[arch-dev-public] Short hiatus
by Travis Willard 23 Apr '07

23 Apr '07

Hey guys, Well, school's done for me. Like, done-done. I'll get my diploma in June, whee! Honours Co-op Bachelor of Math, Computer Science. Anyway, enough tooting my own horn - with a couple weeks off before I start work (my first full-time, heh) the wife and I are doing a quick trip to visit people we haven't seen in a long time. We're leaving tomorrow (Monday) and won't be back until at least Saturday - so for at least that long I won't be available for what developer-work I do. I've updated what packages I can - fglrx just released a new version, and I'll hopefully get to that update before I go to bed tonight, and smb4k is out of date but berlios.de's down right now so I can't update that - might be a good thing though if somebody's going to move kde to /usr soon; wouldn't want to overlap with their work. Anyway, see you in one to two weeks. :) -- Travis

2 1

Re: [arch-dev-public] [arch] kernel 2.6.20.7, acpi changes and alsa bumped to 1.0.14rc3
by James 22 Apr '07

22 Apr '07

On 4/15/07, Tobias Powalowski <t.powa(a)gmx.de> wrote: > Hi folks, > the new kernel has acpi modules as much modularized as possible, it was > requested due to some people having problems with the monitoring modules in > the kernel. > > I have written a small wiki about the acpi modules, you need to add them to > your MODULES=() array in rc.conf. > Why wasnt this put into testing first at least? As we can see from the thread in [arch], we've already come across one person whose fan is controlled via acpi... and had an overheat as a result. Secondly, is modularising them really a solution? - You could have tracked down which one exactly is causing the problem, and modularised that - Or heaven above, file a bug upstream at LKML. - If this is a real problem, then other distros would have done the same, and you should have found their autodetection scripts before doing this here. this is going to annoy more people than it is going to fix problems for, and this is unacceptable when there's other solutions available. and... what was the bug? can't find it on the bug tracker. James -- iphitus // Arch Developer // kernel26beyond // iphitus.loudas.com

2 2

[arch-dev-public] Fw: OpenSSL 0.9.8e has serious bug
by Judd Vinet 21 Apr '07

21 Apr '07

Begin forwarded message: Date: Tue, 17 Apr 2007 23:32:26 -0700 From: "Valient Gough" <valient(a)gmail.com> To: jvinet(a)zeroflux.org Subject: OpenSSL 0.9.8e has serious bug I've had reports from a couple users of Arch Linux that EncFS is unable to access their existing encrypted filesystems after upgrading Arch packages. The problem is that OpenSSL 0.9.8e has a known problem with Blowfish encryption which makes it incompatible with any other versions of OpenSSL. EncFS users will not be able to read filesystem which use Blowfish with key length > 128 bits, and if they create a new filesystem when using OpenSSL 0.9.8e, then they will not be able to access their filesystem when using the next release of OpenSSL with that bug fixed. See: http://cvs.openssl.org/chngview?cn=15978 regards, Valient

4 4

[arch-dev-public] DistroWatch blurb
by Roman Kyrylych 21 Apr '07

21 Apr '07

Just wanted to remind the old topic http://bbs.archlinux.org/viewtopic.php?id=16767 because IMHO our DistroWatch blurb is still not as good as it could. For example it has "i686-optimized" but doesn't mention x86_64. There was http://wiki.archlinux.org/index.php/New_distrowatch_blurb where some nice proposed descriptions were collected, but it's deleted now (don't know when it happened). Suggestions? -- Roman Kyrylych (Роман Кирилич)

1 0