- Arch-projects - lists.archlinux.org

[arch-projects] calling python from C/C++
by Aaron Griffin 16 Mar '05

16 Mar '05

ok, here's what I want to do: ---- foobar.py --------------- class foo: def bar(self): print "bar called" def foobar(): print "foobar called" ---------------------------------- and I'm gonna make up the syntax here: ----- test.c ------------------- #include <python.h> /* dunno if this is right */ void main() { PyObject *o; o = PyLoadModule("foobar"); o.call("foobar"); PyObject *x; x = PyImport("foobar.foo"); x.call("bar"); } ---------------------------------- what I want to know is the proper syntax to do this...the docs are sketchy Also, what's the correct way to pass a C struct to python?

2 2

[arch-projects] Xenophile
by Dusty Phillips 16 Mar '05

16 Mar '05

The guy who came up with this idea is either too modest or too busy to post it here. I'm sure some people have heard of it already: http://xentac.net/~jchu/blog/technology/jabber/xenophile-intro.html An interesting idea for remote control and communication with daemons via Jabber. Dusty

3 5

[arch-projects] interesting developer tool
by Joao Estevao 16 Mar '05

16 Mar '05

If you're a programmer and have the same dislike for creating .ac and .am files as myself, you might want to check this. Haven't tested it though... http://premake.sourceforge.net/ -- A mind all logic is like a knife all blade. It makes the hand bleed that uses it. -- Rabindranath Tagore (1861-1941)

2 1

[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