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

[arch-dev-public] missing x86_64 packages
by Varun Acharya 23 Dec '07

23 Dec '07

Hi, Please upload the following, notice: Missing gcc-gcj-4.2.1-4-x86_64.pkg.tar.gz in ftp site notice: Missing deskbar-applet-2.20.1-2-x86_64.pkg.tar.gz in ftp site notice: Missing mplayer-plugin-3.50-1-x86_64.pkg.tar.gz in ftp site notice: Missing scim-pinyin-0.5.91-4-x86_64.pkg.tar.gz in ftp site

5 8

[arch-dev-public] Holiday Status
by Aaron Griffin 23 Dec '07

23 Dec '07

Hello Everyone, I wanted to let you know that I'm not going to be around all that much for the next few days. With Holiday parties at the office, and visiting family, I probably won't be sitting down at a computer until Wed. This means, sadly, I won't have the time to write up a big long status report. :( BUT, the good news is that I am on vacation until the next Wed. So with 7 days with nothing to do but Arch, I should be able to get a lot of ground covered. I'm sure other developers are in the same boat. This is on the announce list. Feel free to reply to this thread and let us know what you're up to - we can make it an impromptu mini-status report Me, personally, over the next week or so, I plan on getting a new initscripts release out the door, beginning work on the DB scripts revamp, and helping finalize everything that needs to be done for pacman 3.1. After all that is done, I want to take a look at Jason's svn repo implementation and begin making that switch over as part of the db script changes. Anyone else want to add anything?

3 2

[arch-dev-public] Man page symlinks
by Aaron Griffin 22 Dec '07

22 Dec '07

Ok, Jan brought this up twice now and I want to flesh this out. This is in relation to the filesystem/bash upgrades. On Dec 20, 2007 4:01 AM, Jan de Groot <jan(a)jgc.homeip.net> wrote: > So what does this do when /usr/man/man3 is a directory with manpages > and /usr/man/man3 is a symlink to /usr/share/man/man3 in the new package? > Shouldn't we move /usr/man to /usr/share/man in pre_install and pre_upgrade? Firstly, I don't think we should have these symlinks in the filesystem package at all simply because /usr/man is not specified in the FHS anywhere. We should technically never have a /usr/man dir at the completion of this ideal. If a *package* installs it, fine. By unsetting MANPATH in /etc/profile, man looks up pages via /etc/man.conf which includes both of these directories. In addition, by using symlinks at all, we run into the potential-and-always-confusing-possibly-working symlink/dir replacement stuff in pacman. Additionally, moving the man pages isn't a good idea. makepkg will NOT move them anymore. So, here's what we're left with: * Newly built packages will install to /usr/share/man * man will search both /usr/man and /usr/share/man for man pages * pacman -Qo will provide us with packages which need a rebuild It allows us to phase in the FHS man pages, and not do it all in one big lump. Backwards compat and all that. Is this acceptable?

3 2

[arch-dev-public] [signoff] dnsutils
by K. Piche 22 Dec '07

22 Dec '07

New dnsutils 9.4.2-1 in testing. Will update bind when dnsutils is signed off. k -- K. Piche <kpiche(a)rogers.com>

4 4

[arch-dev-public] adding "alias wlan0 ndiswrapper" to /etc/modprobe.conf
by Damir Perisa 22 Dec '07

22 Dec '07

hi devs, i just got surprised by this post-install message: (2/2) installing ndiswrapper [##################################################] 100% adding "alias wlan0 ndiswrapper" to /etc/modprobe.conf ... on what logic is ndiswrapper adding wlan0 to be ndiswrapper? this should not be. you cannot assume that the user wants wlan0 to be a ndiswrapper device. it may (as in my case) be wlan1 because wlan1 is the internal wireless device (intel 4965). let the user configure things like this by himself, no? - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><

2 4

[arch-dev-public] [signoff] iwlwifi 1.2.22
by Tobias Powalowski 21 Dec '07

21 Dec '07

Hi please signoff both arches greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 3

[arch-dev-public] [signoff] kernel26-2.6.23.12-2
by Tobias Powalowski 20 Dec '07

20 Dec '07

Hi kernel for both arches in testing, please signoff addresses those 2 bugs: http://bugs.archlinux.org/task/8949 http://bugs.archlinux.org/task/8948 - cleaned up cvs - removed alsa - updated unionfs greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

6 7

[arch-dev-public] Status Report: 2007-12-11
by Aaron Griffin 20 Dec '07

20 Dec '07

ArchLinux Status Report, 2007-12-11 =================================== Aaron Griffin I apologize for the delay here - yesterday was a long day for me, and I didn't have the time to sit down and write this out (it is a tad time consuming, as you can probably tell). == Newsworthy Items == * TLLTS Interview I hate self-promotion as much as the next guy, but TLLTS wants to do an interview about me tomorrow at 20:30 EST. Some of you may be interested. It'll be freeform, so I don't know what we'll talk about, but it will probably be related to where we're going in the near future. More here: http://www.tllts.org/ == Completed Tasks == * Developer signoff clarification When I originally initiated the "signoff" buffer for core packages, I had intended that the developer requesting the signoff count as one of the "two required" signoffs per architecture, as it is assumed a given developer tested a package before uploading and is also responsible. To clarify: We need two developers responsible for each physical package - two for each architecture. These two can include the original uploader. These people are responsible for any issues caused by this release of the package. They're also the people we have to point fingers at 8) * Mailing list rename We've renamed two of our most important mailing lists, just for a change in nomenclature. There's not much to say on this topic that wasn't covered in the front page news: http://archlinux.org/news/368/ * New netcfg scripts _still_ in [testing] I want to poke this item here. I'd like to get some yays/nays here. I dropped the ball on including the patches into an initscripts package in [testing] which replaces the current netcfg scripts. It's on my list - high priority. More details here: http://archlinux.org/news/362/ * Packages in [extra] I attempted to get some discussion here a few times, and not much came of it. As such, here's the criteria for what goes in extra, and what goes in community. * Packages in [extra] define us as a distro and should not include packages for personal use. If something is personal and/or only used by small amounts of people, it should go to community. Not only does this help us with our vision, it also helps out our mirrors (not all mirrors mirror the community repo). * Devs should inform everyone if they're putting a new package into extra, just in case another dev has an issue with it, to prevent silly bloat from too many personal packages. If someone has a problem with a package going into extra, a simple vote should suffice (no need to discuss it to death) * We should be prepared to remove contentious packages at any time. If someone claims "package foo doesn't belong in extra" and enough developers agree, we should simple move it to community and maintain it there. * Unified chroot build tools These chroot building tools have gone through some changes, and are in successful use on my "micro build machine": http://www.archlinux.org/pipermail/arch-dev-public/2007-November/003130.html This machine is being used to cover developers and TUs who do not have x86_64 hardware and still would like to build the packages. This way, we can help out the x86_64 guys immensely. Future plans involve setting up a 32bit chroot on the same machine for the converse of the above. == Pending Tasks, Short Term == * Logo contest delay We've hit a few snags trying to figure out issues with regard to setting up a trademark for our new logo. Suffice to say that we HAVE chosen the top 5 logos. And ARE moving forward with this. Travis, could you provide us with a follow up email with all the fun details here? * Bug tracker cleanup This weekend Roman is planning to do a big bug tracker overhaul and attempt to cleanup and consolidate our open bugs. Any help from the developers would be appreciated. I'd like to especially thank Allan McRae here too - I keep seeing him suggesting bugs be closed, and he's been helping Roman out here too. Thanks for the hard work. I'm very grateful. * Bug Squashing Day revamp We used to do official Bug Squashing days near the end of every month (second to last Sunday, or something to that effect), but these have fallen by the wayside due to Roman's awesome work. Even so, I'd like to get back in the swing of doing this, as it will help keep us all on track. Roman, would you like to help organize this? I will try to keep track of the dates and everything, but it'd be nice if you could spearhead the initiative. * Getting rid of /opt We officially have a todo list here. Actually, we have two: General packages: https://archlinux.org/todo/45/ (Thanks Jeff) Mozilla specific: https://archlinux.org/todo/44/ (Thanks Alex) It seems we haven't done a whole lot with this, though Paul's moved Eclipse out of /opt (yay!). It'd be nice if we can get to these at some point - they're not very taxing to change for the most part. Anyone willing to devote a night to knocking out the easy ones? * License Updates This one is not easy or pretty - every so often, please take a look at the items in the list and try to correct your licenses if they are wrong. https://archlinux.org/todo/43/ * ABS Redux This task has been partially done/discussed around the water cooler. http://archlinux.org/pipermail/arch-dev-public/2007-November/003224.html The plan? To create a static directory which we can use to rsync ABS instead of using cvsup. Dan has already sent some patches around. I will dig them up after I send this out. The easiest step here is to break ABS out from the pacman package - Dan, is is possible for us to do this as part of the 3.1 release? After that we can make ABS changes independent of pacman (and ABS is really an Arch specific tool, while pacman/makepkg are not) * Getting rid of CVS Last status report, I pointed this guy out. Roman responded with a vote for Jason's SVN proposal. In summary: * Jason has provided us with an svn solution, where sub-directories control the location of the package (i.e. package-name/repos/extra/PKGBUILD will place the package into extra) * Dan has provided us with a git solution that uses named branches to control the location (i.e. a branch named "testing" has changes to PKGBUILDs present only in the testing repo) I'm going to put my weight behind Jason's SVN proposal too, for the following reasons: * There is no reason to manage our packages in a distributed manner * SVN will be an easier transition for some users and developers unfamiliar with the esoteric commands of git. * It has a real implementation * One can use the git-svn porcelain on top of this, to still get the full power if git if they so wish. So, the next steps: Jason, can you provide us with some more details on your implementation, or perhaps something on gerolde as a preliminary system? I'd like to setup something side-by-side for people to use and to play with a bit. This way we can easily flesh out the hairier details. Paul, you did some similar work with repoman, yes? Do you have anything to add to this topic? == Pending Tasks, Long Term == * Perl policy implementation Kevin has been taking some of these on, and helping implement the perl policy. It's a big task, and any help from perl gurus around would be appretiated. http://bugs.archlinux.org/task/8374 * Pacman 3.1 Release We're still cranking away here. Big thanks go out to Chantry Xavier, Allan McRae, Nagy Gabor, and Nathan Jones for all the hard work. And thanks to all the translators too: Giovanni Scafora, Jeff Bailes, and anyone else I missed. Dan DOES have a pacman repo here with the latest and greatest pacman-git package for those of you wanting to live on the edge: http://archlinux.org/pipermail/pacman-dev/2007-November/009825.html Pending bugs for the release are listed here: http://bugs.archlinux.org/task/8109 * Official pacbuild usage This apparently has gone farther by the wayside with the machine I put out there for non-x86_64 devs to build packages, taking some of the load off of the guys who were waiting for pacbuild. I'm not even sure of the state here anymore - Simo, Jason, any news? Would you guys like root access to the build machine so as to have a place to RUN pacbuild? Last I checked I did install it, but it isn't configured or the most recent version. * Modernize our Dashboard Eliott has broken out our public and private sites, allowing us to, in the future, mess with our internal tools without disrupting the external site, in addition to applying improvements with regard to caching and all that fun stuff on the public site. The testing site URL should, for the time being, remain private - his original email was sent to the private ML. Please test it and give us a thumbs up/down if you have the time. You should be able to use it for all your normal public site access, if you'd like to give it a thorough testing. In order to garner more interest here, I'd like to get some docs or a script setup in the git repo that would allow one to run a quick local instance with a small test DB. Eliott, is this doable? * Architecture Independent Repos We have pacman support (for the 3.1 release) done thanks to Roman. We now have an idea of where we want the new SCM changes to go. This means some rewriting of the DB scripts are in order here. So, with this in mind, we should be able to create these architecture independent repos as part of the same push. Don't you love it when things fall into place like that? Here's the internal (private) task for anyone interested in this: http://bugs.archlinux.org/task/8555 * ArchCon 2009: Big Baaad Idea More details. Tom has suggested some dates for this. What do you guys think? http://archlinux.org/pipermail/arch-dev-public/2007-November/003310.html Pierre brought up a valid idea - we plan this around another convention that we have a presence at. Doing this at Froscon would cover our German/European contingent well, but we also have a chunk of developers on this side of the pond. It'd be nice if we could give an island somewhere in the middle of the Atlantic, but without massive volcanic activity, we're stuck with one side or the other. How to the Europeans feel about coming over here? And vice versa? Let's assume, for the sake of argument, that money isn't the issue here. Opinions? What about Canada? Birthplace of Arch AND it's not as dangerous as the US (hah!).

5 6

[arch-dev-public] Impending initscripts changes
by Aaron Griffin 20 Dec '07

20 Dec '07

Hey all, I've been throwing together a handful of initscripts changes to fix numerous bugs and things of that nature. Relevant git repo: http://code.phraktured.net/?p=initscripts.git;a=summary The splash branch contains the patch to make it look less like it's splash related (the wording makes it seem better, IMO) This is yet to be merged on my working branch (due to change there) but I'll do that tomorrow-ish. So, the working branch is the fun one to look at. ----------------------------------- http://bugs.archlinux.org/task/1186 (force background color to black - thanks Simo) http://bugs.archlinux.org/task/8843 (tput calls fail if /usr isn't mounted - thanks Roman) http://bugs.archlinux.org/task/6989 (added /etc/rc.d/functions.d/ directory) I'd like to finish this up, but want some input: http://bugs.archlinux.org/task/4550 (break out hwclock functionality from rc.sysinit) Thomas merged this earlier: http://bugs.archlinux.org/task/8579 (allow loading of multiple keymaps - thanks Roman) I don't think this one is a good idea: http://bugs.archlinux.org/task/6776 ----------------------------------- Anything else pending for initscripts? Any other requests? Can I get some possible input on the above items? Thanks in advance.

2 5

[arch-dev-public] [signoff] filesystem 2007.11-4
by Aaron Griffin 20 Dec '07

20 Dec '07

Setup for FHS compliant man pages - FS#8839 Claim ownership of /etc/profile from bash - FS#4766 Remove LESSCHARSET env var from /etc/profile - FS#8877 Please test. This goes hand-in-hand with the bash package (see other sign off) /etc/profile was also largely revamped. Please comment on that if you'd like to, we can always add more stuff before it's out of testing.

4 5