- Arch-announce - lists.archlinux.org

[arch-announce] netcfg2 is now in [testing]
by Roman Kyrylych 06 Nov '07

06 Nov '07

---------- Forwarded message ---------- From: James Rayner <iphitus(a)gmail.com> Date: 6 Лис 2007 00:38 Subject: [arch] netcfg2 is now in [testing] To: arch(a)archlinux.org netcfg2 aims to be a refined network profile system for Arch Linux, replacing the current implementation. Through this, it has also gained various features and improvements which are listed on the development wiki page (http://wiki.archlinux.org/index.php/Network_Scripts) Before it can replace the current profiles, netcfg2 needs testers of various wireless hardware and configuration to try the scripts and report back on the wiki page testing section (http://wiki.archlinux.org/index.php/Network_Scripts#Testing). Bugs can be filed at the bug tracker. Documentation for netcfg2 is located in the netcfg manpage, detailed examples in /etc/network.d/examples, and the wiki: http://wiki.archlinux.org/index.php/Network_Profiles -- Roman Kyrylych (Роман Кирилич)

1 0

[arch-announce] Status Report: 2007-11-05
by Aaron Griffin 06 Nov '07

06 Nov '07

ArchLinux Status Report, 2007-11-05 =================================== Aaron Griffin (Reviewed by Travis Willard) So, some of you may have noticed there was no Status Report last week. Well, see, I got busy. No one to blame but myself. I _was_ going to get it out on Tuesday, but decided to "roll with it", as it were. So, before we get started, I wanted to get some honest opinions - does doing this every 2 weeks make you guys feel less pestered? One important thing to note: for anyone looking for "something to do", the reason I list a lot of thing here is that I feel we should get them done. If you're looking for things to do, I'd appreciate it if you took a look at this list to see if there's something you can tackle. == Newsworthy Items == * New Logo Competition has begun! The competition for the new Arch logo, spearheaded by Travis, has begun. Full details can be found in this news item: http://archlinux.org/news/359/ * New Newsletter Format Eduardo Romero (kensai) has taken over doing our newsletter, and has changed the format and content. Take a look, and let him know what you think - I, for one, think it's great. Thanks a lot for all the effort Eduardo, and congrats on making a great new new style and layout! == Completed Tasks == * Latest ISO Testing The upcoming 2007.11 ISOs have been in testing for some time now. ftp://ftp.archlinux.org/other/rc-iso/2007.11/ No new show-stoppers have been reported, so I believe we should have new ISOs when Tobias returns from his exams. Yay! * New devtools release This is for all the developers and TUs. We've included a few new features, and two new scripts, in the latest devtools release. Please report any problems or feature requests on the bug tracker. * Xorg 7.3 out of testing Xorg 7.3 has been in testing for about a month now. It's time to move it out there. http://archlinux.org/news/363/ Thanks go out, of course, to Alex for making this happen. * Code projects moved to git All our code projects have officially been moved to our git repos, located at http://projects.archlinux.org/git/ Special thanks to Dan, Simo, and Eliott for carving up CVS and SVN repos to create nice little subsets for specific projects. * cvsup is dead. Long live csup. We've officially replaced cvsup (used by ABS) with csup. There are a handful of reasons, but the biggest one is that cvsup does not compile on x86_64. Thanks to Dan for actually making the move and testing it. * slocate has been replaced by mlocate This has been a long time coming. mlocate is a locate/updatedb implementation that uses a different method of updating the locate database, making it much faster on successive runs. This means your machine isn't going to grind to a halt every night at around midnight, heh. Thanks goes out to James for pushing this one through here, good job. == Pending Tasks, Short Term == * QT4 Move Pierre has proposed a migration plan for moving to QT4. http://archlinux.org/pipermail/arch-dev-public/2007-November/002910.html This appears to be straightforward, so we should get to this soon! Hooray for progress! * Killing off of /opt According to Jan, the last remaining apps we have in /opt (KDE, OpenOffice, and Mozilla/Firefox) can be safely moved out of /opt and into the /usr tree like everything else. Moving binaries and things out of /opt is going to remove a lot of headache we've had in the past. So for anyone who maintains a package that installs to /opt, see if you can get it to install in /usr instead. * Core rebuild Our core rebuild, due to toolchain changes, is currently waiting for testing to empty. For those developers that have packages sitting in testing, please either try to push them up to the real repo, or remove them from testing if they are old. Andy has started cleanup threads for most of these packages. Please check here to see if you own any of these packages: http://archlinux.org/pipermail/arch-dev-public/2007-November/002855.html http://archlinux.org/pipermail/arch-dev-public/2007-November/002856.html * License Updates Travis has created us a _HUGE_ todolist of packages with broken licenses. Please take a look at it and see if you can close out any packages you currently own. http://archlinux.org/todo/43/ Keep in mind that this list contains ONLY packages in the [extra] repo. This means it will not affect the core repo rebuild, but may be affected by the Package Cleanup. * The dividing line: extra and community Another discussion that has gone by the wayside. I'll try to summarize here to see if we can a better idea. The question: when does a package belong in extra? We all agree that we need some sort of "rule" for this. There seems to be two big ideas on how to "answer" this question: a) Split extra into "mantle" and "crust". Mantle contains packages "important to the distro" to be agreed upon by the developers, and crust contains anything else a developer wants to maintain. b) The idea above remains the same, BUT extra is not split at all. The "mantle" packages go to extra, and "crust" packages go to community. So, what do you guys think? Should we vote on these two to get things moving? * Package and Orphan Cleanup Eric has done an amazing job of cleaning up a big wave of packages from extra. All things considered, this is fairly important task, as is affects the "Dividing line" question above, as well as lightening our workload. Eric, what is the next step here - how can we help? * DVD and Additional Package ISO Lists Still not even a peep from people. This is the last time I'm going to include this item on the list. If we don't get any sort of activity or discussion on this, I am going to consider the matter closed. The question: do we want to distribute additional DVDs/CDs full of packages? If so, how do we define what packages are on these things? * Unified chroot build tools The new devtools release has pushed two of these tools out there: mkarchroot, for creating ArchLinux based chroots, and makechrootpkg, for running makepkg inside one of these chroots. Currently, there are a few little bugs floating around, but feel free to report more. The next step is to move to official usage here, so for you developers out there, PLEASE contact me if you have any problems - we should all be building packages in clean chroots to make sure hidden dependencies do not sneak into the packages, and I want to make these tools as easy to use as possible. * DB Scripts Code to git With our SCM backend changing, the DB Scripts rewrite task is no longer a big deal. What we _do need_, however, is our existing code moved out of CVS (and into git, in an ideal world). This way we can use these as examples as we create new scripts for working with our new SCM layout. == Pending Tasks, Long Term == * Perl policy I've moved this one to the long-term section http://bugs.archlinux.org/task/8374 Apparently, perl isn't very widely cared about, so this is mostly all up to me, and we all know my freetime is hard to find these days. So, this is on the "hey this is important" list, but there is no rush. * Getting rid of CVS Last time we visted this, we had two potential implementations. The complexity here has to do with representing one package in many repos at the same time. _This_ is the problem that is solved by CVS tags that we need to redefine elsewhere. Jason gave us an example svn implementation that used the following structure: package-name/ PKGBUILD repos/ core/ testing/ blahblah/ Where each directory under repos/ is a new repository that contains a PKGBUILD and all supplemental files that are routinely "synced" with the master files (in the top level directory). Dan gave us a git implementation that uses a similar structure, but uses git's "lightweight branches" in place of the repos/ directory. This also allows us to create rebuild branches and the like very easily. Here is a usage example: git checkout -b foo_rebuild $EDITOR foo/PKGBUILD $EDITOR pkg1/PKGBUILD $EDITOR pkg2/PKGBUILD git commit -a or git checkout -b testing $EDITOR foobar/PKGBUILD git commit -a The branch names above indicate a new repo, which contain only packages that are changed in the new branch. So, I leave the floor open here - what do you guys think? Which is a better solution? I want to open this up to opinion and vote _real_ soon, as this is something we've talked about for so long it's becoming near mythical. * Pacman 3.1 Release http://bugs.archlinux.org/task/8109 Ah, another stagnating task. We've gotten some great patch contributions from the community, and Dan has been rocking with the pacman changes. We'd love to see more testers out there testing the version from git, and possibly confirming some of the "Requires Testing" bugs on the above, so we can close them out. * Official pacbuild usage We have an official git repo for pacbuild sitting here: http://projects.archlinux.org/git/?p=pacbuild.git;a=summary The news here is small, again. Last I heard, Jason is planning on incorporating the new 'mkarchroot' tool from devtools into pacbuild. Anything else, I am unsure of. Jason, would you mind informing us on what needs to be done to get pacbuild running somewhere? I'd like to do _something_ here before this becomes vaporware. * Modernize our Dashboard Ok, we've made some steps. We now have our web code up here: http://projects.archlinux.org/git/?p=archweb.git;a=summary I plan on filling out the README as far as running your own instance goes. >From there, I'd like people to add any and all dashboard related requests to the "Internal Dev" bug tracker, so we can begin closing them out. * Architecture Independent Repos Roman has provided us patches for makepkg on the pacman-dev list. That's step one. The next step is to modify our DB scripts to check for the proper suffix, and run itself for both the i686 and x86_64 repos. This one is a rather small change, is anyone interested in doing this? Thomas? * ArchCon 2009: Big Baaad Idea http://archlinux.org/pipermail/arch-dev-public/2007-September/001614.html ArchCon is still floating here at the bottom of the list...but it looks like no one is interested anymore. That's sad. No one wants to come visit lil ol' me?

1 0

[arch-announce] slocate Replaced by mlocate
by Roman Kyrylych 05 Nov '07

05 Nov '07

2007/11/5, James Rayner <iphitus(a)gmail.com>: > mlocate has replaced slocate as the default locate implementation after a > short period in [testing], and an even longer one in [extra]. This was > requested on the bug tracker a while back[1]. > > mlocate is used by Fedora at least and unlike slocate, no longer has the > well known midnight updatedb crawl. In all other aspects it's compatible > with and identical to slocate. > > AndyRTR posted some performance measurements on the mailing list [2]. > > [1] http://bugs.archlinux.org/task/4490 > [2] http://archlinux.org/pipermail/arch-dev-public/2007-November/002870.html > > As described by the README: > mlocate is a locate/updatedb implementation. The 'm' stands for > "merging": updatedb reuses the existing database to avoid rereading most > of the file system, which makes updatedb faster and does not trash the > system caches as much. > > The locate(1) utility is intended to be completely compatible to slocate. > It also attempts to be compatible to GNU locate, when it does not conflict > with slocate compatibility. > -- Roman Kyrylych (Роман Кирилич)

1 0

[arch-announce] Arch Linux Logo Competition
by Travis Willard 25 Oct '07

25 Oct '07

Hello everyone! As you may have heard, the Arch logo as we know it is going the way of the dodo! We are refreshing our graphical identity, and in that spirit we're having a logo competition, open to the entire Arch community! We want to know what you think of when you think Arch Linux - what logo do you think would best suit the distribution we've all come to love? Submission guidelines are as follows: . Anyone can submit as many logo concepts as they wish . Entry is freeform, with no need to base it on current logo. Be creative! . For the sake of moving the competition along, artists will maintain the rights to their works until the completion of the competition, when we've decided what to do with license issues. Per submission, you will need: . SVG sources for logo preferred. If you don't know how to make SVG logos, but have a great idea, visit this[1] thread; foxbunny has graciously stepped up to help with logo concepts. . Fill out the following on this submission sheet[2] (courtesy of foxbunny) .. Name (or alias) .. Main logo areas (white/black/neutral BG) .. 2-colour or Black version .. 128x128px and 16x16px icon version .. Colour palette used All other fields are optional - you do not need them to create a submission, and omission of those options will not count negatively against you. Submit completed submission sheet attached in an email to travis AT archlinux.org. They will be posted in this[3] thread; two weeks after the date of this post, we will collect all submissions in that thread and judge. Judging will be the job of the Developers, and will proceed as follows: All submissions will be posted to the [arch-dev] private mailing list, and developers will give their +1 to those logos they like. They may add a +1 to more than one submission - once all developers are accounted for, the logo with the most +1 votes will win. Should multiple logo submissions tie for first place, those entries will be announced to the community, and we will have a community vote on the forums. The logo voted highest in this case will be the winner. Additionally, we'll want to use the logo for additional media - CD labels or wallpapers, for example. If the winning author hasn't provided any, they will be given a chance after the competition is over to create this artwork, if they want. Basically, no need to get it done before the judging, if you want to do it, so don't worry! :) Please note: there are also threads for logo concept discussion[4] and for showing off possible concepts, without entering them into the competition[5]. Feel free to make use of them. Good luck to all participants, and have fun! [1] http://bbs.archlinux.org/viewtopic.php?id=38666 [2] http://www.archlinux.org/~travis/logo-contest/submission-blank.png [3] http://bbs.archlinux.org/viewtopic.php?pid=292815 [4] http://bbs.archlinux.org/viewtopic.php?id=38051 [5] http://bbs.archlinux.org/viewtopic.php?pid=290216

1 0

[arch-announce] Addendum SR 2007-10-22
by Aaron Griffin 23 Oct '07

23 Oct '07

There was a mistake in the previous status report. Our release is NOT "Hardcore" but "Core Dump". My mistake. The entry should read: ------------------------------------------------------------------------ * New release named Our next ISO release, codenamed "Core Dump", is almost ready to go, and will be released at the beginning of next month. Be prepared for a good old round of testing starting this week. ------------------------------------------------------------------------

1 0

[arch-announce] Status Report 2007-10-22
by Aaron Griffin 23 Oct '07

23 Oct '07

ArchLinux Status Report, 2007-10-22 And another week goes by. Hectic for me, and I'm sure others too. Sadly, I got very little of what I hoped accomplished. So I'll be sure to revisit those items this time. Just to be clear here, because I don't think I expressed this properly: The tasks listed here are things I'd _like_ to see done. I'm 100% positive there are other things that need doing, but if you let _me_ worry about that, it will lift some weight off of all of us. What I'm saying is this: if you see some sort of larger task that we should all be a part of, let me know, and I will deal with delegation and all that fun stuff so you don't have to. And if you have some free time, check the list I have here. == Newsworthy Items == * New Announcement Mailing List In a bit of irony, this will be the first email to this new list, I believe. Please try and use this list for all official announcements, until I sit down and setup rss2email on gerolde for the front page news. == Completed Tasks == * New initscripts in testing Looks like we closed out 4 or 5 bugs with this initscripts package, so congrats guys. In addition, we've moved the initscripts code out of our package tree: http://projects.archlinux.org/git/?p=initscripts.git;a=summary * git project owners I've setup all our code projects with real owners and groups, so we can more effectively manage this stuff. So now we have real people to point fingers at, yay! You can see the list here: http://projects.archlinux.org/git/ * AUFS support patch added to kernel26 A small patch was added to our kernel to support building AUFS out-of-tree from the kernel. This means that we'll also see aufs packages in extra soon. * New release named Our next ISO release, codenamed "Hardcore", is almost ready to go, and will be released at the beginning of next month. Be prepared for a good old round of testing starting this week. == Pending Tasks, Short Term == * Core rebuild With the release of the new glibc, we want to, at the very least, rebuild all of the core repo to take advantage of the latest changes. Ref: http://archlinux.org/pipermail/arch-dev-public/2007-October/002441.html Extra will be much harder to do, so we should attack the core repo first. Lets focus on that for now, and complete a rebuild of extra as the next step. * License Updates Travis has provided us a list of packages that have broken or improper licenses. This stuff is becoming more and more important, so I'd like to get some supervision here as soon as possible. This looks like it's a task that pairs well with the core rebuild and extra cleanup. So, anyone participating in those tasks should keep this list in mind. Travis, would it be possible to get this list on the dev wiki? Or possibly setup as a todo list? Ref: http://archlinux.org/pipermail/arch-dev-public/2007-October/002505.html * New logo competition Travis is spearheading this competition for our new logo. Sometime this week, we should get things started, as we have all the rules down. There is, however, a question of legality raised by Simo. http://archlinux.org/pipermail/arch-dev-public/2007-October/002494.html If anyone has some insight here, it'd be helpful. We need to address this before we move forward with this competition. * The dividing line: extra and community Last time, we had this discussion, and it didn't go all that much farther. The question is this: What defines 'extra'? We seemed to talk a big game, but no decision was really reached. So, let us revisit this thread if possible: http://archlinux.org/pipermail/arch-dev-public/2007-October/002263.html Do we want to go with Damir's suggestion and make "mantle" and "crust", or would we rather stick with the current layout and make extra the "mantle" and community the "crust" ? * Package and Orphan Cleanup And again, I've dropped the ball here. We have a list of packages here: https://www.archlinux.org/wiki/Repo%20Cleanup/ If anyone has some freetime, could you help me figure out what needs to go where, perhaps with another column on that page? Could we annotate the list with what should move to community and what should move to unsupported? In addition, is there any way someone would want to export this list to the public wiki for review by the TUs? * DVD and Additional Package ISO Lists This item has been pending for some time. Discussion was heavy when this was first brought up, but now no one seems concerned about additional ISOs for packages. https://www.archlinux.org/wiki/ISO-Packages/ So, here's the ultimatum: either we at least add a few packages here, or we decide against doing this at all. Should we be distributing additional CDs/DVDs like this? * Unified chroot build tools I have some minor modifications still pending, but this should be ready to go this week. Andy's already done some testing and reported some errors. If you guys could try and go through here and test, that'd be great. Any criticism is appreciated. http://code.phraktured.net/?p=devtools.git;a=summary * Perl policy I've created a bug collector for Perl policy changes: http://bugs.archlinux.org/task/8374 It would be nice if anyone vested in perl on Arch would help out here. Patches for PKGBUILDs are always appretiated. == Pending Tasks, Long Term == * Getting rid of CVS This is a LONG time coming. We've been sitting on CVS for some time, and many of us (including myself) feel that it's time to move on. We've tried to discuss how to do this numerous times, but hit a brick wall that seems to be made of lack-of-work and I-don't-want-to-change. Thankfully, Jason stepped up to the plate and provided us with a working SVN implementation of a new PKGBUILD repo setup: http://archlinux.org/pipermail/arch-dev-public/2007-October/002308.html If anyone else has something to show for this, don't be shy, let us see it. For some reason apathy overtakes this topic whenever it's discussed, and Id love to prevent that from happening again. * Pacman 3.1 Release http://bugs.archlinux.org/task/8109 Ah, another stagnating task. Dan's been pushing some interesting patches into git, but haven't got many of these big bugs closed. Dan, could you let me know when you're free this week? We could sit down and 'sprint' a few of these bugs away. * DB Script Rewrite This item is going to become more and more important if we change repo layouts (see above). I'd like to split this task up into a few actionable portions: a) Get the DB scripts setup in a git repo like everything else b) Find an "owner" who wants to read through the code and address what would need to change if we changed SCMs. c) Try * Official pacbuild usage http://archlinux.org/pipermail/arch-dev-public/2007-October/001944.html We have an official git repo for pacbuild sitting here: http://projects.archlinux.org/git/?p=pacbuild.git;a=summary I don't think we've had any news on this front. We only have a small contingent of developers actually writing code, so this is a difficult one. I'd love to get someone in place actually working on pacbuild fulltime, as it's a very important tool for us. Do we have any python coders among us that want to show their mettle? * 'Continuous Integration' setup / machine Still an item on here. I think we're going to wait and see how we move our repo SCM in order to do this, as it'd really be just a hook to that SCM. * Modernize our Dashboard I have some documentation on doing this, I want to finalize it and possibly setup a test instance on one of my machines at home for us to play with. Eliott, Simo: I'd still like to get a sanitized git repo up for the web code, so the public can play with it as well. Is either of you available to do this sometime this week? * Architecture Independent Repos This one also seems to have gone by the wayside. What happened to the flare we had for this, or are we all waiting for someone else to do the work? http://bugs.archlinux.org/task/8153 Action Items: a) Update devtools to support arch=(all) by tagging for BOTH CURRENT and CURRENT64 b) Update DB scripts to support arch=(all) by running DB scripts for BOTH architectures. c) Test. Test. Test. * ArchCon 2009: Big Baaad Idea http://archlinux.org/pipermail/arch-dev-public/2007-September/001614.html Ah ArchCon. There was a burst of enthusiasm at first, but it died down. I wonder what country would be best? Is the rest of the world still scared to come here to the US? Or should we go to Canada?

1 0