- Arch-projects - lists.archlinux.org

[arch-projects] SolarWiki--php5 based Wiki
by cactus 16 Mar '05

16 Mar '05

I have a little project going. It is a php5 based wiki. http://solarwiki.net/ http://user-contributions.org/forums/userproject/viewforum.php?f=12

2 2

[arch-projects] Reviving this list
by Dusty Phillips 15 Mar '05

15 Mar '05

Hey folks, I'm planning on trying to revive this mailing list. Want to get some people posting ideas and workgroups here and stuff. Try to expand the scope of the list a bit to include not just Arch-specific projects, but also development on other linux-related projects created by Arch users. For the most part, Arch Linux users seem to be a pretty smart group, although this seems to be dropping, given the current state of the AL community. I'm looking for a somewhat smaller and much more interesting/less stupid community of developer types. This is going to be it. I've sort of got Xentac's blessing on this, so if you don't like these plans for the list, feel free to unsubscribe. Otherwise, feel free to start posting something interesting! :-) I've got a few small script ideas I'll be interested in posting later on. I've also seen some interesting projects that I think would be good candidates for this sort of discussion; I'm going to try to get the authors on board. I'm also mining for members at user-contributions.org. We mostly all know each other as Arch users here. Simply put this should be a subcommunity of Arch-users comprised of people who are also active programmers. Let me know what you think. Happy Hacking, Dusty

1 0

[arch-projects] Brain storming - php parsing bash
by Jason Chu 13 Dec '04

13 Dec '04

Alright, I'll give you guys a problem and see what sorts of solutions you can come up with. We have a php script that will be downloading PKGBUILD tarballs from users (the users will be uploading to the script). One of the things we want to do is parse the PKGBUILD scripts and store the information like sources and depends in a database, much the same as the current archlinux.org website works. There's one big difference between what we do on the archlinux.org site and this other site (in case you haven't guessed it's for the AUR site): we trust the developers and don't trust Joe Anonymous on the internet. On archlinux.org we just run the script through bash and output all the variables that are set, after they've been evaluated. We can't just trust any old script from any old person to be safe enough to just run and get variables out of. Know of any good ways to get those variables out without the risk of a malicious script running amuck? Would something like sash or that other restricted shell work in the majority of cases? Other ideas I haven't thought of? Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are. My old gpg key expired, the new one is available from keyservers. I was stupid enough not to realize this before it was too late, so I am not able to sign my new key with my old key. If this assurance isn't enough, please contact me.

1 0

[arch-projects] Multi-cd ideas for pacman
by Jason Chu 02 Oct '04

02 Oct '04

http://bbs.archlinux.org/viewtopic.php?t=7138&start=0&postdays=0&postorder=… The problem goes something like this: Pacman assumes that all files are available in a given repo. This means that if you split up dependencies across multiple cds, pacman will assume they're all available in one directory. My thought is to write a small (or smallish) program that pacman will use as an XferCommand that will let you get around the multiple cd problem. Anyone up for the challenge? Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are. My old gpg key expired, the new one is available from keyservers. I was stupid enough not to realize this before it was too late, so I am not able to sign my new key with my old key. If this assurance isn't enough, please contact me.

1 0

[arch-projects] Pluggable wrapper
by Jason Chu 01 Sep '04

01 Sep '04

There are two conflicting schools of thought with respect to adding features to pacman: - everything should be written into pacman, because there's less to worry about that way - everything should be a wrapper, because it complicates pacman less For the most part, I believe the latter. There are some things that would benefit everyone if they were added to pacman, but most things would just add unnecessary complexity that's only used by a subset of all the users. There is a related issue to wrappers though: if you have more than one wrapper that do complimentary things, shouldn't you be able to run both of them at the same time? Enter the pluggable wrapper script. It would be event based, interfacing (almost) seamlessly with pacman, and allow you to enabled and disable wrapper functionality, such as srcpac. My two example cases were srcpac and rollbacks. Rollbacks could be implementable through such a system, but I'm already told it'll be going right into pacman itself. Another example is regular expression searching. What does everyone think of this idea? Is there enough demand for different functionalities that would be nice for some people but annoying, problematic or just stupid to add to pacman? Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are. My old gpg key expired, the new one is available from keyservers. I was stupid enough not to realize this before it was too late, so I am not able to sign my new key with my old key. If this assurance isn't enough, please contact me.

4 9

[arch-projects] pacbuild
by Jason Chu 29 Aug '04

29 Aug '04

Here is my explanation and my current status with respect to pacbuild. I've been toying with the idea of an autobuilder for a while now, but only implemented it in the last 4 months. As it stands, I use it to keep i586 relatively up to date. Right now it uses python, postgresql, and user mode linux (UML). It's broken into three parts: 1) waka 2) catchup 2) checkbuilds Waka is the actual building daemon. It starts UML sessions using copy on write (COW) files, so that I can just throw away the build session after it's done. Catchup scans /var/abs looking for builds that are newer than the ones in the currently defined repo. Checkbuilds gives you the logs from built packages so they can be reviewed and marked as correct or not. If they are incorrect, they are marked in the db as incorrect and there is no attempt at building the same version again. If they are correct, they're added to the repo, old packages are removed and the db is updated. Rarely do I have to mark a build as incorrect, because most of them actually fail and are detected as such. As it stands, I have run into a few limitations of my current implementation: - distributed building with multiple wakas on remote machines - provides support - no support for extra scripts (such as a generated packages.txt needed for the current repo) Just glancing at the code, I might actually be able to add provides support fairly easily, to the catchup script. I'd have more trouble getting proper provides working within waka and makepkg. Distributed building is more difficult. My initial implementation uses the filesystem to store builds and pass around files and whatnot. I really don't know if I want to go to a db-storage solution or something else entirely. I would have to abstract the building and the managing aspects a bit more to make it work better. This will be something that needs a lot of thinking and designing. The extra scripts support will probably come along when I actually implement support for multiple repos. In my first version, only one repo is supported, that's one of the reasons only current is being built. I'm not exactly sure why I'm explaining this, I don't know exactly what you people could do without a lot more explanation... Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are. My old gpg key expired, the new one is available from keyservers. I was stupid enough not to realize this before it was too late, so I am not able to sign my new key with my old key. If this assurance isn't enough, please contact me.

2 2

[arch-projects] Configuration Management
by Paul Mattal 29 Aug '04

29 Aug '04

It would be nice to have a system within Arch to manage configuration files. I'd really like to be able to express my Arch Linux systems setups as a set of installed packages and a number of configuration sets and then not have to back up all the system files. This allows a sysadmin to create another Arch box just like the one he's already got in minutes. This system would allow one to easily package up configurations and deploy them to multiple machines. For instance, I set up each desktop user box in my office for printing in the same way, and I set up nfs to mount the same filesystems, and even enscript to use letter rather than A4 paper. It would be nice to be able to point each box at a "config repo" with configurations associated with packages, and then have pacman automatically pick up those configurations when I install the corresponding packages. I'd like to hear people's input on how to make this work best in Arch and whether or not they'd think it useful. I can describe something I've worked on for the arch-toaster by way of example of the kind of thing I'm talking about, which led me to desire a more general-purpose tool. For the toaster, I have an "arch-toaster" package which contains a lot of dependencies on packages the toaster needs, plus default configuration files and a fairly reusable perl script which had 2 main purposes: 1) to deploy the "default" configuration files to "current" locations (if there's no "current" version already) where they can be further customized, if desired 2) to deploy the "current" configuration files to their real "field" locations on the filesystem after editing, or after updating the system (since configuration files must in some cases replace package files), making backups as it does so to avoid ever destroying any intended changes made directly in the field Additionally, I added a third function to the script, useful in development: to roll the configuration files from the field back into "current" and store them in a tar.gz which I could then roll back into my package build as I refined the arch-toaster package. This was my means of collecting my changes as I went along. Then all I had to continue to maintain was the list of files that would be under control of my configuration management system, and it handled the rest. Anyhow, I'm mostly curious if people think this is a good idea, or if they think there is a better way, or both. This would be a sizeable project, but not that awfully complex, I don't think. - P

1 0

[arch-projects] Debian menu program
by Jason Chu 29 Aug '04

29 Aug '04

Many people have suggested a universal menu system (one that can keep every WMs menu up to date with all the packages installed on the system). People say that the freedesktop standard will do that for us and all we have to do is wait for WMs to support it. Personally, I think it'll be a while before all the WMs support the freedesktop standard and I'm not sure if we really should wait. Debian had a solution to this problem in the form of its menu program. The menu program consisted of a directory called /usr/share/menu that you stored a menu file in (the menu file describes categories, command names, and titles of programs; each package gets one but can describe multiple programs in a single file), definitions to create menus for each WM, and an update-menus script. The update-menus script would scan all the files in /usr/share/menu and generate menus for all the installed packages. This was done automatically by the dpkg program. My original idea was to port the Debian menu program (version 2) to Arch and add it as an optional service. Someone who has the menu package installed can run update-menus at any time and it would update all the menus for all WMs on the system. The purpose of this system was not to make stupider users but to simplify administration of systems. If I'm a sys admin for a box that has 4 users (let's say it's a family computer) and one user wants me to install freeciv so ge* can play it, do I want to help ger* to add a menu item as well? What if other people in the house want to play freeciv as well? Will I help all of them add these items to their menus? In this way, it simplifies administration, isn't mandatory, and doesn't hide anything. I did a little bit of research into using Debian's menu program, the problem is that depnends on Debian's dpkg. To make this work, someone would have to patch the menu program to work with pacman. Is anyone interested? Jason *ge/gis/ger are the newly proposed third person singular gender-neutral pronouns. Ge is similar to he, gis to his, and ger to him. -- If you understand, things are just as they are. If you do not understand, things are just as they are. My old gpg key expired, the new one is available from keyservers. I was stupid enough not to realize this before it was too late, so I am not able to sign my new key with my old key. If this assurance isn't enough, please contact me.

2 2

Re: [arch-projects] Proposal for additional gcc packages
by Paul Mattal 29 Aug '04

29 Aug '04

This is a good idea for other languages.. also for other platforms. Awhile ago I had to do some cross-compiling for arm, and I think I created a nice set of retargetable packages for compiling cross-compiler packages. I should dig these out and get them into the general consciousness. I keep meaning to eventually try the cross-compiled stuff on the old Intrinsyc cubes I used to use as dns/dhcp servers. At the time, I was cross-compiling for other purposes, but the cross-compiler worked great. - P

1 0

[arch-projects] Status update on the gcc packages
by Jason Chu 28 Aug '04

28 Aug '04

I was able to build f77 and java packages for this but I ran into a snag: they both share a file that isn't available in the original gcc package (/usr/lib/gcc/i686-pc-linux-gnu/3.4.1/include/nessus/net/bpf.h). I wouldn't want to make one of them depend on the other, but making a gcc-added-compat package is also probably a bad idea. Any suggestions to get around this problem? Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are. My old gpg key expired, the new one is available from keyservers. I was stupid enough not to realize this before it was too late, so I am not able to sign my new key with my old key. If this assurance isn't enough, please contact me.

1 0